Malleable software is hard not just for technology reasons; probably the most difficult part of designing software is thinking through and cleanly handling the implications of every decision. It's easy to imagine that one could 'just make it work like this instead of that' without understanding the implications of the change or the reasons why the system is like that in the first place. Making software has never been easier than it is today, but it's still hard because designing coherent systems that work correctly in all scenarios of usage is hard.

Yes, configurability is good and scripting is a great way to safely add functionality to a system but there will always be a distinction between people who use software and just want it to work perhaps with minor tweaking, and those who build systems. It makes no more sense to throw everyone in the same bucket than saying that being able to change the oil in a car makes everyone a mechnical engineer.

Also:

> Many, many technologists have taken one look at an existing workflow of spreadsheets, reacted with performative disgust, and proposed the trifecta of microservices, Kubernetes and something called a "service mesh".

Yes, over-engineering is a thing, but piles of interlinked spreadsheets are usually thrown out precisely because the people who created them didn't have the skills necessary to build a system, and these ad-hoc systems eventually outgrow their usefulness and become unwieldy horror shows. Maybe Beryl in accounts knows the eighteen cells across three files that need to be updated when the interest rate changes, but if she leaves then we're all screwed.