When I started my current job, I developed the ritual of writing email to the developer whenever I had a question about how code worked. Often, the developer no longer worked for the company, which didn’t matter, since I never sent the email anyway.
What I found was that I would write emails like “So.. I notice X, and Y, and Z. Which seems like they contradict each other. Of course, it’s possible that A is also true, which would explain it, but if A were true I’d expect to see B. Which...” (research) “I do indeed see. So, um, never mind.” and delete the email.
Eventually I figured out how to have that conversation entirely inside my head, but it took quite a while.
I am particularly fond of the framing that among “hackers” the value of a question is presumed to be in what it teaches. The authors don’t say this explicitly, but this contrasts sharply with the wider culture in which the value of a question is presumed to be in that it increases the status of the person being asked (whether they can answer it or not). Much of the intercultural communication failure around asking and answering questions can be traced back to that.
I’d never heard that expression, though I was familiar with the technique (with a teddy bear, though, not a duck). That said, I wasn’t actually programming at the time, just trying to understand what the code did.
I think I’ve seen it explained with a rubber duck more often, but I learned it
first with a teddy bear too, probably on page 123 of Kernighan & Pike’s
“wiener dog book”:
Another effective technique is to explain your code to someone else. This
will often cause you to explain the bug to yourself. Sometimes it takes no
more than a few sentences, followed by an embarrassed “Never mind, I see
what’s wrong. Sorry to bother you.” This works remarkably well; you can
even use non-programmers as listeners. 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 counselor.
Sounds like my thing where I can only locate objects after the ritual of saying “hey where is the”.
When I started my current job, I developed the ritual of writing email to the developer whenever I had a question about how code worked. Often, the developer no longer worked for the company, which didn’t matter, since I never sent the email anyway.
What I found was that I would write emails like “So.. I notice X, and Y, and Z. Which seems like they contradict each other. Of course, it’s possible that A is also true, which would explain it, but if A were true I’d expect to see B. Which...” (research) “I do indeed see. So, um, never mind.” and delete the email.
Eventually I figured out how to have that conversation entirely inside my head, but it took quite a while.
Eric S. Raymond and Rick Moen make a very similar point in How to Ask Questions the Smart Way.
That’s a lovely essay; thanks for the pointer.
I am particularly fond of the framing that among “hackers” the value of a question is presumed to be in what it teaches. The authors don’t say this explicitly, but this contrasts sharply with the wider culture in which the value of a question is presumed to be in that it increases the status of the person being asked (whether they can answer it or not). Much of the intercultural communication failure around asking and answering questions can be traced back to that.
This is called rubber ducking.
I’d never heard that expression, though I was familiar with the technique (with a teddy bear, though, not a duck). That said, I wasn’t actually programming at the time, just trying to understand what the code did.
I think I’ve seen it explained with a rubber duck more often, but I learned it first with a teddy bear too, probably on page 123 of Kernighan & Pike’s “wiener dog book”:
Yes! That’s exactly the anecdote wherein I first learned it.