I heard a similar story. Back in the day, when computers were big and slow, there was a debugging room in the Bell Labs. When a programmer had difficulties debugging his piece of code, he went to that room and talk to a teddy bear about his code and the error he's getting. This should have made him realize what he's doing wrong. I don't know how successful the method was for them, however it works often for me.
"One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counsellor." - The Practice of Programming, Kernighan and Pike 1999.
It's a good book and a good technique. We used to use the director for the same purpose at my first "real" job. He couldn't program but he was really good at looking skeptical.
This has a own section in the book The Pragmatic Programmer.
Chapter 3, Debugging, Rubber Ducking.
However, even if I agree with the great use I really use it more for code reviews than for actual hardcore debugging. (This could be my fault because I use distributed async processes in my work)
I think the rubber ducking has more advantage if you use a high level dynamic type language to code in (rather than more low-level C with pointers).
Funny, I'm quite often the 'rubber duck' for other members of my team. I was thinking of trying to find a way to get a cardboard cutout of myself that they could pull out when needed.
This is a great method. I always start writing an email to another developer when I'm having a problem, and by the time I finish it I've usually solved my issue.
