A tutorial to help you write comprehensive unit-test suites.
Let’s imagine we just wrote a method calculating distance between two points on our planet. And let’s imagine we want to test it as well as possible. How do we come up with test cases? And what exactly do we need to test?
Continue reading “Writing Good Unit-Tests: A Step By Step Tutorial”
I sometimes have this feeling: The Hunch™. It’s when I sense there is something wrong with the project, with the requirement, or with the feature, even when everyone else is sure all is well.
When I sense this, I feel like a dog who picked up the scent. I follow the scent by asking questions, until I get my answer.
Here’s how it happens.
Continue reading “The Hunch: 4 Times I Felt It And 1 When I Didn’t, And What Were The Consequences”
You’re in for a technical interview. They ask you a question, and you have to build a system or to write some code, either on a whiteboard (brr!), on a piece of paper, or on a laptop at home. And then you discuss it with the interviewer.
Some enjoy it, and some dread it. But if you are going through it, it means the end of the process is near! And you really want to show the best side of yourself.
I led more than 120 interviews. Here are some common mistakes I noticed the candidates make.
Continue reading “11 Mistakes To Avoid On A Technical Interview”
I call it a hunch.
Sometimes I sense something’s wrong.
There is no visible indicator of it. Devs say it’s going well, products say it’s on time and under control, specialists say it’s all aligned and agreed on.
Continue reading “Problem Solving: A Hunch”
I have unit-tested my code for many years.
While building a GIS-system, we really cared about our product quality. Our users’ needs demanded the app to work properly. I had all critical and/or complex parts of code 100% test-covered, with multiple paths and corner cases. It was such a pleasure to find a bug, fix it, write a couple of tests for this surprise scenario, and be sure it won’t break again. Ah, good times.
Continue reading “Unit-testing: best practices”
Last week a very nice thing happened with me. Two of my colleagues asked my advice on analyzing corner cases.
Continue reading “Problem Solving: Thinking About Corner Cases”
Many developers tell what they have done. They used Kafka, RabbitMQ and Kubernetes. They sharded, scaled and clustered. They moved the logic from monoliths to microservices. They built castles and teared down mountains.
What they often don’t say is why they did it.
I often ask this question on interviews:
“What is the most interesting or challenging task you have ever done?”
The answer tells me a lot.
Continue reading “Seeing The Big Picture: One Important Aspect Of Being A Senior Developer”
What’s common between software and opera houses? Building of both often goes overtime. Read on to know why and what should you do about it, as a client or as a developer.
Many software projects go overtime. Software developers get blamed for that, laughed at, scorned at.
But guess what: it’s not only software developers.
Many building projects also go overtime, and most noticeably of all, perhaps, opera houses and concert halls.
Continue reading “What’s Common Between Opera Houses And Software Projects, or 10 Reasons Software Developers Go Overtime”
If you ask me, what’s a single most important thing in writing good code, I’d reply: “Modularization and Dependency Management”.
Well, actually, that’s two things. Sorry about that! But they are two sides of the same coin, and you can’t have one without the other, if you want to your code to be nice and clean.
Continue reading “Modularization and dependency management: three steps to better code”
Are you a perfectionist? That kind of a person that can never say “I’m done”, “it’s ready” or “let’s ship it”? The one who can’t release the new feature unless it’s polished and perfect?
Continue reading “Prioritization for Perfectionists, or: How I Learned to Stop Worrying and Love the Non-Perfection”