Rubber duck debugging

The practice is often attributed to Andrew Hunt and David Thomas, who described it in their 1999 book The Pragmatic Programmer. They recounted a story of a programmer who carried a rubber duck and debugged by explaining his code to it. However, the concept of talking through a problem aloud to an inanimate object predates this; it is a form of self-explanation, a cognitive strategy studied in education. The term gained widespread popularity in the 2000s through online programming communities, and rubber ducks became a common sight on programmers' desks.

Rubber duck debugging works by forcing the programmer to slow down and articulate their assumptions and logic. This process often reveals discrepancies between what the code is supposed to do and what it actually does. Research on self-explanation suggests that verbalizing one's reasoning can improve problem-solving and comprehension. In practice, the technique is effective because it encourages a systematic review of the code, similar to a code review, but without the social pressure of another person. It is particularly useful for elusive bugs that persist despite other debugging methods.

While the rubber duck is the archetypal object, any inanimate object can serve the purpose—a teddy bear, a plant, or even a cactus. Some programmers use a rubber duck emulator or a chatbot that listens to the explanation. The technique is related to pair programming, where a human partner plays a similar role, and to the Socratic method of questioning. In some agile methodologies, a 'rubber duck' is a designated person who listens without interrupting, a practice known as rubber ducking in a team context.

Beyond debugging, rubber ducking is used in other fields: writers explain plots to a duck to untangle narratives, and mathematicians talk through proofs. The term has entered the lexicon of software engineering folklore, and there are even rubber duck debugging conferences and merchandise. A notable edge case is the 'rubber duck effect' in test-driven development, where writing a test that fails can serve a similar purpose. Some programmers report that the duck's 'silence' is key, as it avoids the interruptions that a human might offer, allowing the programmer to maintain their train of thought.

Rubber ducking

The act of explaining code to an inanimate object as a debugging technique.

Self-explanation

A cognitive strategy where individuals explain material to themselves to enhance understanding.

Pair programming

A software development technique where two programmers work together at one workstation.