
Classic: Rubber Duck debugging - jaybol
http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
======
cruise02
> Actually, if you don't have a rubber duck you could at a pinch ask a fellow
> programmer or engineer to sit in.

In my experience the rubber duck works better because it doesn't try to talk
back to you or interfere in any way.

~~~
city41
And the idea is to not waste a coworker's time when a rubber duck would
actually suffice.

~~~
stcredzero
An HR tip for increasing office efficiency: only hire programmers who look
less intelligent than rubber ducks.

------
jgrahamc
See also Turing's Teddy. <http://blog.jgc.org/2010/05/talking-to-porgy.html>

------
danielsoneg
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...

~~~
wnoise
I definitely prefer the teddy bear -- a bugbear is so much cooler than a
bugduck.

------
danilocampos
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.

~~~
dekz
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.

------
davnola
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.

I'll tell him he's my rubber duck.

------
seldo
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.

------
varikin
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.

------
stcredzero
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?

~~~
phaedrus
> 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.

~~~
stcredzero
_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.

------
gordonguthrie
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)

------
kitchen
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)

They're quite effective actually :)

------
nowarninglabel
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...

~~~
stcredzero
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.

------
wazoox
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 :)

------
eof
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.

