.. because your brain ain’t listening.
I forget where I first read about the technique known as rubber ducking. I’m pretty sure it was in a book called “The pragmatic programmer” by Andrew Hunt and David Thomas. I’d highly recommend The Pragmatic Programmer to any programmer, if only for its exhaustive application of the DRY principle – but that I’ll save for another blog post.
The idea behind rubber ducking originates with a programmer struggling with a problem. After the best part of an hour wrestling with it in your brain she concedes and goes to seek the assistance of a colleague. She describes her problem to the colleague, step by step, covering all bases, and as she does so she has some sort of epiphany, sees the light at the end of the tunnel and enthusiastically returns to her own computer leaving her bemused colleague, who hasn’t uttered a single word but has been interrupted, it would seem needlessly.
A rubber duck on your desk can prevent such interruptions. The solution is simple. Whenever you have a problem you just can’t get your head round – talk to the duck. Not mentally – talk out loud – to the duck – describing exactly what each line of code does. Not what you think it does – read the code – tell the duck.
A google search will reveal a host of websites that describe this technique – offering a slew of explanations as to why it works and what the advantages are. Don’t take my word for it – check it out for yourself.
My favourite advantage is “Rubber ducks don’t gossip about your private problems with other rubber ducks.”