What is Rubber Duck Debugging?

Rubber Duck Debugging is a debugging technique based on describing out loud to a rubber duck, or anything or anyone, what your program is supposed to do, which usually makes you realize what you’re doing wrong. As rubberduckdebugging.com describes it better than I do, I’ll quote them here:

The rubber duck debugging method is as follows:

1. Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety).

2. Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.

3. Explain to the duck what your code is supposed to do, and then go into detail and explain your code line by line.

4. At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

**Note**: In a pinch a coworker might be able to substitute for the duck, however, it is often preferred to confide mistakes to the duck instead of your coworker.

I have a This Is Fine Dog Funko Pop that I sometimes talk to when I’m stuck, who reminds me that, well, while it’s not fine to be stuck for too long, it’s fine to commit mistakes. Meanwhile, my Mario Super Mushroom timer reminds me that errors are always an opportunity to grow.

Rubber ducking is often taught as a way to avoid interrupting other colleagues with simple questions that you’re very likely to answer while describing the issue - developers and designers don’t like being interrupted, they say.

Quick pair programming sessions

However, we’re helpful, nice people, and we like to help. Most of the time, yes, we’re available for a quick pairing session. Maybe not now, but a few minutes from now. It might be worth it to ask a colleague for 10 or so minutes of their time. You can take this opportunity and be intentional about who you’re reaching out to, seeking someone out of your immediate circle. That’s a great technique to manage unconscious bias, and still expand your circle.

It might happen that this colleague will serve as a fancy rubber duck. As you have to explain your code to a human, you might go into greater detail and figure it out yourself. Sometimes, they might catch your wrong assumption as you speak and ask an enlightening question. Or they could just confirm this is a very weird behavior, and at least you know you’re not alone. Either way, chances are you’ll be better after this pairing session than before.

Interactive non-human rubber ducks

Unfortunately, there’s a chance you won’t find someone to help you.

With the rise of virtual assistants such as ChatGPT, people massively started using them as their rubber ducks. They’re great tools and tend to ask good questions that guide you toward understanding what went wrong. There are even specialized versions bundled as editor plugins - not to forget GitHub Copilot.

While those tools are helpful and help developers code faster, that undermines collaboration and knowledge sharing on a scale much bigger than a simple rubber duck. As you asked your questions to a computer program and nobody even knew you had that issue, no one had the opportunity to learn with you.

Rubber ducking in public

If you really don’t want to bother anyone, asynchronous communication can help you get unstuck and still share something with everyone.

At thoughtbot, we have the #dev Slack channel, where developers ask questions when they’re stuck, share TILs, and discuss whatever topics they think it’d be good to share. You can take a peek into this channel by reading the This Week In #dev series.

Several times, after writing down the question, I found myself realizing the wrong assumptions I made. Moments before deleting my message, it occurred to me that what I’ve learned might be beneficial to others who could encounter similar challenges and search for solutions there. So I sent it anyway, alongside my own answer.

What’s more interesting is that, as I shared, other folks offered alternative solutions that worked better in my case. That turned out to be a double win: I learned two new things, and other colleagues had the opportunity to learn them as well.

Don’t keep it in your head

In the end, it doesn’t matter if you had the eureka moment while typing a message on Slack, describing what you were doing to a colleague while pairing, or talking to a teddy bear. I strongly encourage you to share your learnings whenever possible anyway: it might be casually mentioning what you learned during a Pull Request review, sharing a short message on Slack, or writing a blog post. What is truly valuable is that other people also have the chance to learn with you, fostering a culture of continuous learning.