Rubber Duck Debugging

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.

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.