Paper debugging

Paper debugging is a tool I really like using. It's arguably the most low-tech approach - yet, it is surprisingly effective.

Take a pen and paper, or a whiteboard. Write up key variables and start to execute the code in your head. Write down how those variables change, one after the other. If you get stuck, ask someone else to follow things with you, to make sure you’re executing the code correctly, in your head.

This approach is especially powerful when you have access to a debugger. First, do paper debugging. Then, run the debugger and check if you ran the program correctly in your head. This approach not only helps you with debugging: it deepens your understanding of the code, and improves your critical thinking.

One of the most efficient ways I’ve found to help someone debug their code is doing paper debugging with them. I usually bring a pen and paper to their desk and ask them, “can explain to me what happens with the code and what might be going wrong, by drawing it down? Using boxes and arrows, in a way I can understand?” This simple technique forces people to take a step back from the details they are focusing on, and has them organize the big picture in their head - and on the paper.

In the worst case, the problem is still there, but now I also understand what the problem is, and where things go wrong. In many cases, however, midway to explanation, the person debugging has the “aha!” moment and finds the problem themselves.

When was the last time you used paper (or whiteboard) debugging?


Gergely Orosz

A hands-on engineering manager, previously developing across the stack for a decade. Working at the intersection of Silicon Valley and Europe. Currently at Uber. Microsoft, Skype & JPMorgan alumni.

Amsterdam, Netherlands