Home » none » The Secret to Debugging . . .

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 …

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • Tracking Down Performance Issues in ASP.NETTracking Down Performance Issues in ASP.NET Last night, one of my clients assigned me a problem that I thought was going to require one solution, and in the end it was just poor programming. But the process reminded me of the need […]
  • How to Excel as a Programmer (or anything else)How to Excel as a Programmer (or anything else) From a very early age we have been conditioned to fail. I know that probably seems harsh, and probably seems like an over generalization, but it is true. Here are some things you can […]
  • Watching Trends = Job SecurityWatching Trends = Job Security I’ve been programming for 21 years now.  Most of my career I’ve spent being on the bleeding edge.  This has helped when it came time to find work because I normally am one of […]
  • What’s In My Blogging Toolbox?What’s In My Blogging Toolbox? So as I thought this week about what I might write, I decided to review the various tools that I use to get stuff done.  I started this post with the stuff I use to create the blog […]
  • Cracking the Programmer’s Interview CodeCracking the Programmer’s Interview Code Several comments this week contribute to this week’s post.The first, and the one that pushed me to write this post, is a discussion over at Simple Programmer on a post called “Cracking […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.

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

  • http://www.conqueredpasture.com ramil

    I agree with you as well, Dave. :)