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
to help me with some weird js modal issues,” and ended up discovering my issue was with post content. I’ve had a
session that took ten minutes. Then I realized I was testing on staging while making code changes on my local.
ed my first WordPress patch.
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.
ed for some amazing developers at WebDevStudios. It’s easy to forget as
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
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.
ing isn’t super time-consuming. A screen share starts, the dev with the problem frames it. The
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.
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
with. If not, take to Twitter, your local meetup, or whatever social circle of technical people you have and agree to
for one another. Most importantly, set the example and be the
Originally published at WebDevStudios.