Home/ Questions/Q 166501
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T12:06:32+00:00

What’s your standard way of debugging a problem? This might seem like a pretty

  • 0

What’s your standard way of debugging a problem? This might seem like a pretty broad question with some of you replying ‘It depends on the problem’ but I think a lot of us debug by instinct and haven’t actually tried wording our process. That’s why we say ‘it depends’.

I was sort of forced to word my process recently because a few developers and I were working an the same problem and we were debugging it in totally different ways. I wanted them to understand what I was trying to do and vice versa.

After some reflection I realized that my way of debugging is actually quite monotonous. I’ll first try to be able to reliably replicate the problem (especially on my local machine). Then through a series of elimination (and this is where I think it’s problem dependent) try to identify the problem.

The other guys were trying to do it in a totally different way.

So, just wondering what has been working for you guys out there? And what would you say your process is for debugging if you had to formalize it in words?

BTW, we still haven’t found out our problem =)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. My approach varies based on my familiarity with the system at hand. Typically I do something like:

    1. Replicate the failure, if at all possible.
    2. Examine the fail state to determine the immediate cause of the failure.
    3. If I’m familiar with the system, I may have a good guess about to root cause. If not, I start to mechanically trace the data back through the software while challenging basic assumptions made by the software.
    4. If the problem seems to have a consistent trigger, I may manually walk forward through the code with a debugger while challenging implicit assumptions that the code makes.

    Tracing the root cause is, of course, where things can get hairy. This is where having a dump (or better, a live, broken process) can be truly invaluable.

    I think that the key point in my debugging process is challenging pre-conceptions and assumptions. The number of times I’ve found a bug in that component that I or a colleague would swear is working fine is massive.

    I’ve been told by my more intuitive friends and colleagues that I’m quite pedantic when they watch me debug or ask me to help them figure something out. 🙂

    • 0