The Next Satisfactory Step #

Debugging your own code is hard. It challenges your mental models that led to the solution in the first place. You have to question every piece of code, even that one that makes you feel like you are very smart.

Debugging other peoples code is even harder because you don’t have the mental models that led to that conclusion. You are missing all the assumptions that the original author had when they wrote piece of code. So everything is under question. Paradoxically, it is also easier because you can look at it with fresh eyes. It can take you a few moments to fix or more time than to the original author.

In the beginning, when what is failing is unclear, you should make big swings until you stuck gold. The more satisfactory steps you take towards the solution the more precise the changes you make need to be in order to keep narrowing down the problem until the root cause is found. From commenting out huge parts of the code or big moving parts one at a time to changing the value of a single parameter.

When the process becomes difficult, in either cases, the only way to get unstuck is to start going in a direction and keep, while successful, going in that direction until a satisfactory solution is found. Keep track of all steps you have made. As soon as you hit a wall, take a step back and make a step in another direction. Success or failure? On success, you already know what to do. On failure, take another step back and repeat the process.

In some situations, you will have to go back to the starting point and in very rare occasions you will have to go back to the starting point a few times before you identify the root cause of the problem. Change the angle from which you look at the problem. Sometimes is helpful to forget things you have discovered during earlier attempts because they might be keeping you stuck. But don’t despair, as each time you take a step, be it forward or backward, is a step in the direction that will eventually lead to the successful conclusion.

It’s is far worse to not want to challenge yourself to go back to the beginning and get stuck attempting to fix the problem at wrong point. Even worse than that is implementing a fix at the wrong point and strongly advocate that is the right fix only because you didn’t want to challenge your assumptions.

Treat the process not a maze but as one dimensional line made of blocks. This way you can never go back but always forward towards the solution.