Learning how to code can be challenging. One odd trick to help make it easier is a little thing called rubber duck debugging. You might be thinking, “What…? Rubber ducks and coding?” Today, we’ll explain the interesting but unexpected connection between developers and these classic bathtime toys.
Here’s what we’ll discuss:
- Why do programmers have rubber ducks?
- What does rubber ducking mean?
- How can I use the rubber duck debugging method in my work?
- Does this mean Ernie from Sesame Street is a coder? (Pure speculation, but it’s a fun thought.)
Why do programmers have rubber ducks?
You might think programmers have rubber duckies just as quirky decorations, but these cute little toys are more than just a statement piece (or a way to reminisce about childhood). Here’s the secret: programmers keep a rubber duck around to help them with their code. In all professions, there are small hacks, tips, and tricks that workers use to make their jobs easier. For a Software Engineer, a rubber duck is another (admittedly unconventional) tool in their toolbox.
What is Rubber Duck Debugging?
Claire Munds, a Senior Software Engineer & Facilitator at Kenzie Academy, answers this question during one of our online webinars. In the video below she explains how software developers use this method to debug their own code.
What does rubber ducking mean?
Do you ever come across a problem and feel totally stumped by it? You ask a coworker, fellow student, or friend for help, but before you finish explaining the problem, you realize the answer all by yourself. It turns out, you just needed to explain the problem out loud to get your brain into problem-solving mode.
In usability testing, we refer to this phenomenon as the think-aloud protocol. Product Designers will ask participants to think aloud while performing different tasks so they can get a better idea of their thought processes and decision-making to gain greater insight into the product’s usability. Meanwhile, in scientific research circles, we’d refer to this sudden arrival of a solution as an “aha!” or “eureka!” moment. Software Engineers use rubber ducky debugging for the sole purpose of reaching these moments.
In rubber duck debugging, you’re following the same concept.
“The Pragmatic Programmer”
The term “rubber duck debugging” can be traced back to a 1999 book by Andrew Hunt and David Thomas called “The Pragmatic Programmer.” In the book, the authors describe a programmer who carries a rubber duck around and debugs their code by explaining it, line-by-line, to the duck. While the practice of talking to a rubber duck may sound silly, it’s actually proven to be a helpful strategy for finding and solving problems with code.
Since the book’s publishing, the technique has become popularized in software engineering circles. You may also hear the technique referred to as ‘rubber ducking’ for short.
Rubber duck debugging can help you sort out a coding problem because it forces you to talk through all of your choices and actions so far to hopefully show you where you may have made a mistake. We think a lot quicker than we speak so talking through the process can help you slow down and see the bigger picture of your code, making it easier to spot problems.
Additionally, rubber duck debugging allows your mind to shift as you work to explain the code to the duck, an object that has no knowledge of your code. Using a duck allows you to be more precise and thorough because you’re going into your explanation with the assumption that the duck doesn’t know anything about your code.
Explaining your code to a rubber duck will also help you learn and become a more efficient coder. In fact, research has consistently shown how the act of teaching someone actually reinforces your own knowledge and skill.
Do I have to use a duck?
It’s important to note that rubber duck debugging doesn’t require a duck. You can use anything as long as it forces you to slowly and carefully explain your code. While the point of this exercise is to avoid wasting your teammates’ time, we’d bet your dog would be pretty interested in what you have to say (if you’d prefer explaining your code to a living thing).
What’s the psychology behind rubber ducking?
David Hayes blogs about life as a programmer on the website Thoughtful Code. We resonate with something he wrote in a post about the psychology of rubber ducking:
“We use ducks and other stand-ins because of the vast difference between the way most humans think and the way that computers do. When you hit a roadblock when programming, it’s likely that you’re not thinking the way a computer does. Computers are painfully precise. Humans are, generally, forgiving and loose in their understanding. So many of the “bugs” and issues you have when solving a problem in your program originate in not being clear and explicit enough in your instructions.”
How can I implement rubber duck debugging into my coding practices?
The next time you’re struggling with your code: Pause, take a deep breath to let out your frustration, and pick up your rubber duck. Then, start to explain your broken code to the duck. Go line-by-line, starting with your overall vision and goals for the code. If you’re still hitting a wall, try explaining the intermediate states and transitions. Finally, bask in your glorious “aha!” moment.
Again, you can still use this method without a rubber duck. Substitute a duck with another inanimate object or explain your code to a pet. The point is that you should explain your code verbally, line by line. If you still aren’t reaching a solution after using the rubber duck debugging, that’s the moment to reach out to a coworker for help.
So next time you’re stumped on a line of code, pull out your trusty sidekick. Heck, maybe even take an actual bath with your rubber duck – shower thoughts can be powerful.
Now, go forth, write code, and kick ass!
Learn more about Software Engineering best practices:
- What is a Full Stack Web Developer?
- Everything You Need to Know About A Career in Web Development
- Web Designer vs. Web Developer: What’s the Difference?
- 15 Skills You Need to Become a Front-End Developer in 2020
- Front End vs Back End: What’s the Difference?