How do I do it?
The method itself is quite simple:
- Step 1: Obtain a rubber duck. Any duck will do; larger, bath-time ducks are preferred, but keyring ducks are acceptable and can be handy to keep around. You can even use the one above in a pinch.
- Step 2:
Explain your code to the "duck". You must remember to:
- Explain each logical step/branch out loud and in detail
- Point to the screen as you do this, so the duck knows which lines/syntax/text you're referring to
- Step 3: Continue until the solution to the problem is provided by the duck's serene attention.
How does it work?
Rubber ducks originated from the Tibetan mountain encampments of Zen monks, who would use small wooden duck statues as a meditation aid. Over millenia the concentration of Zen masters was focussed on these statues, flooding them with thoughtwaves, which were captured and stored. Eventually, once the Zen masters had reflected on the statues enough, these ducks were gifted to small children in local villages, who would use them as toys during bathing. It was found that children who received the ducks would sleep more soundly and their nature would become calmer, which is why we have rubber ducks in many cultures around the world.
It has been found that, through quantum morphic resonance, any item which follows the shape of the original statues becomes a receptical for the Zen contemplations. This deliberation leaks out of the ducks as delta-waves, and in talking to the ducks we latch on to these delta-waves which ties us directly into a mystical thought-network which permeates the globe. When using a colleague as a duck, the colleague must hold the shape of a rubber duck in their mind, to act as a bridge to the mystical thought-network.
...right... but how does it really work?
As developers we can become so familiar with the code that we don't notice small errors creep in when we're "in the zone", writing the logic we need at this point in the source while focussing on the larger picture.
The act of reading aloud slows us down, and pointing at the code forces us to review the syntax and logic directly under our finger. We can then easily see where the code is doing something different to what we *think* it is doing.