I do this sometimes. In many cases, I feel like "yes, and" would be an endorsement of the original idea. If I say "yes, and" and then there are delays or problems in implementation because of things that would have been obvious to "no, but", the question becomes "why wasn't this brought up earlier on before people sunk so much time in." In the reverse case, saying "no, but" in a case where the problem is easily surmountable just makes the questioner look like a good planner. So in that sense the reason devs tend to "no, but" is matter of them responding to incentives; it's not that they can't think divergently, it's that they're putting themselves at risk for little reward for doing so.

> So how about we treat thinking as a two-phase problem and give divergent thinking some room?

Yes, I think separating these two phases (and thus separating "throwing an idea out there" from "endorsing an idea as definitely workable with no foreseeable complications") would be very helpful.

Being primarily an engineer myself, I can't help to say 'yes, but' you might want to rephrase this into 'untrained engineers' or 'some engineers' or 'uncreative engineers' or similar. Don't get me wrong, I know the people you talk about and I simply cannot deny I used to be like this myself sometimes but over the years this changed into something bimodal. I.e. when needed I will always fall back to 'how can this fail' mode - just because it's often required to properly fix/create things which won't brake, but I find myself defaulting to generating tons of ideas. But I'm also creative b nature so that helps. In fact most other engineers (by education or not, doesn't matter) I know also clearly use a mix of both modes. There's only a couple which don't (and even some which default to only creating a mess, not seeing any problem, but that's something else and I'm not sure if it's an engineer:).

yes, and "resting on the backs of four huge elephants which are in turn standing on the back of an enormous turtle"

I'm engineer :)

To use your "I'm a unicorn fireman" example, sure that conversation can be fun.. and what does the winner get? With that example you're not building a system to be used by humans in the real world, you're doing stream-of-consciousness thought experiments, more art than engineering. There are no solid constraints.

Sure there's some debatable evidence that creativity can be "practiced" and generally applied, but when you're trying to build a better airplane putting a giant swimming pool in the nosecone is probably not a good idea for a whole host of reasons and it's best that you account for those before building the thing.

Software and the other arts largely benefit from cheap iteration cycles and relatively low-impact mistakes. And even in those cases if you "yes and" too much and try to account for the mistakes later you can find yourself with a horrible, underthought design and swamped trying to fix all the problems at once. Then all those negative constraints you ignored in the name of "divergent thinking" suddenly make themselves known. Many a failed startup led by a Steve Jobs wannabe is a perfect example of this.

I think the main point is that there may be advantages to explicitly giving room to both divergent and convergent thinking to exist in separate phases (this could be done in one cycle -- there's nothing that says any of the cute unworkable ideas would ever leave the meeting room or shopfloor or prototype. Reality/logic/laws of nature are the final arbiters).

Constraints/refinements/criticisms will emerge in the second phase, but we often don't give room to the first because we tend to want to edit too soon, and if we're honest, our impulse criticisms going to be based on our past experience and emotion rather than a cool, deliberate, rational analysis process or empirical reality.

A disciplined balance is what is sought. In creative processes, withholding judgment during ideation is a basic principle -- but many engineering types are too quick to ignore it, wanting to filter almost immediately. This is ok if the space is well-understood and what you're doing is cookie cutter (which to be honest, is all most engineers do), but definitely a blocker if you really want to challenge ideas and do something truly new. It snuffs out ideas pre-maturely and doesn't allow them to potentially grow into something that would work.

An example of this: I was against neural networks for years because they lacked explainability ("black boxes" was my criticism of them), and whenever someone brought them up I would enumerate my usual list of criticisms of why they would never work -- all rational and mathematically watertight. It became so habitual that a few good ideas (where neural networks actually would have worked if we had tried them, albeit it had to be in creative ways) passed us by. I snuffed that idea out before it had a chance to emerge in a form that I would have recognized as something workable.

An example I experienced a couple of weeks ago: Someone let code that "just works" slide through a code review back in 2017. That code had a hard-coded value that would have been easy to determine dynamically (he just set a max at an arbitrary value instead of counting how many of a resource there were) but wasn't due to general lack of discipline. Now it's a minor issue, and the code did indeed work up until a couple of weeks ago. Then the number of the resource in question changed, and all of a sudden that hard-coded max was no longer accurate.

The error manifested as a segfault in our C++ but only sporadically and was hard to reproduce when we didn't know what the issue was. Doesn't help that it was in a mountain of legacy spaghetti code. It took me and two other people two days to track down the original cause, which if you add up our de-facto hourly rates cost the company thousands of dollars. All because of one little minor piece of sloppy code.

Now imagine the effects of bigger, grander sloppiness at the design level. And then those effects get compounded because they're conveniently ignored and integrated into still further mistakes, and you get an exponentially multiplying mess.

I'm willing to bet many professional engineers have had an experience similar to that, and if they care about their craft at all it was likely extremely frustrating and painful to deal with. So it's not that they're "bad at divergent thinking" so much as they've been trained by experience to believe that the benefits of divergent thinking aren't worth the potential downsides. Whether that's an unconscious bias that should be worked against is an interesting question.

But that superpower, which is so instrumental for execution, seems to me to be simultaneously deleterious to creative enterprises. It is at best an incomplete superpower.

I would also say that the reverse is true. Artsy creative types who are gifted at divergent thinking, but not convergent, are typically weak at execution so their products never gain traction or do not actually work.

Creative endeavors are by nature "sloppy". Hence the need to withhold judgment and let an idea play out via a divergent phase, and then bring it back through the convergent phase.

It would seem to me that both rationals and creatives have blind spots, hence the usefulness of a 2-phase process.