By June 17, 2011

The Debugger Mindset

Today I want to talk to you about a serious mental disorder that affects far too many programmers.

The symptoms of this disease are many:

  • Frantically saying “It’ll work this time”
  • Randomly adding +1 and –1 to integers
  • Inability to see the forest
  • Irritability
  • Irrational paradoxical statements like “I am sure this is impossible, but I don’t know how it is happening.”
  • Screaming
  • Spitting at hamsters
  • The list goes on…

What I am talking about is the debugger mind set and…

It is a mental disorder

So what is this debugger mindset I am talking about?

It is more than just overusing the debugger, it is thinking and acting in a way that is the same way one tends to think and act when they are stepping through code in the debugger.

I am guilty of it as I imagine many of you are.

And it is a disease.


A debugging tale all too familiar

Picture this… You are just about to check in the final piece of code that you have been working on all week for this awesome feature you are developing and something is wrong.

It is just not working.  You can’t figure out why.  The behavior of the code seems to defy all logic.

You set a few break points and start stepping through code.  (By the way it is 4:00 on a Friday and you were about to check in this code and go home a little early, you deserve it.)

Step… step… step…  Check this variable… Check that variable… Evaluate this expression.

Nothing, no clue as to what is going on.  You are beginning to sweat.  The release is going out on Sunday.  You need to get this fixed or the code can’t release.

You look at the clock.  It is now 5:03.  You glance at your phone and see you have a text from your wife.  No time to look at what it says.  You are intensely focused.  You must solve this bug.

Step… step… step… Check this variable… Check that variable… Evaluate this expression.  You begin to sweat more.

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’re thirsty, you’re hungry, your eyes hurt from not blinking.  You’re tapping your foot like a madman intently focused on the keyboard.  It’s now 7:40.

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?

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."