Network Dictionary — Rubber Duck Debugging
April 15, 2009 by Greg Ferro · 5 Comments
As found at http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
We called it the Rubber Duck method of debugging. It goes like this:
1) Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety)
2) Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.
3) Explain to the duck what you code is supposed to do, and then go into detail and explain things line by line
4) At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.
Works every time. Actually, if you don’t have a rubber duck you could at a pinch ask a fellow programmer or engineer to sit in.
And don’t you feel foolish.…..
when, after hours or days of banging away and being completely stumped by something. Then you walk someone else through a problem, and you facepalm and realise EXACTLY WHERE the freaking problem was.
You blush, you mutter and say, thanks for the help. They look at you like you are an idiot and walk away grumbling.
AM I RIGHT ?
- Network Dictionary — Freelance
- Network Dictionary — Resume Generating Events
- Network Dictionary — Scalable
- Network Dictionary — magic hand wave
- Network Dictionary — NAT’d
- Network Dictionary — Pain Relief Technology
- Network Dictionary — workshop
- Network Dictionary — Process Humping
- Network Dictionary — appsellation
- Network Dictionary — Spinning Rust
- Network Dictionary — Server Hugger
- Network Dictionary — Facepalm
- Network Dictionary — Nortard
- Network Dictionary — Ciscotist
- Network Dictionary — longhorn
- Network Dictionary — IEEEdiot
- Network Dictionary — foo
- Network Dictionary — Ethereal
- Network Dictionary — Signal Slope
- Network Dictionary — leverage
- Network Dictionary — Microsoft Standard
- Network Dictionary — Brandalize
- Network Dictionary — Blamestorming
- Network Dictionary — CCIE Pounds
- Network Dictionary — borked
- Network Dictionary — technobabble
- Network Dictionary — Markenauts
- Network Dictionary — Implementation
- Network Dictionary — Distributed Attention
- Network Dictionary — functionality
- Network Dictionary — coffice
- Network Dictionary — Rubber Duck Debugging
- Network Dictionary — Unicorn Tears
- Network Dictionary — survivor’s bias
- Network Dictionary — IPocalypse
- Network Dictionary — slugged
- Network Dictionary — Project Manager
- Network Dictionary — Sanity Cheque
- Network Dictionary — goodthing
- Network Dictionary: Fun Detector
- Network Dictionary: Cock Blocked
- Network Dictionary — TACrathon
- Network Dictionary — Backhoe Attenuation
- Network Dictionary — heater
Please rate this post:
Why Rate Posts?
(1 votes, average: 7.00 out of 10)
Loading ...
You are more than right. I don’t code any more, but, when I was in college, I remember having an issue with an assignment. I went to the professor, began to show him what I did, and realized about 3.5 seconds into my explanation what was happening. Of course, this followed 10 hours of troubleshooting to no avail.
I may go get a duck just in case, though.
I’ve used this technique in reverse where I’m the rubber duck. When I can’t seem to communicate to someone why their idea won’t work, I say, “Well, okay. Explain it to me, using a whiteboard and small words. Perhaps I’m missing something. (Quack.)” Three boxes and few lines into the drawing, I usually witness the facepalm and a crestfallen expression. “Oh, I get what you were telling me now. It WON’T work, will it…”
Quack, quack.
_grin_