I've recently mused about very similar topic. I recovered the old forgotten dilemma about "systems programming" and "applied programming".

In short, systems programmers create systems for other programmers. I include not only operating systems here, but also frameworks and libraries.

And then there are applied programmers and even advanced users who do the rest.

My claim is that every programmer should learn to be systems programmer to be good. "Systems" have additional qualities, like extra optimizations, ergonomics, meccano-like approach to solution domain, etc. Systems programmers are accustomed to deal with software... systematically. So even throw-away scripts written by them will be less chaotic.

I wonder what is percentage of system programmers among those 30M you mention? How many really think of what they write as a system, having levels of abstractions, with parts playing well together?

This is where 10x-ness comes. A habit to do things uniformly (principle of least surprise) pays off, because if we have M components, each with their own ways, in the worst case we might need to deal with M² connections individually. What a waste compared with thinking about M+1 abstraction (M components and a system, which glues them together). In everything. One may say M=1 "for starters". But it's rarely the case. In practice, number of boolean flags grow, where there is one parameter two can come, where we thought will always be one language more will come, etc.

Systems programmers see the seeds of a greater supersystem even in M=1, and learn to deal it in such a way, that even initial implementation does not require too much overhead.

Bonus is this video "The Mess We're In" by Joe Armstrong I've seen a couple of days ago. It explains a lot. Enjoy!

https://youtu.be/lKXe3HUG2l4?si=5iw6EjCbIlhUfUYh

(now we have that "compressor" Joe mentions, but software engineers seems to use it in reverse)