[rauljara]

I've witnessed this phenomenon at work when asking other people for help with problems. My coworkers come up with more creative solutions than I did, much faster. The only problem is that when I'm asking for help with stuff, it tends to be tricky stuff with lots of edge cases. My coworkers' solutions tend to not actually work...

Which is not to say that there isn't value in asking them. Sometimes their solutions that don't work can be modified into something that does; or their crazy non-solutions can spark some inspiration on my end.

My theory as to what's going on here is that when you are responsible for the solution, you spend a lot of time thinking about what could go wrong, so your thinking gets constrained. When you are solving a problem for someone else, you're thinking is much freer, because frankly you don't give a damn. You are much more likely to come up with a unique, novel solution. You are also much more likely to deliver a solution that is actually disastrous.

My point being: I think there's room for both associated and disassociated thinking. This article seems to think because there was one series of studies showing some benefits of disassociated thinking that disassociated thinking is just straight up better.

[phkahler]

I've seen this as well. Other peoples problems offer an escape from my own. There isn't any pressure to solve them so there is definitely a different feel to them. There is also choice, if I hear about 5 other peoples problems, I may have insight into one or two but not the others and I can devote my spare cycles to the promising ones.

One approach for getting your own work done may be to think of your future self. That's who you're doing it for. This also gives less immediacy to the problem in addition to distance. "Older me is going to really appreciate this 3 months from now."

[MereInterest]

It also gives you the advantage of putting yourself in a different mindset. For that, I usually use "3 AM me" as the comparison. Any API that is usable by fully-conscious daytime me, but is prone to errors by "3 AM me" is one that needs to be improved. If an API can be used by "3 AM me", along with all the stress and pressure that led to late-night coding, then it is sufficient.

[Angostura]

Not only is there less pressure, but there is also the immediate pressure of gratitude from your peers, it's great to be able to help someone out and get a heartfelt thankyou. They are also often quite interesting and let you learn something about a new domain.

And suddenly I understand why I keep volunteering to help on gnarly little projects that are peripheral to my main job - even though I'm extraordinarily busy.

[saosebastiao]

> I've witnessed this phenomenon at work when asking other people for help with problems. My coworkers come up with more creative solutions than I did, much faster. The only problem is that when I'm asking for help with stuff, it tends to be tricky stuff with lots of edge cases. My coworkers' solutions tend to not actually work...

You can see this phenomenon in the HN comments on pretty much any article about Self Driving Cars. Everybody seems to have an extremely creative solution to some problem, as long as you're willing to ignore all of the inconvenient reality that researchers and corporations actually have to handle.

[buzzybee]

This is a really good point and it shows how good collaborations need a "lead with strength" attitude and why rubberducking works - when you think the problem is not actually that hard and you can clearly describe it, then you can safely delegate its solution. But the thorniest stuff has to stay under your supervision or it won't get done right - usually. But there are just as many "easy problems with simple solutions that you overthink", and then you need a rubberduck conversation to work out why it's easy.

[gregmac]

I regularly use this to my advantage. Though other people's solutions often don't consider all the edge cases or complexity, they are not without merit. I often find I can adapt a suggestion to make it work, or solve one part of the problem. In the best cases, someone else can identify something you were worried about as a not as big a deal as you thought, think of a totally different solution/workaround to it, or even identify it as a non-problem.

This is aside from the rubber duck effects[0] of just explaining your problem to someone else.

[0] https://blog.codinghorror.com/rubber-duck-problem-solving/

[atemerev]

For me its other way around: I know that I am a very sloppy person and can handle a lot of inconveniences, so I don't bother with fine details. If I write for other people, I assume that they are much neater and pickier, so I spend a lot of time polishing those corner cases.

[Retra]

Another problem of coming up with solutions for others is that it's easier to say "throw it out start from scratch" when you're not the one doing the implementation leg work.

[BurningFrog]

Something only becomes a Problem for me if I have failed to solve it. So, by definition, my problems are things I'm probably worse at solving than other people.

[klodolph]

That's a clever definition for "problem", but it's not how I would use the word in context. I would consider "problem" to include things which I have not yet attempted to solve, and I think most people would define it similarly.