Why a Rubber Duck is important in Software Engineering

Nearly all software engineers have been through the frustration of investigating some specific bug, where you stare at a block of code for hours, but everything just looks correct. You might have even written the code and feel you know it inside out. Then after putting out your hair in frustration, you decide to turn to a colleague for assistance. But while explaining the code to them, you unexpectedly have that 'aha' moment and find the bug. The ever-so-witty engineer then usually comments along the lines of "see how good I am. I didn't need to say a word. My presence alone helped you find the bug".

It can be embarrassing and make you feel like you've wasted your colleague's time. So perhaps next time you're in this situation, instead of reaching out to your colleague for help, you can try a technique called "Rubber Duck Debugging".

It's pretty simple to do. But first, you'll need to get a rubber duck. Buy, borrow, or steal one, whatever works for you. Once you have it, explain to the duck, out loud, what the piece of code should be doing, and then you walk through each line of the code and explain in detail what it's doing. At some point, you will realise that it's not doing what you thought it was, and you've found your bug. Or you've found another bug.

"Rubber Duck Debugging" is from the book "The Pragmatic Programmer" by Andrew Hunt and David Thomas. They share a story of a programmer who would carry around a rubber duck and help colleagues debug their code by forcing them to explain their code, line-by-line, to the duck.

Now you don't have to use a rubber duck. It can be any stuffed animal or in fact, any object around you. For example, your mouse, a pen or your coffee cup. Could you also use your cat or dog? Of course, you could, but you might get distracted with them, so some silent inanimate toy animal is the best. The main thing is to explain everything to the object as though you are explaining it to someone who knows nothing about the problem.

So why is this technique effective?

Firstly, the action of speaking out loud slows down our thinking process and makes our minds think differently. Our brain can process some staggering 800 words a minute, but we can only speak at about 120 words a minute. So instead of looking at the problem as a whole, slowing down gives our minds a chance to break down the information into pieces. And this can lead our minds to see different patterns between the parts and provide a different perspective on the problem.

Secondly, speaking aloud also forces our mind to focus on the problem by stopping it from wondering or spending too much energy juggling different thoughts. For example, according to the "Quarterly Journal of Experimental Psychology", just saying the word "chair" instead of just thinking about a "chair" actually increases brain activity and awareness of that chair.

Thirdly, explaining the code helps us understand it more deeply. This is also known as "the Protégé Effect". A student teaching something to another person demonstrates greater effort to learn and understand the material than just studying independently. As a result, we are more motivated to question whether what we are saying is correct. As a result, we will pay extra attention to the code and look for any information to help validate or explain what's happening.

And lastly, it's so easy to fall deep in the code that we don't see the larger picture, overlook some part of the code that we thought wasn't related, or make wrong assumptions. We can reduce any assumption bias by reading each line and explicitly explaining it to the duck.

You can also apply the inverse of "Rubber Duck Debugging" if another developer asks you to help find a specific bug. Play the role of the duck and ask them how their code or application works. More often than not, when they explain the code's flow, they will find the issue themselves before you even understand what the problem was or what the code is doing. And they'll give you a big "thank you" for literally doing nothing.

This technique is also helpful in solving general problems outside of software engineering. This could be a conflict with another person, writing a report, a homework problem or running into a roadblock with a big event. The simple act of putting your problem into words can shed light on the issue and give you some new insights.