You've read the function four times and it looks correct. Then you start explaining it out loud, line by line. Somewhere along the way, you hear yourself describe something the code doesn't actually do. Most developers recognize that moment, and the habit has a name: rubber duck debugging.
It's one of the best-loved tricks in programming, and one of the least examined. So here is a debugging session on the technique itself, with the evidence in one column and our confidence in the other.
Symptom: A Technique Everyone Swears By
The idea is usually traced to The Pragmatic Programmer (1999) by Andrew Hunt and David Thomas. The book describes explaining a problem, step by step, to someone or something that doesn't need to answer, and reports that the act of explaining often makes the bug show itself. The name comes from a story in the book about a colleague who carried a rubber duck to talk to.
That's the claim. The next question is what supports it.
Reproducing the Result: What We Could Find
We looked for controlled studies of rubber duck debugging itself: programmers randomly assigned to explain code aloud or work silently, then compared on how fast or how often they fix the bug. In the sources we reviewed, we didn't find one. Plenty of articles describe the technique's success, but we couldn't trace those claims to a published experiment.
What exists instead is circumstantial: research on mental processes that look a lot like what the duck prompts. Three findings are worth knowing.
Explaining helps learning. A 2018 meta-analysis by Kiran Bisra and colleagues pooled 69 effect sizes from 64 research reports (5,917 participants) on prompting people to self-explain while studying or solving problems. The average effect was g = 0.55, a medium-sized effect on learning outcomes for people prompted to self-explain compared with those who weren't. The caveat matters: these were learners in educational tasks, with learning as the outcome, not professionals hunting a production bug.
Explaining exposes what you don't know. In 2002, Leonid Rozenblit and Frank Keil showed that people feel they understand complex things with more precision, coherence, and depth than they really do, which they called the illusion of explanatory depth. In their studies, participants rated their understanding of everyday devices and then tried to explain how those devices work. The exercise exposed gaps between how well people thought they understood something and how much they could actually explain.
Putting thoughts into words isn't always harmless. In 1993, Jonathan Schooler, Stellan Ohlsson, and Kevin Brooks found that asking people to verbalize their thinking made them less successful on insight problems, the kind where the solution arrives as a sudden restructuring. Their suggestion was that what's easy to put into words can overshadow what isn't. The result hasn't been universal: Jessica Fleck and Robert Weisberg (2004) had people solve the candle problem silently or while thinking aloud and found comparable solution rates.
Root Cause: A Hypothesis, Not a Finding
Put the pieces together and a plausible account emerges. A bug is a gap between what you believe the code does and what it does. Feeling that you understand the code isn't the same as having a step-by-step account that survives being spoken. The duck forces the second, and the bug tends to live where that account breaks.
To be clear about the status of this explanation: it's an inference from adjacent research, not a demonstrated result about debugging. The studies above concern explaining, not listening, so they say nothing about whether the audience matters. A duck might be doing real work, or it might simply be a prompt that gets you to talk.
There's a second hypothesis about why speaking might matter, and it's just as untested. In your head, you can jump between assumptions and skip familiar steps without noticing. Speech is linear: one sentence follows another, which may make it harder to glide past a step you'd otherwise take for granted. We haven't reviewed research that separates explaining aloud from explaining silently or in writing, so whether speaking adds anything beyond structured self-explanation is an open question.
Applying the Fix (If You Want to Try It Properly)
None of the following has been tested as a debugging protocol. These are reasonable applications of the research above.
- Explain what the code is supposed to do, not just what it says. Say the value you expect at each step before checking the next line. If a function receives [2, 4, 6], predict what each transformation should return. Don't just describe the operation; predict its output. Mismatches between expectation and reality are where bugs hide.
- Be causal and specific. "This handles the input" can sound true without being checkable. "This reads the string, splits it on commas, and returns the second item" can be checked against the code. Spelling out the steps is what shook people's confidence in Rozenblit and Keil's studies.
- Stop at the first mismatch. When your explanation and the code disagree, you've likely found something. Pause there instead of talking past it.
Known Limitations
- Missing information isn't a faulty mental model. If the bug comes from library behavior you've never seen or an environment difference you don't know about, explaining what you do know won't surface it. Reading documentation or instrumenting the code is the better move.
- Insight-style problems may behave differently. If the answer needs a sudden rethink of the whole approach, the verbal-overshadowing research suggests talking could sometimes get in the way, though the evidence is mixed.
- The research isn't about programmers. Every study above used learners or lab tasks, so the fit with real debugging is an assumption.
A rubber duck can't read your code. Whatever it does for you, it does by getting you to read it again, out loud and in order. That's a modest claim, and it happens to be the one the evidence can support.
Sources
- Hunt, A., & Thomas, D. (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley. — The book that popularized "rubber ducking" as a debugging practice.
- Bisra, K., Liu, Q., Nesbit, J. C., Salimi, F., & Winne, P. H. (2018). Inducing self-explanation: A meta-analysis. Educational Psychology Review, 30(3), 703–725. https://doi.org/10.1007/s10648-018-9434-x — Meta-analysis of 69 effect sizes (64 reports, 5,917 participants); average g = 0.55 for prompted self-explanation on learning outcomes.
- Rozenblit, L., & Keil, F. (2002). The misunderstood limits of folk science: An illusion of explanatory depth. Cognitive Science, 26(5), 521–562. https://doi.org/10.1207/s15516709cog2605_1 — Ten studies on people's overconfidence in their understanding of explanatory knowledge.
- Schooler, J. W., Ohlsson, S., & Brooks, K. (1993). Thoughts beyond words: When language overshadows insight. Journal of Experimental Psychology: General, 122(2), 166–183. https://doi.org/10.1037/0096-3445.122.2.166 — Verbalization interfered with insight problem solving.
- Fleck, J. I., & Weisberg, R. W. (2004). The use of verbal protocols as data: An analysis of insight in the candle problem. Memory & Cognition, 32(6), 990–1006. https://doi.org/10.3758/BF03196876 — Found comparable solution rates for the candle problem with and without thinking aloud.