Why Explaining Your Code Out Loud Actually Finds the Bug
Rubber duck debugging isn't a joke about talking to a toy — it works because explaining code forces you to stop skimming it, and that's usually where the bug was hiding.
Every time I sit down to record a codeBetter lesson, I have to explain a concept out loud, start to finish, in a way that makes sense to someone seeing it for the first time — and more times than I'd like to admit, that process alone has surfaced a bug or a gap in an example I'd already looked at and thought was fine. That's rubber duck debugging, just with a camera instead of an actual rubber duck.
The technique's name comes from an old story about a programmer who kept a literal rubber duck on their desk and explained code to it, line by line, out loud, before asking a human colleague for help. The duck doesn't answer — it doesn't need to. The value is entirely in the explaining.
The reason it works is that reading code and explaining code use different parts of your attention. When you read your own code silently, you tend to read what you meant to write, because you already know what you meant — your brain fills in the intent and skims past the actual text. Explaining it out loud forces you to say what the code actually does, one step at a time, and that's usually where the mismatch between "what I meant" and "what I wrote" shows up.
It works best on the kind of bug where you've already been staring at the code for a while and nothing looks wrong — which is exactly the situation where silent re-reading keeps producing the same blind spot, because you're re-reading with the same assumptions that let the bug in in the first place.
You don't need an actual duck, or a lesson to record. Explaining the code to a colleague who has no context on the problem works the same way, and so does writing the explanation out as a comment or a message before you send it, then deleting it once you've found the issue — the value is in the act of articulating it, not in who or what is listening.
It's a genuinely low-cost thing to try before reaching for a debugger: no setup, no tooling, just the discipline of saying out loud, in order, what each line of code is actually doing instead of what you assumed it does.