I don't believe in rubber-duck debugging as a deliberate practice - you don't know that you'll work out your problem in the process of explaining it. It just happens sometimes.

I'm not sure where I first heard of rubber duck debugging, but in my experience there is rarely a physical rubber duck at all. It's more of a "can I rubber duck you on something for a minute?" "Yea, sure!" "<starts explaining> ... ah I've figured it out cheers".

This frequently happens to me in the middle of writing a support ticket, which I try to make as detailed as possible for that specific purpose.

That's not only a lovely story, it also holds useful insights about effective problem solving and collaboration (or when the best collaboration is just listening).

There's a different but somewhat related "no response necessary" communication technique my wife and I discovered. This occurred when she would share a problem she'd recently faced with me. Being an engineer, I'd listen to the problem and then helpfully try to suggest possible solutions. Sometimes this was fine but on other occasions, she'd seem to just disconnect or even get frustrated. But which way things went didn't seem dependent on the usefulness of my answer.

The realization came one day when I was kind of disappointed that the comprehensive rank-ordered list of possible solutions I'd helpfully provided only got an annoyed and frustrated non-response. So I pushed back and asked what answer she was looking for. This caused her to erupt and exclaim "I just needed you to say 'That's terrible, honey.'" and then she stormed off. This was a shocking revelation for me.

We discussed it more calmly later and, sure enough, sometimes she was relating the problems she'd confronted not because she wanted solutions but because she felt a need for understanding, empathy and connection. Ah! That's the day I learned to consider (or sometimes even ask) which kind of problem statement this is - and that lets me respond with either solution suggestions or a heartfelt "That's terrible, honey." This has made life better.

Although the whole idea of “figuring out the solution by explaining the problem” is absolutely real, I find that the problem for me with this is that the duck is (and always will be) an obvious stand in for something else; a gimmick of sorts. It just doesn’t work for me as a suspension of disbelief. I need to believe that my explanation is actually useful and necessary for the other person to help me. This happened to me a lot back in the days when stack overflow was the go-to place for programming help. I think the vast majority of my questions there I figured out by myself immediately after posting, but only because I actually believed that someone there (a) could actually help me and (b) for them to do it they needed me to be very clear in my explanation.

I argue that verbalizing to the duck without involving another person solves many problems just by itself. Deeper problems may require verbalizing it to a person. In my professional experience, I have lost vast amounts of time and attention to people who would break my flow state to explain the problem to me and figure it out themselves while verbalizing it for the very first time. So, I explained Rubber ducking to them and gave them all ducks. It worked wonderfully.

This story has such a different feeling about it since the rise of auto correct, lol. It's the first thing I thought of when I read the title. I was a bit disappointed it was utterly harmless. Though I'm surprised how far back the rubber ducking habit goes.

Also someone sent me that meme "Dear Autocorrect. It's never 'duck'." recently :) It was still fresh in the back of my mind. Also I'm a super "open" person when it comes to such matters and activities. So I have a very dirty mind :)

Sometimes posting my problem/question in Slack causes me to figure out the solution by myself not too long after.

It feels like God wants me to expose my ignorance/inability in public first and only then reward my "humility" with a solution directly in my brain.

In truth, rubber-ducking doesn’t even require anyone to listen. I find this practice of “step back and describe the system again” to be useful anytime an assumption changes, though I guess it isn’t limited to that. In my own work change of assumptions/requirements is pretty frequent, so I often find myself wanting to just step back and re-evaluate the system based on that new information. If you can take even a fragment of your problem space and go “end to end” on it logically, then you’ve in many cases given yourself a reference to work from, and now you can go off and make changes to align your work to that logic with confidence. And then you’ve also made yourself a decent test scope, so you can verify your logic and iterate on it.

If I get to the end of all that and still have questions then I’ll bring someone else in, usually just for a fresh perspective, though.

Sounds like a Tom Green bit.

Composing an email works. Start writing about the problem, and as you write, imagine the (adversarial?) comeback: Did you try A? B? C? Have you considered D or E? Do you know about F?

Numerous times IME, from this process of message composition has emerged a solution.

Dang, sometimes the world seems so small. I know one of the names mentioned in the article. And while this was before the duck was known, we did have conversations like that. Communication with another person can really help with figuring out the problem yourself.