You can’t understand why this one little thing isn’t working. It is driving you nuts, it doesn’t make any sense… You start scratching at your head in frustration.

Time ticks by, it’s now 6:30. Your phone rings, it’s your wife.

“Did you get my text? When are you coming home? It’s Friday. It’s the weekend.”

You fumble to get to your SMS program on your phone. You don’t have time for this, you must SOLVE this bug, now! Grrr, you are getting angry and irritated. You try and hide it, but it comes through in your voice.

You start frantically changing variables. You’ve lost track of what the code is doing now, instead you’re just watching values in your watch window. It’s getting hard to think, minutes turn to hours.

You finally solve your bug at 11:03 PM, but your nerves are shot. The taste of victory is soured like milk left too long in the fridge. You can taste the chunky curds in your mouth as you think about how even though you fixed the problem, you still don’t understand why your solution worked or what was causing it.

It is very important to avoid this pattern of behavior

And it can destroy your productivity like nothing else.

You don’t actually have to be in the debugger to have this mindset, even though it often occurs when you are.

All developers are susceptible to it. I know I have spent my share of time thrashing around with it. It takes a fairly simple 1-hour-to-solve-problem and makes it take 8 hours to solve because we try to solve it in 5 minutes.

Very few things in life have a 5 minute solution.

When we start thinking this way, we lose all ability to think rationally and actually solve a problem. Instead we start zooming into symptoms and using frustration instead of wit.

This kind of mindset can put us into a downward spiral of burnout and insatiability. We end up wasting time and losing focus. It is the most frequent time in my career when I have made stupid mistakes.

How to avoid the debugger mindset

The is a perfect storm of conditions which tend to cause this kind of a mindset, mix and match these as you will:

A looming deadline (self-imposed or otherwise)

Large chunks of almost complete work that can’t stand on its own

Being in a hurry and looking for a shortcut

Believing a problem is probably simple

Believing a problem is probably hard

Jumping to the debugger too soon

Being at the end of a marathon session

Not taking enough breaks

There are many other conditions of course which can contribute to this mindset, but these are some of the ones I find most common. It can only take a few of these in combination to really push you over the edge into no man’s land.

Avoiding the debugger mindset can be as simple as trying to eliminate as many of these precursors as possible.

Here are a few tips I have found to directly counter this list above:

Don’t impose deadlines on yourself and try to ignore unrealistic ones that are imposed on you. Instead try to focus on doing a good job and being productive. You are much more likely to get fired for being in the debugger mindset and making a stupid brainless mistake than for taking a bit longer to accomplish a task or having to tell your boss that you cannot in good conscious commit to a deadline. Never forget that software development is always going to have a huge “unknowable” factor to it. No one can blame you for that and it is not your fault.

Try to commit as frequently as possible and divide your work into very small tasks.Smaller is better. Also try to split work vertically rather than horizontally. This means trying to implement a feature in terms of small working pieces that work end to end, rather than trying to implement all the functionality in a single layer at a time.

There are no shorcuts in programming. When you need time take it. Don’t forget to take time to quietly think about a problem. Quiet contemplation is work. It is not slacking off. Take a walk if you need to. Ask for a second set of eyes before you get into panic mode.

Do not make an assumption about a problem until you understand fully what the problem is. Don’t tell yourself it is easy, don’t tell yourself it is difficult, instead refrain from making a judgment call until you have enough information to do so.

Don’t prematurely go to the debugger. Always try to solve problems without the debugger first. Once you have gone to the debugger, you are much more likely to get sucked into the debugger mindset. If you do need to use the debugger, always have a hypothesis of what the problem is and use the debugger to confirm or deny it.

Do not use the debugger to help you understand what the code is doing. Instead use unit tests for that or refactor to make the code clearer. Divide and conquer the problem into a series of branching hypothesizes. Use the debugger only when necessary to confirm or disprove a hypotheses and then form a new one and repeat all the while remaining calm and understanding that you don’t know how deep a rabbit hole is until you go down it. (This StackOverflow question points out a fairly extreme view of what I am saying here, but I tend to agree with it more than I disagree with it. I won’t say never use the debugger, but I will say that I myself use it too much and jump to it too quickly.)

Take breaks and don’t work on the same piece of code for too long a period of time. As stated above, break your tasks into smaller tasks so that you are always near a checkpoint. If you are feeling frustrated, take a 5 minute break to clear your head and regain your focus.

What do you think? Have you ever been in the debugger mindset? What are some ways you avoid it?

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week. Also, you can follow me on twitter here.

[…] The Debugger Mindset – John Sonmez discusses the ‘Debugger Mindset’, an over reliance on the use of the debugger to get code to work, and discusses some of the other development anti patterns that this can lead to, sharing some ideas that can help you break out of this way of working. […]

Certainly as a maintenance programmer using legacy systems (particularly in VB6) that have dead-end code bases using a debugger to find the problem is the very best solution.

In fact the longer a product has been in development for, the more valuable a debugger is to actually find and fix issues.

Unit tests and documentation are great things, but they are most important in the early days. They allow you to build a solid program from the beginning. For those of us who are dealing with codebases which consist of hundreds of thousands or millions of lines of code that is going to be thrown out in a couple of years and which has already been abandoned as far as new work is concerned, a debugger will let us fix things and then focus on more important activities.

I’m with Stephen on this one. The points above are more like “words to live by”. Sure we’d ALL love to not impose deadlines and work at our own pace and have complete control of our environment. But life just doesn’t work that way. it just doesn’t.

Stepping through a debugger isn’t pleasant but it WORKS, especially when you’re trying to figure out someone ELSE’s code!