Not necessarily. I recently earned 9-figure comp as an individual contributor by using my old-school skills for writing performance and correctness-critical software (and it's rather complex, too).
Thank you, I guess. I've been a practicing software engineer for over 40 years now, and watching the decline of my profession over the decades is quite painful.
The newfangled ways of teaching how to code managed to produce a generation of really poor-quality software "engineers" producing atrocious slow and buggy bloatware.
You cannot be a good engineer if you reason with analogies and metaphors instead of understanding how things actually work, at multiple levels, and knowing what and when can be abstracted and which lower-level details are important and should not be ignored.
So... if you want to become a decent software engineer, start with learning digital electronics and assembly. This way you won't need "metaphors" for arrays and such - because you will know that a static array is just multiplication by constant followed by addition to a constant and dereferencing of the resulting address.
Good thing I'm a tech diver certified for use of 100% oxygen as decompression "mix". Sitting at 10m for 90min every day for a month is too much, though...
The most important structural thing which happened in 70s was going off the gold standard. This resulted in financialization of economy and thus skyrocketing inequality (asset holders benefit from rampant inflation while labor loses). Inequality results in growing tensions between rich and poor (urban tech/financial elites and rural deplorables these days).
I have another take on it... Haskell is fundamentally misguided and not a real-world production language.
What engineers need is not something which makes stuff elegant, but what makes stuff simple. Having to work with advanced mathematical concepts to achieve rather simple functionality basically means that the pool of people able to use it effectively (and willing to spend efforts on learning how to do that... instead of, say, solving the actual real-world problems) is small.
Thus the niche appeal to the language astronauts - and thus their arrogance of people who mastered something with steep learning curve feeling superior to mere peons. Except it's the peons who deliver real products and get paid for that.
Anarchists (as opposed to thugs and hooligans who riot in the streets) are simply people who think that violence (or threats of violence) towards people who did nothing wrong to anyone is not morally permissible.
This immediately makes State impossible because it fundamentally relies on taxation. Taxes are, of course, are collected under the threat of violence.
Now, how to exactly organize society which doesn't rely on violence towards innocent people to operate is a matter of much debate. The most logically sound (in fact much sounder than any existing current State laws) legal theory for such society was advanced by Murray Newton Rothbard. His "The Ethics of Liberty" is absolute must read to anyone who wants to claim any familiarity with modern political thought.
Now, even villages in Khyber Pass can produce modern-ish full-auto weapons. Every machine shop in the West (including a large portion of hobbyist garage ones) is capable of making production-quality firearms.
Trying to prohibit tech from 100 years ago is an exercise in futility. Just don't tell that to Democrat politicians, they love to live in denial of reality.
You can't call the COVID masquerade "science", for a simple reason: it isn't. The science on the subject of masks is actually pretty much settled: they have exactly zero effect on transmission of airborne viral diseases. Dozens of studies, some are largish RCTs. No effect.
Must be a religion, then. Cult of State Almighty or something.
I don't think you understand the purpose of documentation.
It's not to say HOW things are done. Code and config files are all overly detailed and often quite convoluted HOWs.
It's to explain WHY and to help people on the team orient themselves in a maturing product. It's to record thinking which went into deciding this or that implementation. It's to help people with HOW-TO recipes. It's to show the big-picture view of the project.
Code and comments in code are pretty much useless for these purposes.
Basically, any engineering org which doesn't pay attention to documentation is deeply disfunctional.