Rubber duck debugging is a simple technique where a developer explains their code out loud, step by step, to find a bug. There is no clever tool involved. The act of slowing down and putting the logic into plain words is what reveals the mistake, often before you even finish the sentence.
The name comes from a well-known programming book where a developer kept a rubber duck on the desk and described each line of code to it. It sounds silly, but it works for the same reason that talking through a problem with a friend helps: you are forced to confront the gap between what you think the code does and what it actually does. That gap is where most bugs live, and it makes this one of the cheapest debugging habits a developer can build. It is also the everyday cousin of pair programming, where a second person plays the duck and talks back.
Why does saying it out loud help when re-reading silently does not? When you read your own code, your brain fills in what you meant, so you skim past the line that is actually broken. Speaking forces you to process each step in order, in full, with no shortcuts, and that is where an assumption finally trips over reality. Many developers notice the bug halfway through the explanation and never reach the end.
The listener can be anything: a colleague, a notebook, the actual duck. What matters is that you explain the logic as if to someone who knows nothing, because that is when your own hidden assumptions finally show.
At TopDevs we lean on simple habits like this alongside formal reviews, because a bug talked out in five minutes is far cheaper than one found in production.
