Rubber Duck Debugging: How Talking to a Toy Can Help You Fix Bugs

Stress, fatigue, external problems... every programmer must fight with errors or failures in their code, and there are plenty of reasons for debugging to become a nightmare. However, there is a very curious technique that goes back to the late '90s, and it involves a rubber duck. What is the exact idea? That the programmer is forced to explain the code to the duck one line at a time, and through that deconstruction process, find the solution.

The Origins: 'The Pragmatic Programmer'

The story goes back to 1999, when Andrew Hunt and David Thomas wrote 'The Pragmatic Programmer', a book that quickly became a university textbook. With short stories and other tricks, Hunt and Thomas give aspiring programmers tools to optimize their development process, starting with the need to be an 'early adopter', adapt at great speed, never lose critical thinking or realism, and act as a wildcard.

Unfortunately, it's not a very accessible title. Its latest edition doesn't go below 45 euros (unless you go for the digital version), and if my memory doesn't fail me, it was never translated into Spanish. But there is a small detail in that book that set itself apart in record time, and that many programmers swear by.

How the Rubber Duck Technique Works

The key is to place a rubber duck on your desk. When the programmer can't find a bug or gets stuck, the duck becomes a kind of passive listener and student. The developer proceeds to explain the problem step by step, and through that explanation, finds the solution. This is quite common among colleagues and coworkers (or programmers talking to their pets), but the duck has two important advantages: it doesn't interrupt, and it prevents you from bothering someone else.

The most valuable thing is that it forces the programmer to start from the beginning, and as they go, they "reanalyze" the code in their mind. That updated visualization often brings enough clarity to detect the problem, to such a point that sometimes only one or two details of the issue need to be described. It seems like a joke, but it's not. While some tasks require total focus, others need to be "disassembled" in some way, even when the only audience is a rubber duck.