Debugging in general is the act of fixing errors (called “bugs”) in computer code. Rubber duck debugging is the act of debugging by explaining your code to a rubber duck.
That’s a simple enough explanation, but why would you want to do that?
Have you ever heard the phrase, “If you can’t explain it to a six year old, you don’t understand it yourself”? The concept is that if you truly understand something, you can explain it to someone who knows nothing about it.
This isn’t just a test of understanding for concepts you already know are sound. You can use the power of explanation to find problems with concepts you came up with yourself. If you explain your logic to someone who knows nothing about it, you’ll be forced to start over from the logical beginning and explain in simple terms.
When you’re the one who created the logic, you can sometimes accidentally accept unreasonable assumptions without knowing it. If you then have to explain the logic, though, you’ll need to spell out your assumptions. And if those assumptions aren’t reasonable, you’ll know it right away.
The best part of this is that it doesn’t require a human. Your brain is good enough at personifying inanimate objects that explaining a concept to another human who simply isn’t replying is functionally interchangeable with explaining it to a rubber duck. So, a lot of programmers explain concepts to rubber ducks (or stuffed rabbits, in my case) instead of inconveniencing fellow humans.
So. What is rubber duck debugging? It’s using your brain’s powers of explanation and personification to fix logic problems.
Rubber duck debugging is hardly the exclusive domain of programmers. Anybody who can use language can explain something to a rubber duck (I don’t even have to say “anybody who can speak”, because I’m sure rubber ducks understand sign language). Writers do it to fix problems with their story plot, for example.
So if you’re ever working on a tricky problem, try stepping back and explaining it to a rubber duck.