A developer is stuck on a bug for an hour, walks over to a colleague, starts explaining it, and halfway through the sentence says "oh, never mind, I see it" and walks back. Everyone in software has done this. The Pragmatic Programmer named the trick: keep a rubber duck on your desk and explain your code to it, line by line, and you'll find the bug yourself. It sounds absurd. It works, and the reason is worth understanding.
Key Takeaways
- Rubber-duck debugging: explain your problem aloud, line by line, to an inanimate object, and the act of explaining surfaces the bug (rubber-duck debugging).
- It comes from a story in The Pragmatic Programmer (1999) (the origin).
- It works through metacognition: explaining forces you to examine your own reasoning (why it works).
- The gap it exposes is between what you meant to do and what you actually did.
Why It Works
The mechanism is metacognition, thinking about your own thinking (why rubber-ducking works). When you're stuck, you're usually reading the code the way you intended it to work, so your eyes slide past the line where intention and reality diverge. Explaining it out loud, forced into complete sentences for an audience, breaks that. You have to articulate what each line actually does, not what you meant it to do, and the moment those two things disagree, the bug jumps out. Vocalizing engages a different, more deliberate mode of reasoning than silent scanning (the rubber-duck method).
The duck matters more than it seems. Explaining to a person works too, that's why "can I borrow you for a second?" so often solves itself, but the duck removes the need for another human's time, and it also removes the social pressure to sound smart, so you explain more honestly and completely.
The Deeper Point
Rubber-ducking reveals something general about how understanding works: you often don't know what you don't understand until you try to explain it. A vague mental model feels complete in your head and falls apart the instant you have to put it into words. That's why explaining is one of the fastest ways to find the holes, in a bug, a design, or a plan.
| Staring at the code | Explaining it aloud |
|---|---|
| Reads intention, not reality | Forces you to state what it actually does |
| Silent, fast, shallow | Deliberate, articulated |
| Eyes slide past the flaw | The flaw has to be said out loud |
| Can loop for an hour | Often breaks in a sentence |
A Concrete Version
An engineer spends 45 minutes convinced a function is returning the wrong value because of a library bug. She starts writing a detailed message to a teammate explaining exactly what she passes in, what she expects, and what she gets. Three sentences into describing what she passes in, she realizes she's passing the arguments in the wrong order. She deletes the message. The "library bug" was her own, and the act of explaining it, not any new information, is what revealed it. The library was innocent the whole time.
The Honest Counterpoint
Rubber-ducking isn't a universal solvent, and treating it as one wastes time. It's excellent for bugs rooted in your own reasoning, the wrong assumption, the overlooked line, the mismatch between intent and code, which is a large share of everyday bugs. It does much less for problems that need information you simply don't have: an undocumented behavior in someone else's system, a race condition you can't reproduce, a bug that lives in a dependency's internals. For those, the duck won't help, and the right move is data, observability, a debugger, or a genuine expert. Know which kind of stuck you're in.
What This Means for Teams
The habit behind rubber-ducking, being able to explain your own reasoning clearly, is one of the most valuable and underrated traits in an engineer, and it's why it shows up in hiring. Asking a candidate to talk through their thinking on a real problem reveals whether they actually understand it or are pattern-matching, exactly what a good structured, work-sample interview is designed to surface. It also underpins strong async, written engineering cultures: a team that writes clear explanations debugs itself, because half the answers appear while writing the question. See available engineers.
Frequently Asked Questions
What is rubber-duck debugging?
A technique from The Pragmatic Programmer: explain your code aloud, line by line, to an inanimate object like a rubber duck. The act of explaining forces you to examine what the code actually does and surfaces the bug.
Why does explaining to a duck work?
Metacognition. When stuck, you read code as you intended it, skimming past the flaw. Explaining out loud forces you to state what each line really does, and the bug appears where intention and reality diverge.
Why not simply explain to a person?
You can, and it works, which is why asking a colleague often solves the problem before they answer. The duck just removes the need for someone else's time and the pressure to sound smart, so you explain more honestly.
When doesn't it help?
When the problem needs information you don't have: undocumented behavior in another system, an unreproducible race condition, or a bug inside a dependency. Those need data, observability, or a real expert, not a duck.
The Bottom Line
Explaining a bug out loud solves it more often than staring harder, because articulation forces you to confront what your code actually does instead of what you meant it to do. Keep a duck, or a willing teammate, and reach for it when the stuck is in your own reasoning. The same skill, explaining your thinking clearly, is what makes engineers and whole teams get unstuck faster.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
