To become a great programmer, never say “It's not working”

Early in my career, I've spent an excessive amount of time answering questions on Stackoverflow. I've watched the platform go from being expert-centric. Experienced programmers tried to get answers to some complex issues. To a much lower barrier of entry. Everyone who wanted to dabble with programming could have their questions answered. This opened the floodgates to some very basic questions asked in the most complex way possible.

You would get a post that simply told you that the code doesn't work, then what followed was a dump of un-formatted code. There is nothing in the question that can help you solve the problem. In fact, it's not even a question. The more these types of questions were becoming common, the quicker I changed my habits. Rather than answering questions, I started asking my own. What doesn't work?

My favorite answer to "What doesn't work?" is, “I don't know.”

Solving these kinds of problems is the equivalent of fixing a car blindfolded with both hands and legs tied behind your back. Maybe the car battery is low. But you won't get to know that because, well you are blindfolded and your hands are tied behind your back.

The problem isn't that the code doesn't work. After working as a programmer for over a decade, I can assure you that at some point, every piece of code doesn't work. The real problem is that the developer doesn't know how to debug. I've come up with a little exercise to help new developers learn to debug their code. Any time someone tells me "it doesn't work," I smirk, roll-up my sleeves, and ask: Did you ever have battery problems with your car?

The battery problem.

Imagine you have a battery problem with your car, but you have no idea what the problem is. How do you figure out that it is the battery? I am no car expert. My only qualification is driving old cars that often left me stranded because of an exhausted battery. But along the way, I learned a thing or two.

Bare with me as I take you through the questions I'm going to ask below:

And just like that, we have a pretty good guess of what the problem is. The person with the car trouble could have saved us a whole lot of time if they had asked themselves all these questions before asking for help. In fact, they could have summarized their problem neatly like this. Let's extract information out of their answers.

"My car doesn't turn on. When I press the ignition button, it makes an unusual sound. As if the engine is struggling to start. It almost sounds like a cough. I have the impression that it could be the battery malfunctioning."

Maybe the diagnosis is incorrect, but there is enough information to help an expert get started. A mechanic can try to press the ignition button himself and quickly confirm whether it is a battery problem or not.

However, when you say it doesn't work, the mechanic doesn't know whether to check the air pressure in the tires, or if the engine needs to be taken apart. There isn't any information available.

When it comes to programming, just like a car, code can fail for a whole lot of different reasons. Debugging, or the process of asking questions we went through can help narrow down where the issue is. As programmers, we have the luxury of getting error messages when things don't work. They can still be cryptic, but it gives us a starting point to solving the issue.

If you find yourself writing “it doesn't work”, remember that it is a signal to start asking yourself questions.