Have you ever stared at code for hours because a program was behaving strangely, and then asked the colleague next to you for help? Curiously, in the middle of explaining “I take this value here, then pass it on like this…,” you often find the answer yourself: “Oh, this is where it’s wrong.” All your colleague did was nod. Among developers, a method that deliberately makes use of this phenomenon has been handed down for a long time. It is called ‘Rubber Duck Debugging.’
Simply put, rubber duck debugging means ‘a debugging method in which you find problems by explaining your code, line by line and out loud, to a rubber duck toy on your desk.’ The listener does not have to say anything at all; the very process of explaining brings out the misconceptions and gaps in your head.
In this article, we will look in turn at where the name rubber duck debugging came from, how to actually do it, why explaining exposes problems, and tips for using it beyond development in everyday life.
Why Talking to a Duck Reveals Bugs
The Story Told in The Pragmatic Programmer
The name spread widely through The Pragmatic Programmer, a software development book published in 1999. Co-written by Andy Hunt and Dave Thomas, the book is still a classic recommended by many developers.
- The Protagonist of the Anecdote (Greg Pugh): According to the book, a research assistant named Greg Pugh always carried a rubber duck around, and whenever he got stuck on a problem, he explained it to the duck.
- The Book’s Explanation (Explaining the Problem): The book notes that the listener does not need to say a word; simply explaining step by step what the code is supposed to do often makes the problem leap off the screen on its own.
- Other Objects: It does not have to be a duck, and there are stories of people explaining to teddy bears, pets, or even a cardboard cutout of a dog.
In the end, the key is not the duck as a prop but the act of explaining something to someone from beginning to end.
How to Explain Line by Line, Out Loud
Because rubber duck debugging is so simple, it is important to follow the steps in order. It roughly proceeds in the following three steps.
(1) Tell the duck the goal first
First, explain in one or two sentences what this code is originally supposed to do. The moment you put the goal into words, you may discover that you misunderstood the requirements from the start.
(2) Read line by line without skipping
Read the code from the top, line by line, saying out loud what each line does and what value each variable is likely to hold. Explaining, without exception, the parts you used to skip over thinking “this will obviously work” is the heart of this method.
(3) Compare your words with the actual results
Look for the point where what you explained diverges from what the program actually produces. Usually, that divergent line is exactly where the bug is hiding.
At this point, rather than reading only in your head, it is better to actually move your mouth and speak, or if that is difficult, to write it down in sentences. Speaking out loud naturally slows you down, so you end up rechecking even a single comma or the direction of a single inequality sign that you would have glossed over when scanning with your eyes. In places where it is awkward to talk, such as an office, writing your explanation down in a notepad has the same effect.
The duck is an audience that listens as if it knows nothing. That is why the effect grows the more you assume the listener knows nothing at all and break things down in very simple words.
Why Explaining Reveals Problems
When you think only in your head, you automatically skip over the parts you believe you already understand. To explain in words, however, you have to lay out your thoughts one by one, in order.
- Exposing Gaps (Explicit Reasoning): Speech is slower than thought and clearly sequential, so the gaps in logic you were loosely stitching together in your head are laid bare.
- Shift in Perspective: When you are in the position of explaining to someone else, you look at the code again through the eyes of someone seeing it for the first time, not the person who wrote it.
- Self-Explanation Effect: In the learning sciences, research has consistently reported that students who try explaining what they have learned to themselves build a deeper understanding.
In particular, bugs often hide not where the code is wrong but where you believe ‘it can’t possibly be wrong.’ As you explain, you have to state the grounds for that belief, and the moment you cannot give those grounds is exactly the point to look at again.
It is also interesting that it works better when there is someone to listen than when you just mutter to yourself. Even with only a duck in front of you, you feel you have to explain properly, so you speak without leaving anything out.
Using It Beyond Development in Everyday Life
Rubber duck debugging has now become something of a symbol of developer culture. Harvard University’s introductory computer science course CS50 added a duck character to its course tools, and the Q&A site Stack Overflow brought laughs on April Fools’ Day 2018 by launching a duck that listened to users’ questions and responded only with “quack.”
This method works just as well for problems that are not code. When the logic of a report gets tangled, when you are stuck on a math problem, or when a presentation does not flow smoothly, putting an empty chair or a stuffed toy in front of you and explaining from the beginning makes the sticking point clear. If you explain to the duck before sending a question to a colleague, you will often find the answer yourself, and even if you don’t, your question will become much clearer.
Some mistakes only become visible once you put them into words. The habit of patiently talking a stuck problem through to a duck is the first step in solving problems by finding the answers yourself.
