Rubber Duck Debugging: Why Explaining a Problem Out Loud Helps You Solve It

Greg Pugh, a research assistant, carried a rubber duck around so that he had something to explain his code to. Wikipedia’s account traces the name rubber duck debugging to that duck and to an anecdote in The Pragmatic Programmer by Andy Hunt and Dave Thomas. The method is to explain a stuck problem step by step to a listener that cannot answer back, until the step that does not do what you said shows itself, and nothing about it is specific to code.¹

The research behind it is better than the joke suggests. A 2011 meta-analysismeta-analysis: A study that combines the results of earlier studies on the same question into one overall estimate. Pooling makes the estimate more precise, but it cannot repair the studies it pools: a meta-analysis of surveys is still survey evidence.Full entry in the glossary found that people who explained their reasoning as they worked scored higher than people working in silence, while plain thinking aloud made no clear difference.² We found no study comparing a duck with talking to no one; as far as the evidence goes, its job is to make you explain. One pass takes five moves:

1. State what should happen.
2. Explain from the start, one step at a time.
3. Say why each step follows.
4. Compare what you said with what is there.
5. Change tack when the talking stops helping.

What is rubber duck debugging?

Rubber duck debugging, or rubberducking, is a debugging technique in which a programmer explains code step by step in plain language, aloud or in writing, to expose mistakes and misunderstandings. In the anecdote behind the name, the listener never has to reply: the explaining does the work.¹ The anecdote comes from The Pragmatic Programmer, published in 1999.³

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

Jeff Atwood, a co-founder of Stack Overflow, described the same effect in 2012. He wrote that many users had told him they solved their own problem while writing a thorough, detailed question for the site, and argued that the effort of walking an imaginary someone through the problem is what often leads to the answer.⁴ That is reported experience, not a study, but it shows the method is not limited to speech or to ducks.

The same move works outside code. A finance analyst can talk a stubborn spreadsheet total through cell by cell; a manager can explain why a project plan slips, week by week; a writer can tell an empty chair what each paragraph of a draft is for.

What is the rubber duck method? Five steps for any problem

The rubber duck method is to explain a stuck problem, in order and in full, to a silent listener, and to say both what each step does and why it should work. It slots into the “find the causes” stage of a step-by-step problem-solving process, and these five steps adapt it beyond code.

1. State what should happen

Before touching the details, say in one or two sentences what the result should be: “This total should match the bank statement” or “this paragraph should convince the reader the deadline is real.” A clear expected result gives every later step something to be checked against.

2. Explain from the start, one step at a time

Begin at the first line, cell or paragraph, and do not skip the parts you are sure about. Studies of the illusion of explanatory depth found that confidence in how well we understand something often runs ahead of what we can explain.⁵ In a spreadsheet, that means saying where each input comes from before saying what the formula does with it.

3. Say why each step follows

For every step, add “and this works because…” Explaining why a step was taken, as distinct from describing it, is the habit research has linked to better problem solving.⁶ When you cannot finish the sentence, you have probably found the problem, or the part you need to look up.

4. Compare what you said with what is there

Read the line, cell or sentence you just explained and check that it does what you said. Wikipedia’s entry describes this comparison between the explanation and what the code actually does as the point where inconsistencies show up.¹ A writer explaining a draft may find that the paragraph they described as the argument is not on the page.

5. Change tack when the talking stops helping

As a rule of thumb, stop after two full passes that turn up nothing. Write the problem up for a colleague, which means explaining it once more in a new form, or set it aside and come back later. Puzzles that need a new angle rather than a missing step are where talking can even get in the way.

One pass with the duck

• Say what the result should be
• Start at the first step, including the parts you are sure of
• For each step, say what it does and why it should work
• Check each step against what is actually there
• Note every point where you could not finish the why
• After two passes with no gap found, write it up or take a break

Why does rubber duck debugging work?

Rubber duck debugging works mainly because a full explanation forces you to state every step and the reason it follows, and that exposes gaps silent rereading skips. Three lines of research bear on it: the illusion of explanatory depth, the self-explanation effect, and the protégé effect. None of them tested a duck.

Each describes a different piece. The first accounts for why the error hides from you, the second for why explaining finds it, and the third for why a listener, even an imagined one, may make you try harder. Creative work, in the psychologists’ definition of creativity, is both original and effective, and debugging is work on the second half: checking that an idea does what it should.

Why the error hides: the illusion of explanatory depth

People feel they understand how things work far better than they can explain them, and the shortfall shows up only when they try. Yale psychologists Leonid Rozenblit and Frank Keil named the effect in 2002, calling it the illusion of explanatory depth after testing it in a set of 12 studies.⁵

In their tests, US students first scored their own grasp of everyday devices such as zippers and cylinder locks. After writing out, in steps, how each device works, they scored themselves lower. The drop was much larger for mechanisms than for facts, procedures or stories, and the authors suggest one reason: knowing what the parts are called can pass for knowing how they work together.⁵

