Rubber Duck Debugging for Beginners
Five steps. One duck. Zero experience required.
You have a bug. You have been staring at it for twenty minutes. The code looks right. The logic looks right. But something is wrong and you cannot see it.
Pick up a rubber duck. Or a pen. Or a water bottle. And start explaining.
The 5 Steps
Step 01: Place the duck on your desk
Find any inanimate object. Put it where you can see it. This is your debugging partner. It does not need batteries, a subscription, or an internet connection.
Step 02: State the problem out loud
Tell the duck what your code is supposed to do. Not how it works. What it is supposed to accomplish. "This function should take a user's email and return true if they have an active subscription." Say it out loud. Hearing your own voice describe the goal sets the baseline for everything that follows.
Step 03: Walk through the code line by line
Start at the top. Read each line and explain to the duck what it does. "First, we query the database for a user with this email. Then we check if their subscription end date is after today. Then we return the result." Do not skip lines. The bug is almost always in the line you want to skip.
Step 04: Listen for the hesitation
At some point, you will pause. You will say "and then this should..." and trail off. Or you will say "wait, actually..." That is the moment. The bug lives in the gap between what you expected to say and what you actually said. The duck did not find it. You did, because you had to say it out loud.
Step 05: Fix the bug and thank the duck
Now you know where the problem is. Fix it. Run your tests. Thank the duck. The duck will not acknowledge your gratitude. That is part of its charm.
A Quick Example
Say you have a function that filters expired subscriptions but it keeps returning active users too. You sit down with the duck.
"Ok duck, this function gets all users from the database. Then it filters for users where the expiration date is before today. Wait. It is checking if the date is after today. That is the opposite of what I want."
Bug found. Time elapsed: forty-five seconds. The duck did nothing. You did everything.
Frequently Asked Questions
Do I need a real rubber duck?
No. Any inanimate object works. A coffee mug, a stuffed animal, a cactus on your desk. The rubber duck is traditional because it was popularized in The Pragmatic Programmer, but the object is not what matters. The explanation is.
Does rubber duck debugging work for non-programmers?
Yes. The technique works for anyone solving a complex problem. Writers use it to find holes in arguments. Mathematicians use it to verify proofs. Product managers use it to stress-test requirements. If you can explain the problem, you can debug it.
What if I feel silly talking to an object?
That feeling fades fast, especially the first time it actually works. You can also write your explanation instead of speaking it. The key mechanism is forcing yourself to articulate each step explicitly rather than skimming over assumptions.
How is this different from asking a coworker for help?
With a coworker, they often jump in with suggestions before you finish explaining. The duck never interrupts. Many developers find that the act of preparing to explain the problem to a colleague is what reveals the bug, before the colleague says a word. The duck cuts out the middleman.
Can I rubber duck debug with an AI chatbot instead?
You can, but it changes the dynamic. An AI responds, which can shortcut your own reasoning. The power of the duck is that it forces you to do all the thinking. Consider explaining to the duck first, then consulting the AI if you are still stuck.
Want to go deeper? Read the full explanation of rubber duck debugging, including the cognitive science behind why it works and how it compares to AI coding assistants. Or see the technique in action with 10 famous rubber duck debugging moments.
The Book Series
The Duck and the Injection is Book 1 of the Rubber Duck Debugging vibe coding picture book series. Coming soon.
See the Full Series