Rubber Ducking

Photo by Andrew Wulf on Unsplash

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 duck

ed my first WordPress patch.

via GIPHY

Even more fun than

ing is being the duck. Asking for a

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 duck

ed 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 duck

ing 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 duck

ing 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 duck

ing 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.


Originally published at WebDevStudios.