Time to Hypothesize

Ok, so you've used the boundaries in your code to narrow down the location of your defect. The offending line is staring you in the face. It's time. It's finally time to form a hypothesis about the cause of the bug.

I use the term "hypothesis" very deliberately, because you want it to be testable, and you want to try to prove it wrong. Often, you'll look at a bad line of code and think that the fix is obvious, so you'll just quickly make the change, refresh the page, and expect to see your application behaving itself. There are two reasons that you should take a somewhat more deliberate approach.

First is that if it if your fix doesn't work, it's more likely to raise your frustration level if you were convinced beforehand that you were correct. A frustrated mind is not a clear debugging mind, and keeping emotional distance from the process is always to your benefit.

The bigger reason though, is that this moment has enormous potential to teach you something if you're open to it. If you're approaching this process with the goal of better understanding your code, this is the moment where you're going to gain that understanding.

Form a hypothesis about what you believe to be the problem, and what you expect to see when you apply the fix. When you apply your fix, don't go looking to see if everything is working on the surface, because it very likely won't be yet. First see if the component that you're working within is now behaving to spec. That is to say, check the nearest boundaries and see if things look right there before working your way out to see if the rest of the system is now working correctly. This will help you recognize if you are making incremental progress when you don't see a complete fix.

Nine times out of ten, what you actually see is going to be at least somewhat different than what you expected to see. This is just new, valuable information to begin forming your next hypothesis. Keep that emotional distance, and remember that this is when you are going to internalize some of your most valuable understandings, as long as you stay open to them.

More tomorrow.

Next Up:
Write it Down

Previously:
Reader Question


Want to impress your boss?

Useful articles delivered to your inbox. Learn to to think about software development like a professional.

Icon