Debugging mindset – how to reason during debugging

Have the right debugging mindsetDebugging is a large part of Software Engineering, and it’s really important to have the right debugging mindset. Debugging itself is a wide subject. It’s something you think everyone knows, but in the real world everyone has to reinvent the wheel themselves.

It starts like this:

There is a problem with my code, and I want to fix it.

That’s one way to look at it. Another way is to say

There is something I don’t know about my source code.

There is something left for you to learn! Be interested. While I’m searching for the problem, I tend to fiddle a little bit with the code. Rename some variables, move functions from one class another or reduce visibility from a method from public to private (if it’s possible). This helps me understand*.

Next to really understanding what is going on, there is another thing that has to be part of your debugging mindset. You have to assume the code is wrong, even if you’ve written it yourself and it’s beautiful. If there wasn’t something wrong with the source code, you wouldn’t be debugging right now**. You have to feel responsible for solving the problem at hand.

Part of your debugging mindset: be relaxed

Another thing about your debugging mindset is that you have to be relaxed. It’s something that’s hard to do in a hurry. It’s about understanding the situation, and making a hypothesis about what is wrong. You should feel confident about this hypothesis. It doesn’t happen often that the hypothesis that you make is wrong.

Be a little bit suspicious  Someone might have tried to make a fix for this problem at a different location, this fix might stop your real fix from working.

The next step is to gather a lot of data. Data can come from a lot of sources

  • The compiler. Configure it to the pickiest level of error reporting. Fix every error, warning and even all the notices. If you get many errors, fix the first error first. Don’t trust the ones coming after, since they are unreliable, and might be just followups from The First One.
  • Tracing with a debugger
  • Log statements
  • Unit-tests

There might be cases where all of this isn’t even enough. Sometimes you won’t find the cause straight away, because you get a non-precise error message. In that case you should think what you want to know, and then improve the error message, or enhance (or introduce) logging. This is closely related to defensive programming.

And with that bombshell it’s time to end the first part about debugging. Right now it might feel a bit vague, but go on to part 2: real life debugging!

* Not everyone thinks this is a great idea though, see refactoring legacy code.

** Unless of course you are that one person who finds the bug inside the vendor code.

5 thoughts on “Debugging mindset – how to reason during debugging

  1. I don’t know whether it’s just me or if everybody else experiencing
    issues with your website. It appears as though some of the written text in your posts are running off the screen.
    Can someone else please comment and let me know if this
    is happening to them too? This may be a issue with my browser because I’ve had this happen before. Thank you

  2. Thanks for ones marvelous posting! I seriously enjoyed reading it,
    you will be a great author.I will ensure that I bookmark
    your blog and will often come back from now on.
    I want to encourage you continue your great work, have
    a nice afternoon!

  3. My partner and I stumbled over here from a different
    website and thought I may as well check things out. I like what I see so now i’m following
    you. Look forward to exploring your web page for a second time.

    Also visit my blog post; youtube

  4. I’ve been surfing online more than 4 hours today, yet I never found any interesting article like yours.

    It’s pretty worth enough for me. In my view, if all web owners and
    bloggers made good content as you did, the web
    will be much more useful than ever before.

Leave a Reply

Your email address will not be published. Required fields are marked *