One of my favorite things to do as a developer is rubber ducking with other devs.

If you aren’t familiar with rubber ducking, the term comes from the book The Pragmatic Programmer in which a dev would explain, line by line, their code to a rubber duck.

Writing code is hard, and interesting, and tricky, and challenging. And frustrating. And disappointing. And humbling. This is especially so when faced with a bug we can’t identify, or a side effect that makes no sense.

I often take to our company Slack when I’m in a sticky situation, asking for someone that isn’t busy to rubber duck. It seldom matters who is available. The role of ‘duck’ isn’t to solve the problem. It’s to listen, occasionally ask questions, and relate to the feeling of being ‘stuck.’ They don’t need to know the project, my IDE, or even understand the code.

I’ve announced, “I need a rubber duck to help me with some weird js modal issues,” and ended up discovering my issue was with post content. I’ve had a rubber duck session that took ten minutes. Then I realized I was testing on staging while making code changes on my local.

I rubber ducked my first WordPress patch.

via GIPHY

Even more fun than rubber ducking is being the duck. Asking for a rubber duck in a team can feel like you’re being a burden. It’s an admission of, “I can’t figure this thing out.” We as devs take pride in how we can think through any sticky situation.

I have rubber ducked for some amazing developers at WebDevStudios. It’s easy to forget as rubber duck that your job is not to solve the issue. It’s to listen, empathize, ask questions, and relate.

I’ve seen issues in code in the first minute, and I’ve spent thirty minutes listening without understanding more than the cursory description of the problem, and everything in between. In all cases the rubber ducking was successful because the goal isn’t to jump in and solve the person’s programming issue. It’s to reset the approach and provide new perspective. There is no place for blame, pity, or frustration. It’s simply an opportunity to hack our human brains into being okay with… well… being human.

Normally, rubber ducking isn’t super time-consuming. A screen share starts, the dev with the problem frames it. The rubber duck may ask for some general background to get a mental model of the problem and then…

¯\_(ツ)_/¯

Sidebar: I know we as devs aren’t supposed to be social. Writing code is usually a solitary endeavor. We all know that the final draft of our code has been wrestled with, refactored, and rewritten. When you duck or rubber duck, you are inserting two people into an incomplete thought. Be cognizant of the person behind the code. Sometimes it’s hard to remember that we are not our code.

rubber ducking is an amazing tool. It gives perspective; it resets our approach to a problem. It doesn’t indict or blame. Hopefully you have a great team of developers you can rubber duck with. If not, take to Twitter, your local meetup, or whatever social circle of technical people you have and agree to rubber duck for one another. Most importantly, set the example and be the rubber duck you’d want.


Photo by Andrew Wulf on Unsplash


Also published on Medium.

1 thought on “Rubber Ducking

Have a comment?

Your email address will not be published. Required fields are marked *

accessibilityadminaggregationanchorbackupsbookmarksbuddypresscachingcalendarcaret-downcartunifiedcrediblecustommigrationdesigndevecomfriendsgoodgroupsgrowthhostingideasinternationalizationiphoneloyaltymailhealthmessagingArtboard 1migrationsmultiple-sourcesmultisitenotificationsperformancephoneprofilesresearchscalablescrapingsecuresharearrowarrowsourcestreamsupportunifiedupdatesvaultwebsitewordpress