The idea
Rubber duck debugging is the habit of explaining a problem, in detail and out loud, to something that cannot answer back. The name comes from the practice of keeping a small toy, often a rubber duck, on a desk and describing your code to it line by line. The toy contributes nothing except attention, and yet the method is widely reported to work. It is a folk technique rather than a studied procedure, so treat claims about how often it helps with some caution, but many engineers find it useful.
You do not need a duck. A colleague, a pet, a houseplant or a blank notes page will do.
Why it often works
There is no single proven explanation, but several plausible reasons are commonly given.
- It forces you to slow down. In your head you can skip steps without noticing. Speech is linear, so you have to put each step in order.
- It exposes assumptions. When you say “this value is always positive”, you may suddenly realise that you have never checked.
- It changes your viewpoint. Preparing an explanation for someone who does not know the details makes you see the problem from outside.
- It separates what you know from what you believe. Saying “the input is correct” and then being unable to say how you know is a useful discovery.
- It reduces tunnel vision. After long effort, attention narrows to one idea. Re-describing the whole problem widens the view again.
None of these reasons is guaranteed to apply to every problem, and sometimes explaining aloud simply confirms that you need more information.
How to do it
- Pick a listener. Anything that lets you speak without interruption will do. If you use a person, ask them to listen first and only comment at the end.
- State the goal. Say what the system is supposed to do. Keep it brief and concrete.
- Describe what actually happens. Be precise about what you observe: the error message, the wrong value, the circuit state, the conditions under which it appears.
- Walk through the logic in order. Start from the input and move step by step. For code, read each line and say what it does, not what you meant it to do. For hardware, trace the signal or the load path stage by stage.
- Check each claim. Whenever you say “this should be”, ask whether you have evidence for it. If not, mark it to test.
- Stop when something sounds off. Often there is a moment where you pause, say “hang on”, and see it. Write that down immediately.
If nothing appears, you have still produced something useful: a clear statement of the problem, a list of assumptions to test and a record of what you have ruled out.
Writing it down
Explaining aloud and writing are close relatives. Drafting a question for a forum or a message to a colleague often solves the problem before you send it. Many people have noticed this: the effort of making a question clear enough for a stranger to answer makes the answer visible. If you do end up sending it, a clearly written bug report with the steps to reproduce, the expected result and the actual result is also the best way to get quick help.
Keeping notes while you work serves a similar purpose, as described under engineering note-taking. A running log of what you tried and what happened prevents you going round in circles.
Beyond software
Although the technique is named after programming, it works on other technical problems.
- Circuit faults. Explain what each stage should do, the voltage you expect at each point and what you measured.
- Mechanical issues. Describe the load path, the fit and the sequence of assembly.
- Calculations. Read through the derivation, stating the unit of each term. This often finds a missing factor or a unit slip, in the spirit of sanity checks.
- Design choices. Justify a decision to an imaginary sceptic. If you cannot, the decision may need more thought.
- Plans and schedules. Talk through the sequence of tasks and what each depends on.
The same skill supports good communication generally, including the ability to explain things in plain language to non-specialists.
Limits and good practice
- It is not magic. Some problems need new information, such as a measurement, a log or a test, that no amount of explaining will supply.
- Know when to ask for help. If you have explained the problem clearly and still cannot see the cause, a second person is the next step. Asking after a clear explanation respects their time. Pair working is a good way to share the load.
- Do not overdo the solitary struggle. There is no prize for suffering longer than necessary. Set a reasonable time limit before involving others.
- Take breaks. A walk or a night’s sleep often does the same job as explaining, by letting the fixed idea relax.
- Mind the environment. In an open office, talking to a duck may be better replaced by quietly typing the explanation.
How it fits with other methods
Rubber duck debugging is a small tool in a larger kit. It helps you formulate a problem and find mistaken assumptions, but you still need systematic methods for narrowing down causes and confirming fixes. For software, the structured approaches are described under debugging strategies, and the wider problem-solving routine is in engineering problem solving. Use the duck as a first step, before reaching for heavier tools.
If you make it a regular habit, you may find that you start to catch many mistakes simply by imagining the explanation you would give, without needing to speak at all.