Advertisements
Posted by: jsonmez | 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.

debuggermindset

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?

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.
Advertisements

Responses

  1. But where do you find the hamster to spit on?

  2. Went through this, don’t want look back!
    Additionally drank so much coffee that I couldn’t even sleep after a 14h hour bug fix day *LOL*

    Very good points! Nice post!

    What about: Commit early, Deploy early, Show-off to your client early (related to small tasks)

    I would highlight tests more!
    #1 Writing tests beforehand, tends to lead to cleaner code, which means less mess to debug/read through.
    #2 Tests are executed faster than any debugging session.

    • Yep definitely agree with you there about the tests!

  3. I will be sharing this with coworkers on Monday. A followup with a list of previous blogs that pertain to automated testing and vertical slices would complement this very well.

    • Take a look at Getting up to Bat or the How to Build agile software tabs at the top of the page for those.

  4. […] The Debugger Mindset (John Sonmez) […]

  5. […] 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. […]

  6. Sometimes using a debugger is the best way to do things.

    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.

  7. 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!

    and as long as it works, i’ll use it!

    • Sometimes the debugger is the best option. Just like sometimes a chainsaw is the best tool.

      Likewise either one should not be the first tool reached for when solving a problem.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: