Debugging is Uncomfortable

Yesterday I ended by reminding you that frustration is the enemy of effective debugging. I wouldn't even need to tell you this if debugging wasn't inherently uncomfortable. It's uncomfortable because no one likes not knowing what's going on, and that's what debugging is, by definition.

Consciously or unconsciously, you want to get to the right answer. You probably have at least 12 years of schooling under your belt that was all about finding correct answers, and that kind of conditioning can't be unlearned quickly. But debugging is not about finding correct answers, it's about learning to better understand your code. A bug in your code represents a misunderstanding of either requirements or of program behavior. 90% of your work when you debug is about finding and clarifying that misunderstanding.

This may sound like semantics, but there's a fundamental difference to how you approach solutions when you're trying to find the right answer vs trying to fully understand. In the former case, you're going to be quicker to implement an idea for a fix, and less likely to test it rigorously. You might call a bug fixed as soon as you see correct behavior, without stopping to think about other related ways this bug could manifest.

In the case of trying to understand, you're constantly testing your own assumptions and actively trying to disprove your own theories. A disproven theory is new information and new information leads to better understanding. The better you truly understand why a bug is occurring, the more likely you are to get to the root cause of it and implement a robust fix.

Learning to not get attached to your theories and to withstand the discomfort of disproving them is an acquired skill, but a necessary one for effective debugging.

More tomorrow.

Next Up:
Theories are Time-Consuming

Previously:
How Do You Define the Term 'Bug'?