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.
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."
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've only been programming for a few years, but this has to be one of the most successful methodologies I've added to my arsenal. Instead of an actual anthropomorphic figure, I use a chat window with someone. Mostly they ignore it, but I still type in that window what the code should be doing. More often then not someone might reply with "wtf why". Which is great because the duck in this case can provide feedback and thought.
I know of a few places like THQ in Australia which promote this idea of rubber ducking.
Also paper and pencil works well for when your only option is to printf debug (embedded devices with no support).
I just hate those times when you've misunderstood the API and you expect certain functionality which isn't its actual defined functionality. You live, you learn.
This is an astonishingly 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.
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?
> 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?
That's far from a new idea; that misguided idea is how monstrosities like COBOL got inflicted on innocent programmers. Here's the problem: whatever you create, will not really be a natural language, it will just be another programming language. Yet for some reason everyone who has this idea thinks no one else ever thought of it. It's the computer science equivalent of perpetual motion physics cranks.
Here's the problem: whatever you create, will not really be a natural language, it will just be another programming language.
This is not what I was suggesting at all. I am thinking along the lines of Knuth's literate programming. What I'm proposing is a programming language combined with natural language, but instead of annotating a programming language with natural language annotations, I'm proposing doing it the other way around. There would still be two separate languages involved. You are talking about a single notation system with the qualities of both natural language and a programming language. Yes, that is a crank idea, which your mind seems to be stuck on.
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)
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...
This is all your fault, you see. You need to start "hiring" student assistants who look less intelligent than rubber ducks or random office equipment. Then your student assistants would be less apt to take up each other's time.
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.
In my experience the rubber duck works better because it doesn't try to talk back to you or interfere in any way.