Rubber Duck Debugging: Where the Explanation Goes

Explaining a problem step by step to something that cannot help you, until you hear the gap in your own reasoning. The name is 27 years old and the duck is interchangeable.

A programmer carries a rubber duck and explains the code to it, line by line. Somewhere in the middle of the explanation, the bug becomes obvious. That story is from 1999 and the name stuck.

Nothing was added. The duck did not help. You said the thing out loud and heard it land wrong.

The object is interchangeable. A cat works. So does a colleague told in advance not to listen.

I usually say to a coworker that I'm going to talk and they don't need to listen to me.

What matters is that it cannot answer. If it could, you would ask instead — describe the symptom, stop, wait. Explaining is a different act from asking, and the explaining does the work.

Because you cannot skim out loud. Reading lets you nod along at the abstraction you already believe. Saying it forces every step into words, and the step you cannot say is the broken one.

Reading is fast because it is allowed to be approximate. Your eyes accept a line of code as the thing you meant. Your mouth will not. It has to say the printer stops when someone opens the door and presses cancel. That word — and — is where you hear it. You meant or.

when you start talking about them it can become more obvious that you flipped something around

It works on the way in too, which is why this is a revision technique as well as a debugging one. Something you understand loosely will not survive being said in order, with nothing skipped.

As a medical student, I never really know if I understand something until I explain it out loud to either a friend or my empty room.

The mechanism has nothing to do with code. It shows up in exam revision, at help desks, in engineering and at home.

The name stayed in programming. The behaviour did not.

There's so many times when I'm at work (not programming) when I've been stuck / confused / indecisive about something, spent ages going over and over and getting nowhere, until I ask a colleague to come and have a look.

The ending is the recognisable part: "so what do you need to ask me?" — "errr..... nevermind, doesn't matter".

Help desks run on this without naming it: a fault often resolves itself while the person is demonstrating it. Students use it for exams. Engineers use it for designs.

I have a cuddly red blood cell I explain things like DNA transcription to. Seriously, he has no idea what it's all about.

The people it happens to most have a name for themselves: chronic verbal processor. It is not a diagnosis. It describes someone whose thinking does not finish until it has been said to somebody.

If that is you, you already know. You have probably also noticed the other half.

It gets destroyed, and usually on purpose. The tools people write in are built for delivery rather than for keeping, so once the problem is solved the explanation has nowhere to live.

Talking is not the only route. You can get there by writing — an email, a chat message, a forum question — and the answer often arrives before the writing is finished.

Then the writing is thrown away.

The drafted email goes to the trash and no one knows I'm dumb

I don't even pretend. Sometimes I'll be legitimately writing one to post … and I eventually abandon the question.

The most deliberate version builds the thing so that it cannot be sent at all.

draft an email to that person, (but leave the to: field blank, so I don't accidentally send it)

That is not carelessness. It is the medium. An email, a chat message and a forum question are all built for delivery, so each has exactly two exits: send it, or delete it. Neither exit is keep.

Look at where yours went. Sent, and now it lives in someone else's inbox rather than in your record. Or deleted, because what made you write it was embarrassment, which left when the answer arrived. Nothing in the tool offered a third option, and you never noticed one was missing.

The drawings rarely make sense in retrospect, but they "free up some space on my head" at the time so I can think about other stuff.

Sometimes you keep it and it has stopped meaning anything. Which is fine for the pressure and useless for the record. Either way, the version of your thinking that finally made the problem make sense is the one that does not exist tomorrow.

Both obvious fixes change the thing that was working. Writing a document turns explaining into producing. Asking a model turns it back into asking.

So write a proper document instead. Same slowing down, and you keep it afterwards. That is a fair objection.

This bleeding edge "document" approach seems a bit of sci-fi here.

But writing a document is a different activity. You pick a structure. You decide where it lives. By then you are producing again, and producing is what you were stuck on. When the explaining involves other people and has to end in a deliverable, that is a different job with a different answer.

Asking a language model is the other obvious fix, and it is a real option. It also changes the exercise. A duck cannot answer, which is why you keep explaining. A model answers, so you stop explaining and start reading.

the response from copilot can help a lot, even tho it's often missed the point and answered some other problem

Sometimes an answer is exactly what you want. When it is not, the useful property of the duck is that it is useless.

The test is narrow: whatever catches this must not change how you explain. Speech is the only medium where the record costs nothing extra.

If you have to open something, choose a format, or decide where it belongs, you have started producing again. Speech does not have that problem. You were going to say it out loud, the words already exist, and the only question is whether anything was on.

And the thing worth keeping is not the conclusion. You will remember that for a week, and you will write it into the code or the plan anyway. What disappears is the route: the four options you ruled out, the assumption you did not know you were making, the reason you rejected the approach you are about to try again in March.

Pastok is a voice capture app for iPhone and Apple Watch. You start the session; nothing begins on its own. Afterwards the transcript is searchable by meaning.

You start a session with one tap from the watch face, or from the phone when that is nearer. Nothing starts by itself. Getting stuck is not scheduled, and Pastok cannot know it happened.

So there are two honest ways it helps. The first is deliberate. You are stuck, you tap once, and you explain the problem to your wrist until you hear the gap. There is no app-imposed limit on how long that runs; the Apple Watch battery is the ceiling.

The second catches more of it. If a session is already running — a walk, a commute, a block of work — the thinking you do out loud inside it is already in the transcript. You decided to record the hour, not the idea.

Afterwards the audio is deleted after processing, within seven days by default. The transcript stays until you delete it, and you search it by meaning rather than by the word you happened to use. That matters here, because you will not remember the word. You were talking, not writing.

A Skill can read back over a window you choose and pull out what you worked through. Each run gives its own output rather than adding to a growing list, so treat it as a Sunday read, not a ledger.

Next time you are stuck, try the oldest thing. Say it out loud to something that cannot help you. It will work more often than it has any right to, and the only decision left is whether anything was listening.