Being self taught also selects for the ability to learn autonomously. Which is very important in software.

someone was bribed != people are motivated by financial gain

That is a self-contradictory statement. If people were not motivated by financial gain, then bribery would not exist. You could say people might be motivated by power and influence, but even those things boil down to one singular thing, and that is accumulating wealth.

"This system has severe limitations. But we should rely more on it because this other system is also limited."

For several decades we've developed and use computers because they can be very precise and deterministic.

Cost of revenue should include R&D and amortization. Pointing to EBTIDA is a very old trick.

Yup. Code is liability. Understanding it is the corresponding asset. Generating more code that is less well understood is akin to increasing leverage.

Or: buying a super car might make your commute feel faster. But if everyone did it, we'd have a lot more congestion and a lot more pollution.

I like to read books on computers from the 70s and 80s. No trite analogies, just hard facts and diagrams. And explanations that start from scratch, requiring no previous knowledge - because there was none.

The thing about these layers of abstraction is that they add load and thus increase the demand for people and teams and organizations that command these lower levels. The idea that, on a systemic level, higher abstraction levels can diminish the importance, size, complexity or expertise needed overall or even keep it at current levels is entirely misguided.

As we add load on top, the base has to become stronger and becomes more important, not less.

This is a good point. However, the base is relatively narrow; there are many, many more people working in the popular frameworks and languages like e.g. React or Java or what have you than there are people who work on the fundamentals and have that low level understanding. And I'm afraid people at that level are going to become rare.

It's not hopeless though, it feels like that in the past decade, some of the smartest minds working at the lower levels of abstractions have come up with great new technologies. New programming languages that push the envelope of performance and security while maintaining good developer experience, great advancements in microchip technologies, that kinda thing.

It's important to maintain access to universities and higher education, where people who have the interest and mindset can learn and become part of this base that powers the greater software market.

I don't know. People working in web frameworks might be more visible, and more numerous than people working more low level stuff. But I don't think the latter is rarefied atmosphere at all. There are today several times more people working on those base levels than 10 or 20 years ago and I expect the trend to continue.

Sure, they will enable even more people proportionally to not think about those low level systems. But my argument is that the need for that low level expertise has always expanded and will keep expanding.

Automation entails tonnes of complexity that need to be managed. It doesn't just evaporate. More automatic systems will demand more people and teams to learn low level systems in great detail and at high levels of accuracy.

Nothing has served me better over the past few decades than accumulating ever more detailed and accurate knowledge of what it is exactly that computers do under the hood.

All the layers of abstraction are well intended and often useful. But they by no means eliminate the need to understand in detail the hard facts underlying computer engineering if you want to build performant and reliable software.

You can trade that off at different rates for different circumstances but the notion that you can do away entirely with the need to know these details has never been true.

More people being enabled to think less about these details necessitates more expertise to exist to support them, never less.

> All the layers of abstraction are well intended and often useful. But they by no means eliminate the need to understand in detail the hard facts underlying computer engineering if you want to build performant and reliable software.

Agreed. A good abstraction usually doesn't obviate the need for understanding what's going on behind the scenes, it just means that I don't have to think about it all the time.

As a more extreme example, I don't usually think about the fact that the Java (or Kotlin, Scala, ...) compiler generates bytecode that runs in an interpreter that translates the bytecode to machine code on the fly. But sometimes it's useful to remember (e.g. when dealing with instrumentation).

Another example are things like databases, or concurrency constructs, etc. There it's usually good to know the properties they guarantee and one way to be able to reason through these is by having some understanding of how they're implemented under the hood.

What you are talking about here is accidental vs essential complexity as described by Brooks in the 80s.

Your claim that LLMs do away entirely with accidental complexity and manage essential complexity for you is not supported by reality. Adding these tools to workflows adds a tonne of accidental complexity, and they still cannot shield you from all the essential complexity because they are often wrong.

There have been endless noise made over semantics but the plain fact is that LLMs render output that is incongruent with reality very often. And now we are trying to remedy it with what amounts to expert systems.

There is no silver bullet. You have to painstakingly get rid of accidental complexity and tackle essential complexity in order to build complex and useful systems.

I don't understand what's so abhorrent about it that people invent layers and layers of accidental complexity trying to avoid facing simple facts. We need to understand computers and domains with high accuracy to build any useful software and that's how it's always been and how it's always gonna be.

There is no silver bullet.