Code and spreadsheets fit that description closely. You can name every function or formula and still not have traced how a value moves from one to the next. The site’s guide to the Feynman technique, which uses the same gap-finding to study, covers the illusion in more depth. For debugging, aim the explanation at how the parts connect, since names alone rarely hold the gap.

Explaining each step finds the gaps: the self-explanation effect

Explaining each step to yourself while you work through an example is linked to better problem solving. Michelene Chi’s team at the University of Pittsburgh in the US called this self-explanation after a 1989 study, funded by the US Office of Naval Research, that recorded students talking while they studied worked physics problems.⁶

The students who went on to solve problems best gave more than five times as many explanations per example as the weakest, saying why each step was taken and checking it against what they knew. With only eight students compared, the study shows that strong solvers explain more without showing that explaining made them strong.⁶ In a 1994 follow-up with 24 eighth graders at a US public school, students prompted to explain each line of a biology text gained more understanding than classmates who read it twice.⁷

The idea has held up more widely since. A 2018 meta-analysis of 64 research reports, led by Kiran Bisra of Canada’s Simon Fraser University, concluded that prompts to self-explain are a potentially powerful aid across a range of learning tasks; we read only its abstract.⁸

Explaining also changes what you look for. In three experiments published in 2010, Joseph Williams and Tania Lombrozo, of UC Berkeley in the US, found that people asked to explain while learning were more likely to discover the rule behind a pattern than people who described items or thought aloud. Describing was better for remembering details.⁹ A bug is often a broken rule, so when you talk to the duck, ask why each line should work rather than reading out what it says.

A listener may raise the effort: the protégé effect

The protégé effect is the finding that people try harder to learn for someone they are teaching than for themselves. A Stanford University team in the US, led by Catherine Chase, described it in 2009 after studies in which school pupils taught a computer character called a teachable agent.¹⁰

Eighth graders who believed they were teaching their own agent spent more time on learning activities, such as reading, and learned more than pupils using the same software for themselves, with lower achievers gaining most. The authors suggest that a protégé brings a sense of responsibility and some protection for the ego when things go wrong; the abstract is all we could read.¹⁰

A duck is a much thinner protégé than a character that reasons from what it is taught, so this is an analogy. It does offer a plausible reason the toy helps: it turns a private check into a small act of explaining to someone, and admitting a mistake to a duck costs nothing. If a toy feels silly, pick a stand-in that makes you want to explain clearly, such as a sticky note with a colleague’s name on it.

Does talking through a problem help?

Talking through a problem helps most when the talk is explanation. A 2011 meta-analysis by Mark Fox, Anders Ericsson and Ryan Best compared people who spoke while they worked with people who worked in silence, and the kind of talk decided the result.²

The study

Moderate evidence

Talk that explains versus talk that narrates: a 2011 meta-analysis

Plain thinking aloud, voicing thoughts as they come, had an effect on performance indistinguishable from zero. People asked to describe or explain their thoughts and actions scored higher than people in matching silent conditions. Every kind of talking went with longer task times.²

We had the abstract alone, which gives no size for the gain on any kind of task, so how much explaining helps with a real work problem is unknown.

There is a known exception. In four experiments published in 1993, Jonathan Schooler of the University of Pittsburgh in the US, with Stellan Ohlsson and Kevin Brooks, found that putting problem-solving into words hurt success on insight puzzles, the kind solved by a sudden shift in view; in the experiment that also tested step-by-step problems, talking made no difference to those.¹¹ The finding is contested: in a 2004 study of 58 undergraduates at Temple University in the US, thinking aloud made no clear difference on Duncker’s candle problem.¹²

Myth

Talking a problem through always helps.

Fact

Explaining tends to help on step-by-step problems. On insight puzzles, describing your strategies mid-task hurt solving in one set of 1993 experiments.

The duck suits logic errors, broken formulas and plans whose steps do not add up. When a problem needs a new way of seeing it and the explanation keeps circling, stop talking. Taking a break from a stuck problem is the better-tested move there.

How strong is the evidence for rubber duck debugging?

The evidence for rubber duck debugging is indirect. Its parts come from lab and school studies, mostly with students in North America, and nobody we found has tested the full method in workplaces. The two direct tests of a duck we found compare listeners with each other. In a 2023 study of 101 people at KTH Royal Institute of Technology in Sweden, people thinking aloud to a robot that signaled it was listening did no better, and rated the tasks no differently, than people talking to a giant rubber duck.¹³ A short 2024 conference paper from Japan reported that a doll duck that nods and asks questions helped users organize their thoughts; we read only the abstracts of both.¹⁴

Nothing in this evidence favors the toy over a colleague, a written question or an empty chair, so use whichever listener keeps you explaining to the end.

The bottom line

The part of rubber duck debugging with research behind it is the explanation: each step in order, with the reason it should work. The duck, chair or teddy bear helps you commit to that, though no test we found shows it beats talking to no one. Next time a formula, plan or draft refuses to come right, start from the first step and say why each one follows until you reach the step you cannot explain.