[typicalbender]

It's amazing how much a technique like rubber ducking[1] helps to work through issues. The number of times I've felt like I have no idea how to solve a problem until the moment after I ask someone else is incredible. I think the act of thinking how to explain the problem to someone else really helps trigger the problem solving side of the brain. That and the number of times taking a 10 minute walk has been more productive than hours of debugging time is frankly mind boggling.

[1]: https://en.wikipedia.org/wiki/Rubber_duck_debugging

[agustamir]

I was stuck debugging a chip for a day until I finally decided to write to the FAE. I sit down, write my problem in the simplest possible language, list all the tricks I tried and asked for a solution. Then I'm reading my email to make sure everything is in order and voila - one last thing to try. and that step worked.

[TheSpiceIsLife]

What does FAE mean in this context?

Or do you mean ‘fae’ as in fairies?

Edit: speeling

[agustamir]

field application engineer (usually a customer facing engineer from semiconductor companies)

[TheSpiceIsLife]

Ah right, I see, thanks.

[kiba]

They call it the Einstellung effect[1]. It's a recommended strategy to take time away from the problem to let your brain subconsciously work on the problem.

[1]: https://en.wikipedia.org/wiki/Einstellung_effect

[lowdose]

How is this different from the Innovators Dilemma?

[sokoloff]

The hours of debugging were still a critical part of the process. It “loosened the jar lid” so to speak. (It’s not like long-distance walkers are some of the best debuggers.)

But once you’ve put in some substantial effort, taking a break and a walk (or a sleep) is often the critical last step.

[daemoncoder]

I've heard this concept called the cardboard colleague - you explain the problem to a cardboard cutout representing a colleague instead of an actual person. Of course it remains a concept, I don't think anyone would go so far as make one :-)

[kwhitefoot]

You can use an actual colleague.

Many years ago when I was designing and programming embedded controllers (early '80s) I worked alongside, but not with, another engineer who was building devices using the same fundamental components (6520, PIA, etc.) In our tea breaks we would explain our problems to each other. Neither of us suggested any solutions to the other or responded with anything other than simple platitudes and sympathy for each other's troubles. It was remarkable how many problems had simply vanished by the end of the tea break.

[dorfsmay]

aka https://en.wikipedia.org/wiki/Rubber_duck_debugging

[tripu]

Rubber duck debugging is extremely useful to unblock. I very rarely use an inanimate object, though — for me, the real help is the first or second (apparently very basic) question that the other person poses to me. That key question usually comes at what would seem the beginning of my explanation, but there lies the magic.

Rubber ducks don't ask questions.

[andrepd]

>That and the number of times taking a 10 minute walk has been more productive than hours of debugging time is frankly mind boggling.

I can't keep track how many times I has an idea that got me unstuck while peeing in the bathroom.