In computer programming, there is a method to discovering the solutions to the bugs, or issues, within the code that prevents the code from functioning properly. This method is called “rubber ducking” and it comes from “The Pragmatic Programmer”, a book published in 1999 by two software developers. In this book, there is a tip for programmers to place an actual rubber duck at their desk and, when there is a bug in the code, verbally tell the rubber duck what the code is supposed to do, line by line.By using this method, the programmer will 9/10 times figure out what the issue is through individual verbal discussion, and will have an “AHA!” moment when they find the missing logic.
This type of troubleshooting is not new. Any engineer knows to logically walk through the foundations of a design to ensure they are correct before moving forward with the completion of the project. If the project is completed and isn’t working, a walkthrough of logic will ALWAYS be necessary. The troubleshooting logic must be methodical and organized or the solution will take a dozen times longer to find. Think of assembling a piece of furniture from Ikea. If you miss a step, you might find that you hammered a piece into place that actually needed something else attached before the final assembly. Because you missed that pertinent step, you now have a piece of furniture that is put together but will fail the moment it is used. You have to disassemble the hard work you have done, add in the step, and reassemble (Ask me how I knew this particular furniture issue *cough* TV mount *cough*). If you look for the issue sporadically through the assembly directions, you will probably not find the issue. Methodically and systematically…line by line…rubber duck.
Luckily, computer programming is less physically laborious than building furniture. If a piece of the code puzzle is missing, you simply type it in or perhaps move some code around with a good ol’ “copy and paste”.
Why a rubber duck? Why not your teammates? Why not Google? Why not a partner? Here is the thing: A GOOD SOFTWARE DEVELOPMENT TEAM IS ONE GIANT RUBBER DUCK. It was discovered that when a programmer becomes frustrated and asks for the team to stop what they are doing and listen to their issue, everyone stopped the train of thought for their own code (extremely frustrating for the other developers who are “in the zone”), swiveled around, and listened to someone talk to themselves until the programmer said, “Oh, figured it out, thanks for the help.” The team typically does nothing but listens and watches the solution form in the programmer’s head in front of their eyes. Occasionally, a teammate might suggest something, but the programmer typically figures it out alone. It wastes everyone’s time to stop their coding to listen to a pointless monologue.
When I was in grad school taking a particularly fast paced Java course, I had a classmate who seriously helped me out, rubber duck style. We would always stay up until midnight or later coding and discussing frustrations on the phone. One particular night, we were working on our individual projects while on the phone. There would be silence unless we were asking each other a question. I got particularly frustrated with one part and just ranted for a solid five minutes and actually figured out my issue. I thanked him for the help as I turned in my project and he said, “Huh? I wasn’t even listening.” I needed to just rubber duck it.
If you think rubber ducking is only applicable to computer programming, think again. There are issues in every aspect of our lives that we need to figure out. Problems can be technical, social, sexual, psychological…
Next time you have an issue, rubber duck it. Better yet, socratically rubber duck it. Take rubber ducking to the next level.
Rubber ducking is very one sided and requires the person talking to the rubber duck to know exactly what they are doing in order to figure out the solution alone. This is very assuming of the person talking to the rubber duck. Do they know the answer? Maybe, especially if it’s a technical issue. But what happens when they don’t know the answer? The problems of our lives are complex, and one person can’t assume they know enough about the world to be their own rubber duck. Rubber ducking without exposure to others’ experience is how dangerous ideologies are born. People who don’t challenge their own beliefs or critically think about the world are the type to be socially backwards, non-evolutionary, and out of the socratic circle.
I use people as rubber ducks constantly for my personal and professional life. I’m sure it is annoying to be my rubber duck (sorry, Bambi and other associates of mine) because I probably don’t want your opinion; I want you to listen to me until I figure it out or until I get frustrated with you for not giving me a nudge in the right direction or towards a different way of thinking. I want you to be socratic in your responses. I want you to stimulate my critical thinking through well-educated questions and remarks that do not insult me but rather, cause me to seriously think about a solution, even if I don’t like it. I am known as being an arguer. However, I don’t see myself as an arguer (See?). I see myself as someone who wants to critically discuss literally everything that I think pertains to me and the world that I care about, professionally or personally. How else am I supposed to grow emotionally and intellectually? People who say I just like to argue frustrate me because I am challenging them and myself to think differently, to think further, to not accept the norm.
Be socratic in your life, and rubber duck your problems with a wide variety of people. Figure out the solutions to your problems that might not be obvious as a solo rubber duck. And don’t forget to be a socratic rubber duck to others.
