I am reposting this article I wrote here since it is no longer available at the original publication source!
Disruptions harm productivity. Strategic breaks with colleagues, however, can refocus developers who are stuck on problems.
I had discussed team dynamics and communication with Jeremy Woertink while preparing remarks for SXSW Interactive Conference. Woertink emphasized that non-technical people provide value to developers, particularly during challenging moments. While limiting distractions matters, appropriate downtime allows developers to recharge and solve difficult problems—which is why many development shops include recreational spaces.
Woertink shared: “Finding a good Rubber Duck can save a bad day.”
What Is Rubber Duck Debugging?
A Rubber Duck is a concept where developers explain programming problems to someone else—even someone without technical knowledge—and often discover solutions through articulation. Describing both intended behavior and actual behavior frequently reveals the underlying issue.
The term originates from The Pragmatic Programmer (1999) by Andrew Hunt and David Thomas. In their debugging chapter, they suggested explaining code line-by-line to an inanimate object. David Thomas collaborated with Greg Pugh, who carried a small yellow duck he’d place on his IBM 3270 terminal while coding.
Implementation
Rather than pairing developers with rubber ducks, teams should provide human listeners. Simply offering your ear—without speaking—lets the developer perform all necessary cognitive work.