The six R’s of debugging

The six R’s of debugging

In Modeling and Simulation yesterday I presented my six R’s of debugging:

Read: You have to read the code, and read what it really says, not what you think it says.  You have to read the documentation, read the error message, and read the Stack Overflow page that comes up when you Google the error message.

But sometimes the bug is in your head.  If the problem is your misunderstanding, you won’t find it by staring at the code…

Run: You also have to run the code, makes some changes, and run the code again.  Sometimes when you clean up the code, and you make a change that should have no effect, and it does, that gives you a hint.

But don’t just make random changes…

Ruminate: Take time to think!  What have you changed since the last time you had a working program?  What is the program doing wrong, and what kind of error could cause it?  What are you assuming that might be wrong?

Question everything, but don’t just sit in silence…

Rubber duck: You have to talk about it.  Find someone who’s willing to listen and explain the problem.  You might figure it out before they have a chance to say a word.  In that case you don’t even need a person.  A rubber duck will do.

Be persistent, but not too persistent…

Rest: If you’ve been at it a while, take a break.  Get away from the computer, do something else, and wait for your blood pressure to come down.  Some of the best places to find bugs are trains, showers, and bed, just before you fall asleep.

Finally, if you are pretty much stuck, you might have to be strategic…

Retreat: Get back to a previous working version and start building up the code.  Take smaller steps this time, or take different steps.  Spend some time building code that helps you debug, like functions that visualize your data structures.

I hope these suggestions are helpful.  There are six things to try, so if you are stuck on one, try another.  Debugging can be frustrating, but it is one of the most useful skills you can develop, and it applies to almost every domain, not just software development.

If you are good at debugging, you can do anything.

2 thoughts on “The six R’s of debugging

  1. These are great tips! I would especially highlight the ‘ruminate’ part about questioning your assumptions. It’s so easy to fall into a trap here. For instance, in C 100 + 100 can easily be -56 if you’re using 8-bit integers! (I use C a lot for embedded systems programming).

    I’ve found that one way to proactively prepare for diagnosing errors is to keep refining my mental model of a system. If there are a lot of parts to the system (programming modules, network connected components, sensors, etc.), it is good to map it all out and recognize which parts look like a black box (beyond the API) and which parts you understand more deeply.

    A couple years ago I read a book by David Agans on debugging (, and it helped me to approach this more methodically.

  2. Rest is a big one: the number of times I’ve stood up, gone to make a cup of tea and realised what was wrong must be huge.

Comments are closed.

Comments are closed.