The Secret to Debugging . . .

Once again, this post comes out of a conversation I had recently.  You see, I have someone doing some work for me who’s just starting out in the programming field.  Well, he’s just starting out relative to me.  He’s actually pretty darn good.

As I was discussing a solution with this programmer I said something to the effect of, “Keep in mind that a lot of times, the easiest way to find a solution is to find out what the code IS doing.”

You see, he was having trouble trying to get the code to do what it was suppose to.  I took the code, worked with it for a couple hours and came up with a solution.

Now, to be honest, the fact that I was able to come up with a solution at all is due in a large part to the fact that I have over 20 years of experience programming in various languages.

But, I’ve always had a knack for being able to solve problems.

I don’t think I could have articulated it quite that way before then, but that really is the key to being a successful programmer.  Find out what the code is doing and work with it, rather than trying to force it to do what you think it ought to be doing.

My experience is that many programmers decide on a solution too early and when it doesn’t work like they expect, they assume it is a bug in the solution rather than the wrong solution.

Instead, what they ought to be doing is testing their assumptions.  Run the debugger.  Set a break point.  Do you even get to that line of code?  Is the variable set to the value you expect?  Are you handling the right event?  What other variables are available to you?  Is there a property hanging off some other object that you can access?

In some cases, you might have to step through each line of code one at a time.

I had a situation several years ago now (back when C++ was just getting popular) where I was given a huge routine to debug.  First mistake was the length of the routine.

I tried several times to just set a break point and figure it out from there.  But this was a loop in a loop in a loop.  The problem ended up being that they used i, j, and k for iteration variables but they had an inner IF condition that reset the i variable.  Something that you literally can’t see unless you step through each line of code.

So, if you are trying to solve a bug today.  Ask yourself, what assumption are you making that needs to be validated?

Other places talking about debugging:

  • Advanced JavaScript Debugging Techniques – The purpose of this article is to provide a list of advanced debugging techniques that are not easily found elsewhere on the web. Using Google to search for JavaScript debugging just gives you hundreds of articles about using alerts and …
  • How to debug a solution containing multiple projects. – Php and creating solutions with multiple projects inside, i decided to write a little blog article / tutorial on how to make debugging possible when using a multi-project solution. The way my solutions are structured, each project is a …
  • Stop tracing and start logging – Debug information with the good old “trace” is around since ActionScript 1 and has been heavily used as this was a key for debugging a Flash application. In AS3 trace has lost its importance as Flash Player 9 supports Runtime Exceptions …
  • Debugging .NET Framework Source Code – I’m currently debugging some issues with an application written against the .NET Framework version 3.0 and today I found an interesting blog post by Shawn Burke where he describes how to configure visual studio 2008 to allow the …

Most Commented Post

2 Responses to “The Secret to Debugging . . .”

  • steve ruddell:

    i have found this to be true too, especially when i’ve been at it for a few hours; that’s usually when i’m too narrowly focused and am blind to those assumptions.

    stepping away for a bit helps, but like you said, what needs to be done is to patiently observe, often step-by-step, what is *actually* happening. that usually helps reveal that what i assumed was happening, was not.

    i’d add that this is especially true if working by oneself. if i can get someone else to look at it, they essentially will do the same thing, just not assume what i have been taking for granted all along. i’ve also found in those conversations that as i describe what it should do, to someone who is fresh to the problem, and walk through the code with them .. that sometimes that brings those assumptions to light too.

  • I agree with you as well, Dave. :)