Why I Use Rubber Duck Debugging

Before I spent nearly 8 years as a Principal Software Engineer at Facebook, I interned there. My manager taught me a valuable lesson and a simple, but effective, technique that I still use to this day.

Being new to the company and engineering, I used to bother him with so many little questions, all hours of the day, every 5-10 minutes. My manager was very non-confrontational, so he decided to make an internal tool to help me answer my own questions. He sent me a link to the tool and told me if I had any questions, I should use the tool from now on instead of asking him. It was called Rubber Duck. I was excited to use it, so I immediately clicked the link. To my surprise, the link directed me to a web page with an image of a rubber duck on it. That was it. At first, I thought he was just making fun of me for asking too many questions. So, I did some research and found out that what he sent was actually legitimate; it was a technique called rubber duck debugging that traces back to a book by David Thomas and Andrew Hunt called Programmatic Programmer.

Although I never actually used a physical rubber duck or even the tool my manager made, rubber duck debugging became a reminder that the code I was writing was going to do exactly what I told it to do, and nothing else. There are no secret things behind the scenes where the code has a mind of its own; it’s following instructions verbatim.

What is rubber duck debugging?

Rubber duck debugging is the idea of explaining your code line by line to a rubber duck (or simply explaining it out loud) and confirming that each line does what you think it does. Talking through your code forces you to focus on each line and think about your code in a different way. A lot of people tend to make assumptions based on what they’ve seen in the past or skip ahead over trivial lines, but even if you’re 100% sure, wires can get crossed in your mind and you can make mistakes. So, if you very patiently and diligently walk through each line, you can often solve those problems. Rubber duck debugging (or rubber duck programming) is throwing out all of those assumptions, letting go of your ego, and moving forward so that you are 100% sure in each line of code.

Why I use rubber duck debugging

Even though it sounds tedious, going through each line of my code can actually save me time. When I review our Fellows’ code in our Fellowship, I often advise them to debug with no assumptions. I tell them to just go through and explain each line as if they’re trying to prove to someone else that it works perfectly. People often gravitate to the hard parts of the code and skip the trivialities, so this is a great way for them to think about every detail of their code.

Everyone spends hours debugging at some points; it’s a sign of an engineer. Right from the beginning, if you go line by line through 50 lines of code you’ll save yourself from playing whack-a-mole testing, and re-testing infinite combinations. It still might take longer than googling and copy/pasting from Stack Overflow, but rubber ducking can be faster than getting lost in these rabbit holes.

Why should you use the rubber duck debugging technique?

1. It’ll save you time: Just like I mentioned above, going line by line will save you the time of re-testing combination after combination.
2. You'll learn more earlier on in your journey: A lot of people love Stack Overflow because it has snippets they can use to solve problems. But you can always tell when someone copied and pasted from there because it feels out of place. Rubber duck programming helps you understand what every line of code is doing and gives you a really solid understanding of the fundamental syntax of a language.
3. Interview helper: If you're working on algorithms in an interview and you’re getting stuck or freezing, don’t frantically spiral. Using the rubber duck debugging technique will help remind you to calmly go through your lines of code and find the problem.

When it’s not ideal to use

For a really complex system where different pieces are interacting beyond your control, like API calls to get data and then passing that data somewhere else to get processed, there are external systems involved. It can be hard to take this technique and use it to the fullest extent, so you kind of have to add more judgment. That’s where experience comes in. When you’re going line by line in a complex system like this and you come across a single line that you have no insight into, you need to use a lot more judgment and experience. In this case, the rubber ducking technique is a bit less helpful, but its spirit can still help.

The spirit of rubber duck debugging lies in not making any assumptions about the code or guessing at what the code is doing, no matter how complex the systems are. The best part about this technique? You don’t need any additional tools to use it. Remember that using rubber duck programming can not only save you time, but it can also help you on your learning journey and even during interviews.

Looking for more tips like this, and to learn from best-in-class engineers like Michael? Apply to our Fellowship today and prepare to supercharge your career.