Is debugging a skill?

Erwin van der Koogh

Recently someone asked me how I came to be so good in debugging things. I was a bit startled by the question as I was not aware of it being something you could be good at. But some people are better at finding problems then others, so I guess it must be true. This is my attempt at trying to figure out what debugging is and how you can get better at it.

When I look back at my most successful debugging sessions there are three recurring themes:

  • Triage
  • Partitioning
  • Assumptions

Triage

When something goes wrong, there are usually a lot of other issues that are either caused by that failure or are related. My first priority when faced with multiple issues is to figure out which issue is most important to solve right now. Those are usually either issues that prevent all flows, or the most important happy flow, from functioning properly, or likely root causes of multiple issues.
This focus is needed because when you start debugging you usually run into errors in log files, stacktraces on web pages etc. Whenever you see anything that indicates a problem you can now ask yourself if it is related to the problem you are trying to solve or not and prevent being distracted by unrelated issues.

Partitioning

The next step is isolating the issue. Difficult debugging problems usually arise when things disappear or there is an unexpected flow in the logic. What I usually do is create an overview of the entire application and its related systems either in my head or scribbled on a piece of paper. With this overview in place you can find system or module boundaries where you can usually quickly check whether the problem is present at that location and zoom in on that.
So first figure out what application the unexpected happens, then what module, class and method level. Do not guess what method it will be and verify that.

Assumptions

There are two famous sayings related to assumptions. "Assumptions are the mother of all f*ckups" and "When you assume things, you make an ass out of u and me" and those are very true. Especially when debugging you need to be extremely careful to not make any assumptions. When 2 requests in a log file look the same, copy and paste them and manually verify them line by line or better yet, run a diff on them. Do not only look whether the request is sent, but is it a valid request? Assumptions are most likely the reasons you are in the mess in the first place, the only way to get out of it is to be mindful of them.

Forcing myself to answer the question and write this blog post has forced me to really think about debugging and going from unconscious competent to conscious competent, which is always a good thing. Please leave a comment if you think I have missed something, or if you have any practices that have worked for you.

Comments (1)

  1. Krishna - Reply

    September 27, 2009 at 5:32 pm

    We have a first leval web support team who escalates all the production/customer issues and problems.I ask all the possbile and relevant questions and listen to every single detail they give us.
    As you can imagine some of the issues are hard to recreate and knowing exactly the way to recreate always comes handy during the debugging sessions.So Ask and Listen as well!

Add a Comment