Rubber Duck Debugging
Explaining a problem aloud to an inanimate object to surface its solution.
Rubber Duck Debugging is the practice of explaining a programming problem aloud, line by line, to an inanimate object (canonically a rubber duck on the desk) when the explainer cannot see what is wrong with their code. The named practice was popularized by Andy Hunt and Dave Thomas in The Pragmatic Programmer (1999), which described an unnamed colleague who carried a small rubber duck for this purpose, but the underlying technique is much older — the protégé effect (you understand something better when teaching it) is well-documented in psychology and education research, and 'explaining the problem' has been a debugging technique as long as there has been programming. The mechanism is that articulating a problem in natural language forces explicit reasoning about assumptions, intermediate states, and expected vs actual behavior that internal thinking glosses over. The duck (or any non-judgmental listener) serves to externalize the explanation without the social pressure that explaining to a colleague would create. The technique remains common practice and has had genuine influence on how engineers think about reasoning aloud, with modern variants including journaling-as-rubber-ducking, talking-to-yourself-while-coding, and increasingly LLM-as-rubber-duck (where a language model acts as the listener and may also offer responses).
Core components
- Aloud explanation of problem
- Inanimate object (rubber duck or other) as listener
- Line-by-line walkthrough of code
- Articulation of assumptions and expected behavior
- Connection to the protégé effect in psychology
- Variants: journaling, self-talk, LLM-as-duck (modern)
- Distinction from explaining to colleague (no social pressure)
Primary use case
Debugging stuck problems; preparation for asking for help (often surfaces the answer before reaching the colleague); learning by teaching practice; complement to other debugging techniques; widely-cited cultural reference in programming.
Common criticisms
- Effectiveness varies substantially by problem type and individual debugging style
- doesn't substitute for systematic debugging tools and techniques (debuggers, logging, tests)
- can become procrastination disguised as productive work
- cultural quirkiness (literal rubber ducks on desks) is more memorable than analytically illuminating
- modern LLM-as-duck variants change the technique substantively — language models talk back, which alters the debugging dynamic in ways that are still being explored
- the underlying protégé effect is well-grounded but the rubber-duck branding is more cultural marker than methodological innovation
- works best for problems where explicit articulation surfaces hidden assumptions, less well for genuinely subtle bugs.
Lineage
- Siblings
- Code Review