Chances are, you’ve probably been rubber duck debugging without even knowing it. Here’s how:
You’re in the zone. The world fades. You type away and every line of code works as expected. Whoever said coding is hard to learn?
And then, boom! You get a bug—an error in your code.
Naturally, your first instinct is to ask Google, so you copy and paste your bug. First stop: Stack Overflow (a question-and-answer site where you can get solutions). You read through a few questions and solutions, trying to find one that works for you.
You try it out, but it doesn’t work. This cycle goes on and on for three hours. By now, you are absolutely lost. Your thoughts are completely entangled, and what’s worse: Every tweak you make to your code increases the bugs.
You check your phone. Your friend tried to reach you, so you call them back.
Before you realize it, you are telling them all about your code.
They ask you a few questions. All of a sudden, you thank them profusely and say you’ll call them back in an hour or so. Your friend is dumbfounded, but they agree anyway.
What you have done is known as “rubber duck debugging” or “rubber ducking”.
But what exactly is it? What does it have to do with ducks? Let’s explore this concept further.
If you’d like to skip ahead to a particular section, simply use the clickable menu:
- What is rubber duck debugging?
- Rubber ducking: A step-by-step guide
- Other useful programming techniques
- Final thoughts
1. What is rubber duck debugging?
Rubber duck debugging is a programming technique used to help with debugging—fixing errors in your code. It involves explaining your code and what you are trying to achieve to a rubber duck, in its literal sense.
If you want to learn about the wider area and other techniques, check out our beginner’s guide to debugging.
Why talk to a duck? I mean, a duck can’t engage you in conversation, or pinpoint a missing semicolon!
The whole point here is that you need to explain your code to something or someone.
The “duck” here could be anything or anyone. It could be a friend or colleague at work. If you’re a remote developer, it could be a flatmate or family member.
It could even be a pet—bunnies and stuffed frogs are acceptable, too.
Image source: Reddit
The recipient might help you with the thought process by asking questions or not.
As you explain your code, you become more aware of your thought process and where you are going wrong.
If your “duck” in this place is a human, then they might help by asking for clarifications or questions that point you in the right direction.
Note that your “human duck” doesn’t need to be a software engineer or web developer—any sympathetic ear will do!
Where did the term rubber duck debugging come from?
Rubber ducking, as a concept, was introduced as a story in The Pragmatic Programmer—a book written by Andrew Hunt and David Thomas in 1999.
In the story, a programmer would carry a rubber duck and explain code to it line by line.
2. Rubber duck debugging: A step-by-step guide
The first step in the rubber ducking process involves, of course, getting your rubber duck.
Next, explain what your goal is—what you are trying to achieve with your code.
For example, let’s say that you are trying to write code that can send a bill after 30 days. You, however, have no idea how to go about adding 30 days to the current start date.
Here are the rubber-ducking steps you would take:
- Tell your duck the goal that you want to achieve: send a bill after 30 days.
- Explain what you have done to achieve the goal. Talk about every line of code.
- Inform the duck about any errors you have encountered.
As you explain your errors, you’re most likely to see where you were going wrong, or the direction in which to take your research.
Yes, you will have hit your eureka moment.
Where your “duck” is another human, you’re highly likely to receive feedback.
The other person may question your thought process. Or why you chose to approach a problem the way you did.
An important tip is that you need to be able to receive feedback and respond without getting defensive.
3. Other useful programming techniques
In this section, we look at more programming approaches that you can add to your coding arsenal:
Code reviews
Code reviews are primarily focused on code quality.
In code reviews, you have your “peers” go through your code, identifying mistakes and better ways you might have written it.
Your peer might point to a variable name that is not obvious, for example.
Pair programming
In pair programming, two developers work together to implement features. There are two main roles—navigator and driver.
The navigator “advises” on what to do. They might say, for example, “create a function without parameters”. The driver then does what the navigator asks him to do.
The driver can question the navigator’s direction and ask for clarification. It’s a collaborative effort.
The roles of the driver and navigator switch from time to time.
The amazing thing about pair programming is that you also get to debug your code together. You kind of have an “ever-present duck”.
Pair programming is part of another technique known as extreme programming. Let’s learn about it next.
Extreme programming
Extreme programming, or XP in short, is not an extreme sport.
You don’t get to code while dipped in ice-cold water for 30 minutes or something.
XP is a programming method of building software quickly while adapting to customer requirements.
In extreme programming, the customer is the focus. And because customer needs can change from time to time, with XP, developers are able to implement them almost immediately.
Customer requirements can be implemented at any stage of the Software Development Life Cycle, or SDLC.
Yes, software development follows a cycle—a number of phases or stages that are followed before we say that software is ready to be “launched” into the market.
Developers will need to go above and beyond to match changing customer requirements. This is where the concept of “extreme programming” comes in.
How might you practice XP as a beginner?
One of the ways you can practice XP as a beginner is by having a mentor. The mentor can act as your “customer”.
They’ll review your code and what features you have built, and make suggestions.
XP with a mentor is not synonymous with rubber ducking. It does, however, keep you on your toes to keep the customer in mind. This way, you might reduce the bugs in the first place, as you’re focussing on the customer.
4. Final thoughts
You don’t have to get frustrated and smash your computer on the wall when you encounter a bug.
Now have a tool that you can use to smush any bugs and find your way when you are stuck—rubber duck debugging.
We weren’t joking earlier—you might as well buy yourself a literal rubber duck and put it on your desk. It’ll surely go a long way toward helping you understand your thought process.
Better still, if you have any web developer friends, a rubber duck would make a thoughtful gift.
When coupled with other techniques like code reviews, pair programming, and extreme programming, rubber ducking becomes even easier.
Why not start practicing the rubber duck method via CareerFoundry’s free 5-day coding short course? Even though it’s designed for absolute beginners, you’re sure to run into at least a small snag at some point—it happens to all of us!
In the short course, you’ll build a website from scratch using HTML, style it with CSS, and add functionality via JavaScript.
Take a sneak-peak at the first lesson in this video, where Abhishek Nagekar, security engineer for Mozilla, introduces you to your project:
Otherwise, if you’d like to read more about the world of coding, check out these articles: