Talking to My Rubber Duck Helps Me Write Better Code and Improve My Business
By: Sammy Jones
Tags: Self Improvement, Life Lessons, Development, Programming, Business

Talking to My Rubber Duck Helps Me Write Better Code and Improve My Business

Talking to a rubber duck is normally a sign of madness, but it can lead to better coding and improve business processes.

Photo by Nick Fewings on Unsplash

Talking to a rubber duck is a globally recognized way to help with debugging coding, but it can easily be used throughout any business. It is a fun process that tricks you into viewing your work with a fresh set of eyes.

Like most people I was very skeptical about talking to a rubber duck (other soft toys are available), however, I tried it and it worked. The first bug I found using my rubber duck was a simple typo that had remained hidden from me for a good couple of hours. That was a decade ago and I’m still using the process today!

It is a fun way of debugging problems that can also reduce your stress levels. Just take your duck out of the bath first!

What Is Rubber Duck Debugging?

Photo by Jonathan Kemper on Unsplash

At first glance rubber duck debugging seems very unscientific. That is mainly because it is completely unscientific! However, it works, and I use it at least 3 or 4 times a month.

When I’m stuck debugging a program, I sit my little rubber duck between my keyboard and my monitor and explain each line of the program to it. By the way, my duck is called Howard, after the err… duck.

It sounds idiotic, but it works and can catch the most elusive bugs. It can also be used for debugging non-programming tasks, but more on that in a bit.

By explaining your code to your rubber friend, it forces you to do a couple of things;

First, you have to read every part of your code. It is surprising how many spelling and syntax errors this will highlight for you.

Second, you have to put into words the theory behind your programming logic. This won’t be the logic you aimed to use when you started, but the actual logic behind the programming you created. If you struggle to explain a part of your coding logic, the chances are you have found the broken part of your code.

Of course, it doesn’t need to be a rubber duck that you talk to and you don’t have to talk out aloud. I’ve seen programmers substitute their duck for soft toys, Star Wars figures, and Lego figures. I got fed up with losing my rubber duck on my travels, so I now have a sticker of Howard the duck next to my laptop’s trackpad.

The important part is the explaining of your programming to someone (or something) else. It forces you to look at your work in more detail than you would just reading or scanning through your code.

How Rubber Duck Debugging Helps Me Write Better Code

Photo by Aleks Marinkovic on Unsplash

I now use Howard for all aspects of my development work, even before I have touched my keyboard.

If I’m not sure of anything when pre-planning my work, I will explain everything to Howard. This will include my flow charts, my processes maps, SQL schemas, data sources, and any other aspect I’m not sure how to handle.

Not only does this debug the processes I intended to follow, but it also helps spot opportunities to simplify and improve the processes.

It can also help identify gaps in supporting systems and gaps in the source data that you have to rely on.

One place I find it particularly helpful is when planning user interfaces and user inputs. For example, it helps ensure I have logically grouped inputs from a user’s perspective rather than a programmer’s.

How Rubber Duck Debugging Helps Create Better Business Practices

Photo by JOSHUA COLEMAN on Unsplash

Rubber duck debugging is not limited to debugging coding, it can also be used to debug any processes, including business processes.

It works in the same way. Just explain your process to your duck (without just reading it aloud to your duck) and look out for anything you can’t easily explain. By mentally rewording your process, as though you were explaining it to someone, forces you into ensuring you understand what is going on in your processes.

Any gaps will become clear as you won’t be able to easily explain it.

If your processes involve various departments, it is worth repeating the exercise for each department. Each time you move on to a different department, put that department’s hat on the duck and explain that department’s part of the process to your duck.

When you debugged each department’s processes, you can replace the duck with actual people from each department. By this time, you would have already headed off any process issues they may ask about.

When applying this to existing business processes, it can identify cases of “We always do that way, because we’ve always done it that way”. If the only explanation for a process step is “we’ve always done it that way”, the process needs investigating, removing, and/or replacing.

Taking It to the Next Level By Talking to Yourself

Photo by icon0.com from Pexels

If talking to your rubber duck doesn’t work, you can refer to a higher authority by talking to yourself. This process should be called “Double Rubber Ducking” as it gives you a second chance to debug things.

While you are explaining your work to your duck, record yourself and your explanations. Sorry, you will have to have to talk out loud to your duck here. Once you have completed your recording, have a cup of tea or a bite to eat before coming back to your recordings.

Now play the recordings back to yourself. Listen carefully to what you are saying and follow along in your coding or business process. Does what you are saying in the recording match up with what you are seeing in your coding or processes? Did you miss a step? Did you leave in something you meant to take out?

But above all question everything you say in your recording — after all, the person in the recording is the person who caused the problem in the first place!

Conclusions

There isn’t any science to this approach, but it is a globally recognized approach to debugging your work. And it works surprisingly well.

Most debugging issues are simple issues resulting from typos or our own stupidity. After all, we are humans and we make mistakes. This simple process is ideal for finding these simple issues.

One other great benefit is that it can also take the stress out of the situation. A lot of debugging work is done under stress, especially if there is a deadline looming or people can’t work because their software has stopped working.

Talking to a rubber duck is hard to do without smiling or raising a few laughs around the office. You can also launch the rubber duck across the room when you find the last two hours of debugging was because of a missing semi-colon. It is very therapeutic hearing your rubber duck squeak as it bounces off the nearest wall!