Rubber ducks aren’t just for bath time. For years now, programmers have been using them as a way to debug code. And anyone who’s familiar with rubber duck debugging can tell you just how powerful it can be when solving coding problems.
It’s true: Talking to a rubber duck might just be your ticket to debugging code. If you’re new to the concept, this probably answers a couple of questions for you. (Yes, the rubber ducks scattered throughout your office have a purpose. No, your coworkers engrossed in one-sided conversations with a bath toy haven’t gone off the deep end.)
And while rubber duck debugging is commonly linked to uncovering buggy code (we’ll explain how), practicing this method as a developer can also help prepare you for whiteboarding and pair programming interviews.
Rubber duck debugging explained
Rubber duck debugging has less to do with a literal duck and everything to do with the problem-solving process. It was first introduced in The Pragmatic Programmer: From Journeyman to Master, written by Andrew Hunt and David Thomas in 1999.
It’s a pretty simple concept: When you come across a hard-to-solve problem, you talk to your duck to find the solution. It requires nearly no upfront investment (rubber duckies aren’t exactly expensive) and pushes you to rethink your approach to uncover errors in your code.
But as simple as starting up a conversation with an inanimate object sounds, there are some ground rules to follow that’ll increase the likelihood you’ll actually spot the oversight in question, and sooner rather than later.
Here’s what The Pragmatic Programmer has to say about it:
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.
Best practices for the best results
A key element to getting the most out of rubber duck debugging is explaining the complete processes or problem—from start to finish.
Starting in the middle won’t cut it. Neither will leaving out little details that don’t seem to matter. After all, the duck isn’t code-savvy. In fact, the duck has no idea what code is, why it matters or what you’re trying to achieve with it.
Part of describing an idea or concept thoroughly encourages your brain to slow down, stop overthinking and look at the problem from a different point of view. Instead of glossing over your code, you break everything out. And in the process, you’ll fill in any knowledge gaps by looking closer at the parts you don’t fully understand (similar to how teaching can help you learn).
Somewhere along the way, you’ll have a lightbulb moment. Maybe your goof was an unclosed bracket. No matter the case, you’ll discover what you’re telling the duck and what you’re actually doing don’t line up.
Bonus reasons to be friends with a duck
For one, your team members will appreciate the power of rubber duck debugging because instead of resorting to their expertise at the start (pulling them away from their own work), you’re resourceful—making a real effort to solve the problem on your own first. And should you find success with rubber ducking, no one else will even know you hit a snag.
If you absolutely can’t solve the issue with your rubber ducky, however, you’ll have at least run through the steps a time or two, which should help you explain the issue to your coworker more thoroughly, speeding up the collaborative problem-solving process.
Additionally, while rubber duck debugging isn’t actually categorized as interview prep, it’s excellent practice nonetheless. The software developer interview process, for example, oftentimes includes a pair programming or whiteboarding interview. Both types of interviews test your coding abilities, but also show the interviewer how you balance communication, collaboration and problem-solving.
When it comes down to it, breaking your code down line by line out loud to solve a problem—the basis behind rubber duck debugging—is exactly what interviewers look for: your thought process and how you work in a real coding environment, not if you can or can’t solve a problem.
Your guide to debugging code with a duck
- First, find a duck. If you don’t have a duck of your own, get in touch with your creative side and sketch one out. Your pet rock, desk accessory or cat will work just as well. Remember, it’s not about the duck per se—it’s about explaining your problem to something (or someone) who has little to no knowledge of programming. So, feel free to tap a sales rep with some extra time, too. In doing this, you’re more likely to explain the problem fully, whereas if you turn to your coding buddy, chances are greater you’ll skip over seemingly irrelevant but key details.
- Start explaining. Look at your duck, say hello and start from the beginning. The duck is clueless when it comes to computers and programming (and probably anything related to humans in general), so explain every aspect of your problem—and be specific.
- Watch and wait. How does your duck respond? With a blank stare? If so, odds are it’s stumped, just as you might still be. Take a step back and think about what you excluded. Did you explain your end goals and what the code is supposed to do? Fill in the gaps with those details. This might mean starting from the beginning again.
- Find the solution. Enter your eureka moment. The answer may have been simple and that’s alright. After all, you can’t write clean code without solving problems, and looking at the problem from a new angle is sometimes all it takes.
Alternatives to rubber ducking aloud
One of the reasons rubber duck debugging works so well is that it forces your mind to process information differently, in part by explaining the problem out loud. While that may be, coworkers working within earshot might consider your conversation a distraction.
To avoid interrupting others, or looking “weird” (if that’s a concern), try one of these alternatives:
- Write a letter. Follow the same steps as you would if you were talking to your duck, and detail every step of the process.
- Phrase your problem as a question. Pretend you’re asking an online community for help. Go through the motions of typing out your question, right up until you actually post it. This helps you include details otherwise overlooked, similar to explaining your problem out loud.
- Ask Duckie. Duckie is an online tool specifically designed for rubber ducking. It encourages you to think through your problem with statements and questions based on your inputs. Start by describing the problem to Duckie. Then, based on what you say, Duckie will ask you questions like: “What parts are you certain work?,” “What are your unknowns?” and “Could you replace uncertainties with debugging statements?”
Debugging code—and then some
The advantages of rubber duck debugging extend beyond the end goal of zeroing in on an error. Along with solving the problem at hand, you’ll likely gain a better understanding of your code, learn from your mistakes and even save yourself frustration and time in the long run.
Something to note: Just because rubber duck debugging is associated with software engineering, it’s not tied to it alone. This method is useful in almost any profession, at all stages of a career—and an easy way to rack up brownie points with your boss and coworkers. (Who doesn’t appreciate an employee that can communicate well and hold their own when faced with a challenge?)