Can I be Your Rubber Duck? Debugging Code With a Friend

Whether it’s an actual living human friend, a coworker, or a dog, or a bird, or an inanimate object imbued with friend status, having someone or something to explain your programming problem to can help you see the solution faster than you might think.

Rubber duck debugging is a problem-solving method used by software engineers and programmers to debug code. When you are staring at something like this all day, it can be easy to get caught up in what you are doing and miss an error.

Rubber Duck Debugging

While it might seem silly to have a little plastic duck sitting on your desk, silly things can serve a great purpose.

Rubber duck debugging is actually a reference to a story in the book The Pragmatic Programmer — a programmer has a literal rubber duck and debugs code by making himself talk to the duck and as he goes through his code line by line.

Today, rubber duck debugging is a widely accepted technique. There are even ducks you can buy in almost any color or theme from pink to one decorated as a pirate. As long as the duck or object is something you like, it should be easy to get out of a rut and see a different perspective when you start talking to your “duck.” The act of talking to a willing listener tends to slow down your thinking and provides the space for you to thoroughly explain the problem. Then your “aha!” moment will arrive — you have discovered the flaw.

While the case is strong that debugging code via the duck method will solve your problems, there are variations you can use to achieve the same results. In many work environments, coworkers take on the role of the rubber duck. For example, remote work teams and those who work from home get a mental shift from the act of contacting a coworker vs. talking to a rubber duck.

Who’s Your Rubber Duck?

For ExaVault engineers, rubber duck debugging means hopping on a call with a coworker and describing the problem. This provides our engineers with an ear to listen as they talk it out and see the solution to their code issue.

While rubber duck debugging typically refers to hitting upon the solution without another person, someone who can audibly respond or breathe heavily over laptop speakers or headphones also does wonders. In debugging cases that are approaching a deadline, doing a screen share as you talk through code lets the other person see the code so they can play a more active role in spotting any errors.

No shame shall come from your coworker. It is better to discover a flaw such as operating on the wrong variable or a simple typo than to get complaints from clients once code is in production.

Explaining Out Loud Allows You to See the Solution

Since rubber duck debugging is all about talking out loud, it’s just as important to feel that you are being listened to. 

It is also a way of reasoning out your assumptions and logic that was in place when you wrote the code. If something doesn’t feel right when you say it, this is your turn to keep talking, trying to describe the process in another way.

When you create something, you can become deeply immersed in it and may not notice little things. Therefore, taking a step back when you realize there is an error, can clear your head of your connection to the code. Once you have stepped back, using words to explain each line of code interrupts the thought patterns you previously had. In many cases, hearing yourself describe something quickly brings about an “aha” moment. That moment when you realize you forgot to consider a vital element, overlooked something, or had come to a conclusion and didn’t follow through on the reasoning.

Now, none of these are negatives to go down in your permanent record. The good thing is – when you need to debug code, there are techniques to help reduce the time and stress involved in doing so.

Analyze Before You Execute

This sounds like sage advice. And it is. But, sometimes you need to execute or test code before you know there is an issue to debug. Snap out of just sitting silently in front of the computer screen. It’s time to try analyzing what is there and what is working before making a bunch of changes like adjusting variables and hoping things will work. Pull up your code, whip out your rubber ducky or call an available coworker, and analyze. You’re not in-depth analyzing for a final exam. Simple rubber duck debugging will do.

Start by explaining your logic. What is the expected outcome? What went on in your mind when you thought about how to get from point A to point B? Your duck is soaking it all in.

Next, go line by line and verbally explain your code. Before you know it, you’ll see the solution.

Time to Debug – Who Are You Talking To?

It’s natural to feel awkward. Maybe you can’t call a coworker or friend to be your rubber duck because you fear they will revel in the fact that you made a mistake. Maybe talking to an inanimate object or stuffed animal fires up your nerves, preventing you from being able to speak coherently. That is why there are multiple options to get you to the same outcome of debugged code.

1. The traditional little yellow rubber duck — or purple duck, or stuff bear, or favorite action figure from your childhood. (No, not a live duck. Unless you live by a pond with ducks and would like to tell them about your code.)
2. Another person. Coworkers are great for this if available. Friends are good at lending an ear. 

It’s not about the knowledge your rubber duck has, but your ability to talk it through. The goal is to quickly debug code. There are many stories of programmers who interrupt a coworker with a code issue. As they are explaining the problem and asking for assistance, they stumble upon the answer just like that! No actual assistance need.

Now you can be like our engineer Tom, finding errors and debugging code like a pro. Next time you need to go over some code you wrote, just ask for a rubber duck.

Get file transfer with direct S/FTP access and a powerful developer API – Try ExaVault Today!