When problem-solving I tend to jump about a bit, which is often efficient as it gets me thinking about the wider picture and seeing varied parts of it instead of getting locked into a particular detail. This sometimes leads me to missing something slightly obvious, that I keep missing as I rerun through things. Explaining to someone else forces me to organise the diagnostic process so far into a more solid narrative which invariable passes closer to, if not headlong into, the detail I've skipped past previously.

Sometimes just pretending I'm explaining to someone else helps the same way, but not always (and hardly ever if I'm a bit manic) because it is too easy to start skipping over bits again where actually talking to someone else (or writing things down) highlights when I'm doing that as the narrative ends up with a gap. Such a gap confuses a human, so they query the skip, or makes the grammar of a written explanation "rub wrong" either immediately or when I read it back.

> you don't know that you'll work out your problem in the process of explaining it

Of course this isn't 100%, it doesn't help if there isn't a clue to the solution in the gap that gets filled, but it works surprisingly often and usually the gap is because I've simply made an unsafe assumption (such as that a particular detail is not really relevant) and things become massively more obvious when that simple error is undone.

> you don't know that you'll work out your problem in the process of explaining it

But if you feel you've exhausted other current avenues, it is worth giving it a shot. It is highly unlikely to make the situation any less fixed, unless your rubber duck highlights a larger problem that the problem you think you are debugging is merely a symptom of…

I think a similar process is in play when I do the “going for some air” thing, come back, and very quickly see the new vital clue. Having taken the break, the process of getting my head back into the problem space becomes one of quickly re-explaining it to myself. This gives the feeling that the back of my mind, my autopilot, has come up with the answer while I wasn't looking.

By this reasoning you must not believe in any debugging techniques (what does it mean to "believe" in a debugging technique anyways?). You don't know that they'll lead you to a solution to your problem. The differential coverage technique posted yesterday? It doesn't work all of the time, or may give you too much to look at to be practical. The statistical variant I posted in that discussion also doesn't always work, it can lead you astray. TDD? Even Kent Beck says to not use it all the time.

These things, and rubber duck debugging, do work. That they don't work all the time is immaterial. Are they effective for you and your team? You rotate through techniques while debugging and you select them based on experience. A first pass with that differential coverage technique or a git bisect may be enough. If they don't help right away you go to other techniques. Repeat. Probably even cycling back once you've isolated the issue better.

https://research.swtch.com/diffcover

https://news.ycombinator.com/item?id=43795090

It's also why various sources recommend writing so much: writing results in learning, or perhaps writing is learning.

For me, the solution doesn't often arrive while I'm explaining the problem but I've had a strong correlation with solutions arriving shortly afterward. As others have said, for at least for some cognitive types (which include me), the process of verbalizing a complex problem activates alternate mental pathways. Explaining it requires curating the domain into what's relevant/not relevant to include, adequately defining terms, surfacing implied assumptions and transforming the mental structure into a linear sequence of explanatory statements.

I think the other person actually being there, as opposed to talking to the duck, is an essential element. And I suspect the results tend to improve in proportion to how capable and experienced in the relevant domain the duck holder is - despite not even speaking. The reason is that when I'm thoroughly explaining something complex to someone I know well, that communication requires me to model their prior understanding of the domain, terminology and even the ways they're most likely to engage with the problem. Sure, explaining something to a random stranger who doesn't know the domain can be partially helpful but it's also inefficient because a lot of my mental focus will be spent on explaining enough of the basics to orient a domain novice. Explaining it to someone who not only knows the domain but who I know is smart in exactly the ways likely to lead to solutions, unconsciously forces me to model my knowledge of how they tend to solve problems like these. It's kind of like a turbo version of that old adage "Ask yourself how {experienced domain expert} would solve this".

I know I'm guilty of the same thing and I'm positive many others here have had very similar experiences.

IN GENERAL, it seems when guys talk to someone else, they are likely looking for input into a situation. If we didn't want input, we would just sit and ruminate in our own personal thoughts processes.

Your story is also a great lesson in why communication is key - unfortunately it takes both parties to realize this!