This article first appeared on the Triplebyte blog and was written by Joseph Pacheco. Joseph is a software engineer who has conducted over 1,400 technical interviews for everything from back-end, to mobile, to low-level systems, and beyond. He’s seen every quirk, hiccup, and one-of-a-kind strength you can think of and wants to share what he’s learned to help engineers grow.

Would you believe it if I told you that something called "rubber ducking" is actually one of the most insightful debugging techniques ever suggested? When you run into a programming snag you can't figure out, just find a rubber duck and start talking to it about your problems. Sold, right? Me neither.

I actually love rubber duck debugging, but not in the way it's usually explained. Turns out, it's hard for adults to take seriously the idea of talking to a literal rubber duck on their desk. And even if you guessed the duck is not really the point, you'd be surprised by how many engineers miss the point entirely. In this article, I'm going to explain what rubber ducking is, why it does actually work, and provide a step-by-step process for the way I do it that I think can change your debugging chops for good.

Related: Git Should Rename the Blame Command

History of the Technique

First, a little history. The Pragmatic Programmer is one of the most legendary programming guides out there, so it's no surprise that the idea of rubber duck debugging was first introduced in its pages. For something so popular, the only mention of it takes up three small paragraphs in a section entitled "Rubber Ducking." Thomas and Hunt explain:

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. The other person should look over your shoulder at the screen, and nod his or her head constantly (like a rubber duck bobbing up and down in a bathtub). They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself. [...] It sounds simple, but in explaining the problem to another person you must explicitly state things that you may take for granted when going through the code yourself. By having to verbalize some of these assumptions, you may suddenly gain new insight into the problem.

Every single word of this is true for about a million reasons, but we'll get to why later. Notice, however, exactly what they say. Find a person and explain the problem. A human. Not a rubber duck. The only reason they call it "rubber ducking" is because they knew another developer who placed a rubber duck on his desk while programming, and they only imply, tongue-in-cheek, that he used it for this purpose. At no point do they actually recommend you attempt to apply the idea by using an actual rubber duck.

Rubber Ducks Are Not for Talking

Now, it’s not always easy to find a coworker who can spare time to listen to your coding problems, and that’s a big reason why we’ve seen engineers over the years take this described “rubber duck” debugging technique literally. But even though these imaginative thinkers swear by their problem-solving process (and bravo to them!), it turns out that most engineers actually either don't feel comfortable explaining code to a toy or report back that it doesn't help them at all. I'm in the camp of believing that talking to an inanimate object is the dictionary definition of "meaningless." But that doesn't mean I think you need a human at your desk to play out The Pragmatic Programmer's debugging process.

How Talking Out a Problem Actually Works

I think the rubber ducking method hits on the great idea that communicating your problems can help you work them. When you force yourself to verbalize something, you take poorly formed mind-stuff and slot it into discretely packaged concepts (words) whose meanings are agreed upon by other humans. This alone adds an important layer of organization to your thinking by taking non-verbal soup and giving it shape.

Related: How I Learned Algorithms – Against All Odds

But there's another, even more important layer: your audience. When you have an actual audience, your mind snaps into this special mode of operation. Suddenly, everything is oriented around the goal of successfully communicating. Your mind no longer takes shortcuts based on things you already know. Rather, when it comes across those shortcuts during the communication process, it notices them, and attempts to verbalize them in addition to everything else. This is where the magic really happens. The onus of having to make someone else understand forces all of your assumptions to the surface and then further into words so they can be communicated. It's usually then that you have an aha moment and notice some basic thing that has been hiding formless under the surface and leads you to solve the problem yourself.

This typically does not work with a rubber duck. At the very least, you need to imagine a real audience. Again, this might work for the more creative-minded among us, but it doesn’t for me.

The Best Way to Rubber Duck (Without the Duck)

As if by some miracle, there's this thing we have where engineers can talk to a real audience about real programming problems. They can do it as themselves or anonymously. And they can expect to get real answers that may actually help them solve said problems — thereby setting the perfect stage for meaningfully verbalizing the question to begin with. This thing is called Stack Overflow.

Folks... the day rubber duck debugging clicked for me is the day I solve my first serious Stack Overflow question. It was a real beast. I was a junior developer, and I was stuck for days on my own, not secure in myself enough yet to ask for help from those I knew. So I put a lot of work into formulating this question. I maybe spent an hour or more. I wrote several lengthy paragraphs explaining all the details. Then it happened: the answer "leapt off the screen and announced itself." I started giggling to myself like a weirdo. My coworkers noticed but I didn't care. I had solved the problem before even posting the question. It felt so so sooooooo good.

Alas, folks. The best way to do rubber duck debugging is to find a real audience and rigorously ask your question. Stack Overflow is not the only option, but it's incredible because you can do it privately, on your own schedule, and get feedback on how well you asked the question — further pushing you to clarify your thinking! Here's the step-by-step process:

1. Anchor on a Meaningful Audience: Imagine you're explaining the problem to someone who might actually be able to help you. As you're writing, assume you're talking to this person or group of people. Doing so will help frame your question in a way that is more meaningful to your goal and allow the words to flow.
2. Let Go of Assumptions: On top of that, assume your audience knows little to nothing about your specific situation. While they may be capable of helping, you don't actually know the way in which they will turn out to be helpful. They might know nothing about the specific tool or framework you're using, but point out something way more fundamental that you would never have thought of (like some OS or network issue). Internalizing this reality will help you avoid glossing over important details that need to be verbalized, organized, and checked.
3. Explain Everything: Give the full context and background of the problem. Force yourself to articulate all of your assumptions, and explain why you believe each assumption to be the case. Explain everything you've attempted so far. Explain what you expected to happen, and why you expected it to happen. Then explain what's actually happened, and why you think it might be happening. Follow this up with other rabbit holes you might consider going down, and why you think they're worth exploring. Then explain anything else you think is relevant. And why. This might be messy at first. You might be overly verbose or disorganized, but it will get better and easier the more you do it. And if you use Stack Overflow, you will probably get feedback on how to be more clear, which will help you along even further.

The more rigorous you are, the more likely you are to have a eureka moment. And a bonus that you don’t get with the duck: You might actually get a real person (albeit on the other end of the internet) to chime in with extra helpful info about your problem!

Final Thoughts

It's ok if you want to have a rubber duck on your desk. The truth is, having it there is a great reminder to take this improved approach. The idea behind rubber duck debugging works. It speaks to something fundamental to the way human minds work that transcends programming entirely. Ever heard of the Socratic method? That's rubber duck debugging in philosophy. How about talk therapy (aka psychotherapy)? That's rubber duck debugging for your mental health. The point is, the principle behind this technique is everywhere. Slow down your thinking, verbalize it, ask probing questions about assumptions, then reveal reality. Then like magic, problems get solved.

Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.