Rubber Duck Debugging

Dutch artist, Florentijn Hofman’s giant rubber duck tours in Taiwan in 2013

1. Where did it start, and why?

Debugging. We’ve all been there. It can be dreadful and frustrating, but we know staring at the screen won’t solve the problem. Instead, stepping away from the code might. Or maybe hiring a rubber duck from Amazon and having it stare at the code for you might do the trick. What does rubber duck have anything to do with code? Nothing. Absolutely zero relation. It just sits there and watch you screwup repeatedly until you get it right.

“A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else… They do not need to say a word: the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself.”

— Andy Hunt and David Thomas, The Pragmatic Programmer

So how does it work and why? Two programmers Andy Hunt and David Thomas wrote a book called The Pragmatic Programmer. Together they introduced the term rubber duck debugging as one of the methods of debugging code. Rubber duck is not some new idea or a groundbreaking debug method. Rather, it’s something that everyone was already doing, but didn’t have a name for it. Even before rubber duck came into the picture, we would talk to ourselves, friends and people around us. There are all sorts of variations. Many programmers have had the experience of explaining a problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem. The Pragmatic Programmer touches on cognitive science behind this phenomenon. What is interesting is that when you think a thought to yourself and have that little voice in your head, that’s one thing that uses only one set of neural pathways and one set of neural processes. If instead you actually say it out loud, that activates entirely different regions of the brain, taking a totally different route.

So one of the things that this book advocates is that when you’re trying to learn something, one way to help strengthen memory and connection is to activate as many different pathways as you can. That’s why hand-writing notes can be more effective than simply just typing them all. Similarly, saying something out loud is different than just running it over in your head. For instance, teaching something to another person is the best way to grasp the concept. So this comes back to rubber duck concept. It actually does make a difference! When you lay things out and explain it out loud, you’re not only using a different set of processes in the brain, but also filling in the assumptions and holes in your reasoning. And of course, you’re quarter of the way through and you say ‘OHHHH I GOT IT!’

When you’re stuck on a problem, trying to debug something, whether that’s a bug in the code or some architectural decision, sitting and typing it to computer is the worst place you can be to figure it out. While you’re sitting there, your brain is locked in a symbolic representation mode of thinking, with characters coming back and forth and typing. That set of neural processes are not the same set of processes that gives you creativity, fusing different ideas together. Worst of all, they have the mutual exclusion and they fight each other! So when you’re sitting there, concentrating on little details like semi colons and curly brackets, you literally can’t see the big picture. You have to step back, put the duck between you and the monitor and get your thoughts out.

Speaking to a rubber duck that knows nothing about coding sounds simple, but we often take for granted what we can achieve by explicitly stating things to another person when we code by ourselves. By verbalizing your assumptions, you may immediately gain new insight into the problem. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent. More generally, teaching a subject forces its evaluation from different perspectives and can provide a deeper understanding. By using an inanimate object, the programmer can try to accomplish this without having to interrupt anyone else.

2. Quack (Overflow)!

Duck, Quack Overflow

On April 1, 2018, Stack Exchange introduced a rubber duck avatar on their websites as a new feature called Quack Overflow. The duck appeared at the bottom right corner of the browser viewport, and attempted to help the user by listening to their problem. However, the duck merely produced a quack sound as a response to user’s thinking input. Some confused users seeing the duck for the first time thought it was a malware program in their computer before realizing it was only an April Fools’ Day joke.

Note: Stack Exchange has annual April Fools Day pranks every year, since 2014.

3. How to rubber duck debug

1. Beg, borrow, steal, buy, or otherwise obtain a rubber duck.
2. Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.
3. Explain to the duck what your code is supposed to do, and then go into detail and explain your code line by line.
4. At some point you will tell the duck what you are doing next and then realize that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

Note: In a pinch a coworker might be able to substitute for the duck, but it is often preferred to confide mistakes to the duck instead of your coworker.

4. If you’re too lazy to hire a rubber duck…

Here’s one virtual duck you can use: http://duckie.me/#

Resources

https://www.nceclusters.no/globalassets/filer/nce/diverse/the-pragmatic-programmer.pdf…