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
I
Even more fun than
I have
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
Normally,
¯_(ツ)_/¯
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.
Photo by Andrew Wulf on Unsplash