The Rubber Duck: Explaining Code to Someone Who Doesn't Answer
A research assistant explained his code, line by line, to a rubber duck. The smallest check in a builder's workshop.
In October 1999 Andrew Hunt and David Thomas published The Pragmatic Programmer with Addison-Wesley, a book that offers no theory but a collection of tips for people who write software. Inside there is a tiny story. A research assistant, Greg Pugh, carried a rubber duck around. When a problem would not let itself be found, he set the duck in front of him and explained the code to it, step by step.
The duck did not have to say a word. According to the authors, the simple act of explaining what the code is supposed to do often makes the problem leap off the screen and announce itself. From that story comes a name now taught in computer science courses: rubber duck debugging.
A listener who does not interrupt
There is nothing magic in the mechanism. Whoever writes code holds two programs in their head: the one they believe they wrote and the one they actually wrote. As long as they stay silent, the first covers the second. When they have to say it aloud, one line at a time, in natural language, they are forced to compare them. At that point the difference shows.
A colleague would serve the same purpose, but a colleague interrupts, guesses, finishes your sentences for you. It is kind, and that is exactly the limit: they spare you the part of the explanation where the error was hiding. The duck guesses nothing and has to be walked all the way to the end. That is why it works better than thinking aloud with no audience: someone is there, even if made of plastic, and to someone you explain everything.
The variants are well known. Some use a teddy bear, some a pet; S. J. Baker even wrote about the contribution of a cardboard cutout dog to software reliability. The object changes, the rule stays: speak to a presence that will not help you.
The smallest ritual in the workshop
It interests me because it is a check, not a trick. In a builder's operating system some checks run on their own: tests, audits, routines that verify every morning that everything is still in place. And some checks cannot be automated, because the machine to be verified is your own understanding. The duck belongs to this second family. It does not find the error: it puts the writer in the position where the error becomes visible.
It holds beyond code. A chapter that does not stand, a procedure that seems clear, a message believed to be obvious: read aloud to someone who cannot pretend to have understood, they show their seams. Writing well is also this, accepting that the sentence we are surest of is the first one to explain.
On 1 April 2018 Stack Overflow made a joke of it, Quack Overflow: a duck in the corner of the screen listened to users' problems, pretended to type a solution and answered with a quack. It was a joke, but it told the truth. The answer had never been in the duck.
So a bath toy, hollow and mute, became a small workshop relic. Not for what it knows, but for what it forces you to say. It is the same idea beneath The Builder Operating System: a structure does not work in place of the builder, it makes visible what would otherwise stay hidden.
Sources: Andrew Hunt and David Thomas, The Pragmatic Programmer, Addison-Wesley, 1999; The Pragmatic Programmer and Rubber duck debugging, Wikipedia (accessed 20 October 2026).
> ln -s ./linked-nodes
- [PART OF] Builder Operating System
- [RELATED] The Builder Operating System
- [REFERENCED BY] The Mark II Moth: the Logbook That Corrected Memory
- [REFERENCED BY] The $2.56 Cheque: Donald Knuth and the Reward for Finding the Error