What its related to is the narrative you shared in your second paragraph, which I think you were writing mostly for color, perhaps seeming to you as the only or necessary story of how software gets made.

"And then", "And then", "And then"... "One feature at a time, you just keep stacking more and more on."

There's no foresight. There's no planning. There's no architecture. There's no readiness. There's no preparation. Tomorrow's needs are always beyond the horizon and today's are to be approached strictly on their own terms.

If you've taught software development to anyone, you're used to seeing this behavior. Your student doesn't know what they don't know (because you haven't taught them yet), and they're overwhelmed by it, so they just scramble together whatever they can to make it past the next most immediate hurdle.

Much (not all) of the industry has basically enshrined that as the way for whole teams and organizations to work now, valorizing it as an expression of agility, nimbleness, and efficiency, and humility.

But it inevitably results in code and modules and programs and services and systems where nothing fully snaps together and operational efficiency is lost at every interface, and implementations for new features/challenges need to get awkwardly jammed in as new code rather than elegantly fleshed out as prefigured opportunities.

So you're right that most modern projects eventually just become swamped by these inefficiencies, with no ripe ways to resolve them. But it's not because of Rails vs Go or something, it's because pretty much everyone now aspires to build cathedrals without committing to any plans for them ahead of time.

What they gain for that is some comfort against FOMO, because they'll never face yesterday's plan conflicting with tomorrow's opportunity (since there is no plan). But they lose a lot too, as you call out very well here.

"What would you use if you cannot use Terraform for a project?"

To which I initially answered, since it was a SENIOR position, with a warning about mixing Terraform and non-Terraform managed infra because it can lead to unforeseen issues, especially if there are less visible dependencies between the 2. I then mentioned anyway it could be done with Python + boto3, with AWS CLI + bash, with Pulumi, with CDK and then after some extra talk, also with Ansible.

They didn't want a long answer with lessons learned in real prod, they wanted a oneliner answer: Ansible. They told me then to be shorter in next answers and proceeded to ask like 30 questions in a row involving bash, Linux, Terraform and Kubernetes knowledge, to which I answered all correctly (and with the one-liner answer).

The result: discarded, because I chaotically answered to that first question. Although I was somehow offended because I don't like to be discarded, I think I dodged a bullet in this case.

"A simple poka-yoke example is demonstrated when a driver of the car equipped with a manual gearbox must press on the clutch pedal (a process step, therefore a poka-yoke) prior to starting an automobile."

You would typically put the car to a neutral gear before starting up the car, clutch isn't required.

Furthermore, if there was such a poka-yoke preventing start-up when the clutch isn't pressed, it would prevent the common safety procedure when a car doesn't start and is in a dangerous position, for example on rails or in the motorway. In such situations you would drive the car with the starter engine alone, putting the first gear on, release the clutch, and start the car, thus moving it forward slowly by the battery and the starter engine.

Closely tracking things you can not control may provide a sense of control to some.

Or the other way round: Crunching enough data and building reasonable predictions based on that takes away the element of surprise, and the element of surprise for some translates to anxiety.

For me the only things that scare me are in the "I have no data on that" category.

Also: Different people, different coping strategies. I don't want to wait until the "Active Shooter!" cell broadcast message finds its way to my phone. :)

For some people, potentially especially those on the spectrum, having as much information as possible to work with might bring mental security and stability.

People are different, brains are diverse.

Because yeah, the database is you main source of invariants. But there is no good reason for you application environment not to query the invariants from there and test or prove your code around them.

We do DRY very badly, and the most vocal proponents are the worst... But I don't think this is a good example of the principle failing.