Classic: Rubber Duck debugging

&#62; Actually, if you don't have a rubber duck you could at a pinch ask a fellow programmer or engineer to sit in.<p>In my experience the rubber duck works better because it doesn't try to talk back to you or interfere in any way.

See also Turing's Teddy. <a href="http://blog.jgc.org/2010/05/talking-to-porgy.html" rel="nofollow">http://blog.jgc.org/2010/05/talking-to-porgy.html</a>

There was an article along these lines up here not too long ago. My favorite anecdote was about a tech support department that had a stuffed teddy bear outside the room - to get in, you had to explain exactly what the problem was to the teddy bear. Apparently the teddy bear solved about half the problems people had...

Great approach. Being forced to wrap some words around your problem is really helpful. I didn't have a duck nearby so I recently talked to my hand during a challenging adventure in threaded code.<p>How often have you grabbed a colleague for help, gotten half way through explaining the problem, then said "Oh, I'm an idiot, I see the problem, nevermind."<p>It also works for more abstract problems. If the rubber duck isn't your style, grab a notebook and a pencil then interview yourself on paper about whatever is giving you trouble. (life, career, relationship, motivation, inspiration, anything) I've had some great insights and ideas tumble out of this process – stuff I simply would not have thought of otherwise.

I have a customer who swears that whenever I tell him I've run into a difficult problem, by the third time I've explained it to him, I've solved it.<p>I'll tell him he's my rubber duck.

This is an <i>astonishingly</i> effective technique. I feel a bit of an ass talking to a duck (in my case, a stress ball with a smiley face on it) but much less of an ass than coming to a co-worker with a stupid problem.<p>NB: silently looking over the code is not the same. Something about having to explain it to a third party makes you question your assumptions in a way that is helpful.

I have used a variation of by using email. When I get to the point of needing to ask for help, I write an email to so coworkers. Half the time, I get the answer just by thinking about the best way to describe and write down the problem.

This got me thinking about literate programming. Here's a thought: why not use natural language to specify a program, but add annotations to disambiguate the parts which are ambiguous due to the inherent fuzziness of natural language?

My rubber duck is the mailing list. So there is some difficult problem that I can't fix. I start writing an e-mail (or a stackoverflow post) and then as I work through the description of what I have done I see the problem)

I have 2 ducks on my desk for this very reason. That and because others around the office have them and when one talks the rest start talking too (just like dogs in a neighborhood)<p>They're quite effective actually :)

So old, but I do tell all my student assistants to do this. Unfortunately, they usually opt for the in a pinch ask a co-worker option. Hmm, I think I am going to buy rubber ducks...

I have a stone statue of a sacred indian dancing girl on my desk. I use her as a rubber duck. Yes, I know, this wouldn't work at all for most common uses of a rubber duck :)

Works well, but not every time. Sometimes, a line of code will behave in a way you don't expect; thus you will wrongly explain it to the duck. I think we literally 'see' code that isn't there due to the well known phenomenon of not registering something that is out of the ordinary and instead categorizing it as something expected while actually experiencing it as something that it is not.