We’ve all been there, battling through a nasty bug that just doesn’t seem to reveal itself. Sprinkling endless breakpoints and log statements to try decipher the bugger, but nothing is working. You’ve been through every line of code in the broken module, traversed every stack frame, probed and prodded, poked and pushed.
You’ve made no progress, all you know is that you don’t know, you’re a broken man/woman and you see no way forward. You need rubber duck debugging.
What is Rubber Duck Debugging?
Do you ever get stuck on a problem, ask a co-worker to lend you a hand and do some pair-programming to try solve the issue, and in the midst of explaining the problem a sudden realisation hits you? you know how to fix it.
This is exactly what rubber duck debugging is, rather than explaining the problem to a co-worker you explain it to your duck. Here’s my duck, he’s had to sit through a lot of my worst times as a software engineer, and has helped me endlessly.

The best way to learn is to teach
I thoroughly believe that a great way to really understand something is to teach it to someone else. If you can’t explain something properly then you probably don’t understand it very well. “While we teach, we learn” – Seneca the younger, who lived 4BC – 65AD.
This is why Rubber Duck debugging is so effective, if you can articulate your problem in a concise and comprehensive manner such that another person can parse the information with ease, the solution to your problem — more often than not — will uncover itself to you.
You see, when you’re trawling through the code line by line, you oftentimes forget the bigger picture; you’re so focused on the intricacies that you neglect the knowns. When you explain the problem to someone else you mustn’t neglect these higher details else they’ll have no context for which to discern the issue. Being bogged down in the details can often be your Achilles heel, you just don’t know it.
The Pragmatic Programmer
Talking to a duck isn’t a novel idea of mine, it was first coined in the book The Pragmatic Programmer. Which is in itself, a brilliant book and thoroughly recommend any programmer to read:
In the book David Thomas — one of the authors — tells the story of one of the best engineer he’s ever met:
Why “rubber ducking”? While an undergraduate at Imperial College in London, Dave did a lot of work with a research assistant named Greg Pugh, one of the best developers Dave has known. For several months Greg carried around a small yellow rubber duck, which he’d place on his terminal while coding. It was a while before Dave had the courage to ask….
The Pragmatic Programmer
Do I have to use a duck?
You absolutely have to use a duck, ever heard the saying like a duck out of water? Well, a rubber duck gives off gamma waves which synchronise with the output of a programmers brain, such that a rubber duck is the only object that can possibly bring us closer to a solution.
I honestly can’t believe I wrote the above paragraph, of course you don’t need to use a duck. Any inanimate object will do, talk to your cup of coffee, your plant, your Himalayan salt lamp. As long as you can look at it and talk to it, then it’ll do the job.
How I use Rubber Duck Debugging
Since the Covid-19 pandemic I am now a full-time homeworker, this has amplified my rubber duck debugging. Nobody gives me a funny look when I’m talking to myself, because nobody can hear me. Talking to myself whilst I program is something I’ve done for as long as I can remember, it’s a trait I’ve inherited from my mum who — one of the best sales women in the country — would frequently think aloud ensuring the task had her undivided attention. I’d argue this is one of the keys to her success, able to retire 20 years earlier than some of her colleagues. And there’s evidence to support this:
The research, published in the journal Memory, finds that the act of reading and speaking text aloud is a more effective way to remember information than reading it silently or just hearing it read aloud. The dual effect of both speaking and hearing helps encode the memory more strongly, the study reports. The new research builds on previous work on the so-called production effect by Waterloo psychologist Colin MacLeod, who is also one of the current paper’s authors.
https://www.mentalfloss.com/article/518457/why-reading-aloud-helps-you-remember-more-information
When I’ve been struggling on a problem for an extended period of time and start to think maybe I need to get a second opinion on it, the first step I take is to figure out how to explain the problem. I do this with my rubber duck, I’ll talk it through, and if I’ve reached the end of the explanation without uncovering something I may have missed, then I make the call.
How to Rubber Duck Debug?
There are 4 steps to Rubber Duck Debugging.
- Get a duck. Mine was from Amazon.com. It’s no longer available, limited edition I suppose. but you can get yourself a batman duck, I would treat myself, but I’m a loyal co-programmer.
- Put the rubber duck on your desk, maybe place it so he/she can see the code. There are some ducks that are more visual learners, you’ll get to know your duck’s intricacies as time goes on.
- Explain your issue to the duck, tell them what’s supposed to happen, what is happening, why you think it’s happening, the proofs you have and then walk through the code. Even if your duck is oriented such that they have been looking at the code, don’t forget to explain the issue assuming they have no knowledge at all.
- Step 4 is not really a step in itself, if you’ve reached step 4 without a solution to your problem then the duck has let you down, or you’ve just not explained it well enough, probably the latter. Explain again, with more detail this time, and again, and again.
- Pay your duck. You see, your duck has potentially saved the time of not just one programmer, but also the other programmers you’d have interrupted when you asked for help, calculate the cost the duck has saved the company. Give him a nice bath, he/she will appreciate it.
The benefits of the duck
There are many benefits to rubber duck debugging and many I probably haven’t covered in this blog, but there are two that really stick out to me.
- You don’t distract other programmers
A programmer is expensive, two programmers twice so. There is much deliberation about the flow state that programmers strive for when writing code, whether you believe in it or not, context switching is costly. When you’re interrupting another engineer, you’re not only distracting them from their work, but you’re potentially taking them out of their flow which could have a negative impact on their own output, which will have a knock-on effect on the team as a whole.
- Ducks don’t judge
Sometimes you just don’t understand the problem enough to explain it, if you can’t explain it to your duck then you’ll have no chance explaining it comprehensively to another engineer. You might risk making yourself look like a plonker — nobody wants that. At least explaining it to your duck you’ll know it won’t judge you, as long as you bath it frequently it’ll think the world of you. If there’s things you don’t understand, voice it aloud to your duck.
What next?
The thing that I love about programming more than anything is that no matter how confused you are right now, it always makes sense in the end. The confusion is just merely a lack of some information, upon acquiring that information and the aha moment you’ll have a better mental model of the system. Things begin to make sense, stuff starts to hang together, you understand.
Rubber duck debugging is not confined to programming, it can be applied to all manner of things: presentation preparation, exams, maths. Whatever the issue you’re stuck on, it wouldn’t do you any harm to talk out the details, verbally explain the problem and watch the answer reveal itself.
Rubber duck debugging is a method to help you understand your own problem better by the simple act of talking the issue through. Leverage rubber duck debugging to solve your problem. I challenge you to give it a go, whenever you’re really stuck on a problem and think you need another pair of eyes, remember, your duck has eyes.
[…] in the episode they spoke about the Pragmatic Programmer, which I’ve since read and recommended in numerous blogs. More specifically, they talk about Prototyping. Which completely changed how I […]
[…] If you’re making no progress, talk the problem through as though you were explaining it to someone with no knowledge, think of the issue from a high level, have a go at Rubber Duck Debugging. […]