I dislike that passive-aggressive dynamic of converting the second type of thinking/feedback to the first. And that dynamic generally has a name: "politics". I've been on teams where I had to use rhetoric to convince a (non-technical) manager that following standard design practices like low coupling/high cohesion, etc. results in more robust software.

What's sad about that whole political dynamic is that it wears people down to the point they just don't care anymore. They're tired of people (often management) who can't make a decision due to political pressures ("I don't want to be the manager who has any project 'fail.'"). This often leads to decision makers succumbing to the sunk cost fallacy. But as long as there are status reports and it looks like work is getting done, then the process continues.

I don't really like politics, but 10,000 years ago people in mud brick huts where taking politics and today people in mud brick huts are still talking politics. If nothing else politics works and ignoring things that work just make your life harder. Also of note, mud brick huts have been around for a really long time.

I understand completely. You have to find the place whose politics interest you as much as the work. That's very difficult (pretty much impossible) to gauge during an interview. You really need someone on the inside to give a complete view.

The other problem with that is it makes it hard to put in place a systematic improvement process. A formal failure analysis process is a wonderful thing that can rapidly drive improvement, but to have such a thing you must first be able to say "that was a failure, let's analyse it". In a highly PC environment where nobody ever fails at anything, everything is always wonderful and the only possible change is to become even greater, it's hard to be fully honest with yourselves.

Here's an example from my own career: I once worked at software firm which routinely sent customer feedback to a black hole. Literally, there were forums where customers could talk to each other, and feedback forms on the website, yet either nobody read them at all or there was someone in customer support who theoretically read them but actually didn't.

I discovered that when I tried to use one of the company's own web forms to report a technical issue with one of their products. When nothing happened, I started asking around. The email thread I started (which was plenty polite: just asking who owned this form and whether my feedback was being processed) quickly got like 20 people CCd onto it as everyone tried to pass the buck and eventually it became clear that whilst it had perhaps once been connected to something, the form had at some point stopped being monitored and nobody had noticed, in fact, the feedbacks weren't even being stored anywhere. We were literally throwing customer feedback in the bin.

Eventually, after asking the question of who was actually responsible for this process and who was going to fix it maybe four or five times (lots of people appeared to be involved in nebulous ways and nobody was willing to take responsibility), I pointed out that this seemed like a fairly serious failure and perhaps there should be a post-mortem of some kind, which was a routine occurrence in other parts of the firm.

This suggestion went down like a lead balloon, as you may imagine. I don't recall if the issue was ever fixed: at some point I ran out of energy and stopped caring. This is how engineers get a reputation as being awkward and difficult: they exist in a world where things work or they don't, and there's no shame in writing a bug because we all do it, but when your software is buggy you're expected to admit that and fix it. Lots of people in fluffier job descriptions don't exist in such a world and interpret any hint that they might have actually ... failed ... as hostile and threatening.