I am reposting this article I wrote here since it is no longer available at the original publication source! Enjoy!

GD

Disruptions are productivity killers. If you are reading this, perhaps you already know that. There are times when taking a break to chat with your peers and co-workers can actually help you get back on track.

had one such chat with Jeremy Woertink about team dynamics and communications for a talk I will be doing in Austin for this year’s SXSW Interactive Conference, and I needed to validate my thoughts with my peers. After about 3 breadsticks and half a salad (since we were chatting at Olive Garden), he told me about how important non-technical people are to a developer.

We were chatting about distractions, and I was stressing the importance of limiting distractions as a developer (a topic I care very much about), but he wanted to stress the importance of having those distractions, just at the right times. Downtime for a developer is needed, as with any vocation, to recharge and clear your head. This becomes even more important when you are really blocked by a task. This is why you see a Foosball table or Xbox in the common areas of many dev shops. It’s sometimes in these moments where a stuck developer can finally figure out how to solve a problem or architect a new feature.

He went on to say, “At the least, finding a good Rubber Duck can save a bad day.”

Confused? Let me give you an example:

“What’s up, Jeremy? You look stressed out.”

– Sales Dude

“I’m struggling with this weird bug! I’ve got all these employee objects that my code goes through and I want to update the employees that have more than … huh. Actually, I think I know what it is now. Thanks for your help.”

– Rockstar Developer Jeremy

blinking hard

– Sales Dude

Sales dude was Jeremy’s Rubber Duck.

A Rubber Duck is the concept of explaining a programming problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem. The mere act of attempting to describe both 1) what the code is supposed to do and 2) what it actually does, can often make the actual problem clear.

The name Rubber Duck comes from an idea in The Pragmatic Programmer (1999), a non-technical book by Andrew Hunt and David Thomas, that explores software development as a craft. In one chapter, Debugging Strategies, the author suggests explaining the code line by line to an inanimate object, like a Rubber Duck, to accomplish this without an actual person.

Why would the author use a Rubber Duck as an example? David Thomas worked with a research assistant named Greg Pugh who would carry around a small yellow duck that he would place on his 3270 terminal while coding.

Work on a team with some developers? Don’t leave them pair programming with Rubber Ducks…offer your ear, don’t say a word, and let them do all the heavy lifting.

Rubber Duckie, you’re the one,
You make bathtime lots of fun,
Rubber Duckie, I’m awfully fond of you;

(woh woh, bee doh!)

Rubber Duckie, joy of joys,
When I squeeze you, you make noise!
Rubber Duckie, you’re my very best friend, it’s true.

Every day when I,
Make my way to the tubby,
I find a liddle fellah who’s,
Cute and yellah and chuu-by
(Rub-a-dub dubby!)

Rubber Duckie, you’re so fine,
And I’m lucky that you’re mine,
Rubber Duckie, I’m awfully fond of,
Rubber Duckie, I’d like a whole pond of-
Rubber Duckie, I’m awfully fond of you!