Daniel Compton

We cannot solve our problems with the same thinking we used when we created them. – Albert Einstein

In my (relatively short) career as a software engineer, I’ve seen a paradoxical behaviour among coworkers and myself: at the point when people most need better debugging tools, they are the least likely to use them.

This behaviour doesn’t seem to be exclusive to any one language, domain, or Operating System. The pattern I see is:

1. Get stuck with a bug
2. Try to debug the problem using the methods you’re comfortable with
3. Keep going, getting more frustrated/nervous/impatient
4. Realise that you’re running out of time, and double down twice as hard on your current methods.

It’s steps 3 and 4 that are most interesting to me, and where the paradoxical behaviour occurs. I can think of a few reasons for why people do this:

• When you are debugging something, you will usually spend some time debugging it with your normal methods. By the time you realise that you are stuck, you may be behind schedule, so you double down on your existing method.
• When you don’t feel like you have enough time, you are not as likely to explore alternative tools and debugging approaches.
• Often when debugging you can feel like the answer is just around the corner (even if it’s still a few hours away).
• If you’re already neck deep in one confusing situation, adding a new unfamiliar tool doesn’t seem like it will help.

I’m not sure if there is a good way to combat this problem in the heat of the moment. Two solutions I can see:

1. Try debugging with someone more experienced than you who is familiar with these tools. As a bonus explaining the problem to them may help you solve the issue.
2. Invest in learning new debugging tools ahead of time. Debugging a problem is a really stressful situation, particularly if you are under time pressure, so having your tools and techniques practiced and ready to go beforehand can be helpful here. Athletes and musicians put in hours of practice before they actually perform, I think Software Developers could take a lesson from them.