Debuggers are great, they let you execute code step-by-step, examine values at runtime, see what’s really going on.
For all their benefits, though, they have a serious drawback. They make it easy for you to to stop thinking. Instead of understanding the “why” of a bug, they make you focus on the “what”. It’s easy to sink a lot of time into setting breakpoints, step-by-stepping, looking at values — but these are just tools, they are a proxy for discovering the root cause. Instead of using the proxy, it’s often faster, and more beneficial in terms of future growth, to think about what’s happening. Look at your error, and think: “How could this have happened? What conditions needed to line up to make this error manifest? What’s are the possible reasons this happened, and their corresponding likelihoods? Logic error? Type system didn’t have my back? Somebody recently touched the code? Unforeseen edge case?” Come up with a hypothesis, then prove or disprove it.
With using the debugger, it’s too easy to focus on the concrete, and even fix the bug, without understanding how the bug came about. And it does nothing to improve your mental modelling. Thinking through a bug, on the other hand, gets right at the “why” of things. With practice, this is a far faster way to fix bugs. More than that, it also builds your thinking in a way that will proactively avoid introducing new bugs in the future.
There are of course times when you are stuck and no hypothesis comes to mind. You need an input data point to get moving forward. Firing up the debugger for just a moment (or adding logging to production code), to get a foothold to start your thinking going, is fine in those cases.
Comments
Post a Comment