Some people thrive by “catching fish in muddy waters”. The real motives of people very often differ from declared ones, but at a workplace it’s usually either getting promotion/pay rise or stealing from company in some way (kickbacks, bribes, benefits for their side business, etc).

Yeah, the best thing those people have going for them is that they get old and die and turn to dust so they don't have to live with the effect that they have on other people. It's one reason why the ancients invented the idea of the afterlife, to put some fear into those people.

Conversely, some in the engineering mindset have a pathological need to nail down ambiguous things to a definition because it fits their style of reasoning. Nobody thinks it's easier to work with poorly-defined things-- even with a well-defined overall goal, when the specific goals and risks in achieving it are a bit ambiguous, you're pretty likely to get it wrong if you try to stuff the problem into a neat little box, and in some cases-- e.g. teams with tight budgets-- getting it wrong is a huge problem. That sort of flexibility is what many developers lack when they get "promoted" to a managerial position because they're skilled developers rather than competent managers.

Any real revolution in living conditions (like being able to support 8 billion people on chemical fertilizers) always involved finding order in situations. Everything else is about as effective as pushing the deck chairs around on the Titanic.

Order vs disorder is a false dichotomy. The vast majority of situations fall somewhere in between "math problem with a proof" and "random assortment of unrelated events." The processes required to make progress at one end of that spectrum are different than at the other end, though most problems worth solving have components at different places on that spectrum. Engineers making micro perfection in well organized pockets is only valuable if people working in the far more ambiguous surrounding areas can apply it to the larger context.

People like thinking what they do is the most difficult and important part of any process, but most non-technical people can pretty easily look at technical work and see that they don't have the knowledge to do it-- the complexity and success/failure is very visible. Since other disciplines' obstacles and processes aren't so easily labelled and quantified, many engineers perennially fail to realize that their perceiving less difficulty and complexity in many other fields is because they lack the perception or experience to identify it.

This is a very well articulated and nuanced comment. In the most pathological engineering organizations, that lack of perception can fester into active resentment of other disciplines.

It's just that the real world is fractal. With apologies to Jonathan Swift, the exceptions have smaller exceptions that upon them prey, and they have smaller yet to bite 'em.

It's a subject (reasoning with defaults) that I've thought about a lot because it's a core part of commonsense reasoning. Back when production rules were a thing people never standardized a way of dealing w/ defaults and one of very few default-oriented programming languages is

https://ganelson.github.io/inform-website/

default-oriented programming might well resolve some of the conflicts involving object-orientation and its discontents. (e.g. defaults could be a better model for "inheritance" that works in more complex relationship graphs.)