Rubber Duck Debugging Works Because Your Brain Is Lazy

Everyone's heard of rubber duck debugging: explain your bug, line by line, to a rubber duck on your desk, and somewhere around line twelve you go "oh." It sounds like a joke. It isn't, and knowing why it works makes it a lot more useful.

When you read your own code silently, your brain cheats. It already knows what the code is supposed to do, so it fills in the gaps with intent instead of reading what's actually there. You see if (user.isActive) and your head hears "if the user can log in," even though isActive was set by a migration three years ago and means something else entirely.

Explaining out loud breaks the cheat. Speech is serial. You can't say "and then it does the thing" to a duck without noticing you have no idea what "the thing" is. Every assumption has to be turned into a sentence, and a wrong assumption sounds wrong once you hear it.

A few ways to get more out of it:

• Explain the data, not just the code. "This variable holds..." is where most bugs hide. Say what the value is at each step, not what the line does.
• Start from the symptom and walk backward. "The page shows 0. That number comes from total. total is set here, which means..."
• Write it down if talking feels silly. A draft Slack message to a coworker you never send works just as well. Half of my "quick questions" never get sent because typing them answered them.
• Say "obviously" out loud and then check it. The things that feel too obvious to verify are exactly the ones you skipped.

The duck doesn't know anything. That's the point. It forces you to stop relying on what you already believe and look at what's really there.