> These people do stupid CRUD API micro-service bullshit because they're blissfully ignorant of how tremendously amazing their software could be if they fired 90% of their boot-camp dev ops and replaced them with a handful of 10x staff-level developers

I wish this was true, I really do. But a few staff developers cannot physically handle the volume of work required to replace that many developers.

Staff developers are good at solving complex problems that many other developers combined could not solve. They are not good at writing 10x more LOC than other developers.

Obviously, it depends on the work (why would we try to have a discussion like this without setting parameters?). But in general, I think the places that need 10x the code are outnumbered by the ones that would be better with 1/10th the code they have, written by fewer people. It doesn't happen, but that's better explained by organizational reasons.

I think it's the complete opposite. There are very few businesses that can exist without having to solve an enormous amount of edge cases. Most of the time that's the whole reason the business is valuable!

Also, this shouldn't be framed as 10x more code but 10x faster velocity. That is what I meant by "[staff developers] are not good at writing 10x more LOC than other developers". Staff devs cannot move 10x faster than average devs on every problem.

Most work is undifferentiated. Staff developers don't add much value over another dev for basic work (Code quality has high diminishing returns) and they might only be 2-3x as fast, if that.

It's possible that many businesses could be sustained as they currently are today with 1/10th of the code and/or 1/10th of the people, but in a growing company that's impossible.

Well, yes, I mean, how can we really have this conversation and throw numbers around without defining even what countries and industries we are talking about?

But, maybe it's true that most code covers edge cases; then in my opinion, staff developers should be building tools for the rest of the company to use, and if they are powerful enough, you might be better off by having fewer people employed as programmers and more people writing programs. Obviously a lot has to go right for this sort of thing to happen.

Like I said, I think most companies don't fit your model so feel free to throw out some industries.

I think service/API companies like Netflix are the most suited to your approach, but even with Netflix leaning into that style of company hard they still have thousands of engineers. There is most definitely some amount of irreducible work for a problem/domain/other.

> Obviously a lot has to go right for this sort of thing to happen

It feels like a very naive approach. When I'm building stuff, the edge cases often require a lot of digging into the surrounding context and working with other teams.

I don't think you can solve this by abstracting it away, because it's still working at the same level of abstraction just in a different part of the codebase.

There is also the fact that every abstraction is leaky...

We should be building tools that empower people to solve their own problems, whether that's no-code or low-code tools, or platforms, or scripting languages. We underinvest in internal tool-building for all sorts of non-technical reasons, and the result is people interacting all day at work with terrible software.

> But a few staff developers cannot physically handle the volume of work required to replace that many developers.

You're assuming "volume of work" is a constant. I'm saying: 90% of "volume of work" is something that a handful of good developers would make the compiler do instead of humans. It's actually more than 90% over time, because there's a fundamental difference in the "capability growth curve" -- this curve is super-linear with good developers and sub-linear with poor developers, so the ratio between them grows greater over time.

> They are not good at writing 10x more LOC than other developers.

Right, it's quite the opposite: they will write 10x less code than the other developers.

> I'm saying: 90% of "volume of work" is something that a handful of good developers would make the compiler do instead of humans

I don't understand what you're saying here. I cannot hand off feature work, rollout planning, context gathering and investigation, etc to the compiler.

> Right, it's quite the opposite: they will write 10x less code than the other developers

At a growing company, that is not helpful... You will not be able to move fast enough.

> It's actually more than 90% over time, because there's a fundamental difference in the "capability growth curve" -- this curve is super-linear with good developers and sub-linear with poor developers, so the ratio between them grows greater over time

This is only true when you are working on complex problems. If I have a lot of tasks like "change the colour of this button" having a few staff developers vs a lot of average developers is far worse.

At almost every single company, there are far more mundane and relatively simple problems than complex problems. Most companies would not get more value from having way less super senior devs. There are just not enough complex problems for them to solve.

Disagree. While I always felt that I want to achieve more than these regular old CRUD apps, no “10xer” would implement them faster/better - because “these systems are building the rails in front of the train”, and it is not even an engineering problem most of the time. I have worked at banks and the amount of back-and-forth between what the bank wants and what the devs need to know is insane, not well specified, always changing, etc..

Hell, it is often the case that requirements change up the whole program logic based on which country it is being used from. It has a much different complexity than a JIT compiler, but it is a super-human, not-really-compressible complexity nonetheless.

> While I always felt that I want to achieve more than these regular old CRUD apps, no “10xer” would implement them faster/better

A "regular old CRUD app" doesn't exist. Poor development teams end up translating all requirements into "regular old CRUD apps" because that's easier. Humans are excellent at replacing hard problems with easy ones, regardless of whether solving the easy one is anywhere near as useful.

And yes, they absolutely would implement them faster. Most "regular old CRUD apps" are rife with SELECT N+1 and other simple and crippling performance issues.

> “these systems are building the rails in front of the train”, and it is not even an engineering problem most of the time.

You're assuming we're stuck with trains and rails. In the physical world, we are: if I invent a different kind of train that doesn't need rails, or a completely different way to transport freight, then I've solved about 1% of the problem -- we still need to build out all the infrastructure around it, change all our systems to use it, etc.

If I invent a different kind of process for handling data flow in an application, I've solved somewhere between 40% and 100% of the problem, depending on how 'private' it is, etc. "Building" the thing takes the compiler a few seconds. We might still need to adjust downstream dependencies, but if they're also written well, that should be extremely easy.

> it is a super-human, not-really-compressible complexity

While this definitely exists, my claim is that the intrinsic, Kolmogorov complexity of the problems most existing software solves is somewhere between 10% and 1% of the actual complexity of that software.

Sometimes upstream processes will need to change (usually becoming much simpler). This is usually the sticking point. if the upstream process is the U.S. Code of Federal Regulations, then this isn't likely (without lots of lobbying money to simplify it, which the FAANGs of the world should actually consider a tool in their toolbox, but most of us can't), and we can call the "intrinsic complexity" high.

But more often than not, that complexity is actually coming from the whims of some previous moron vice president who now works somewhere else, and they're conflicting with the whims of the current moron vice president. My whole point here is that the staff-level developers need the authority to tell those people to shove off and implement it in a way that actually makes sense. Yes, I'm aware that will never happen because of the deep toxic dysfunction endemic in modern corporations -- this is my point.

I wrote somewhere about there being two kinds of complexities (not the very important essential/accidental, but a different categorization).

I called them vertical and horizontal, not sure if they have some better name, but the vertical one would correspond to “hard” problems, like some complex lock-free parallel algorithm that had to be made in exactly that way to not have race conditions. Or some of mathematics.

The other dimension would be the essential part of business logic, where the business logic has grown in a haphazard, organic way - but since other services depend on it, it has to work as is, from bug to bug almost. This is more like a biological system — cells have plenty of redundant, vaguely similar pathways handling the same thing, it is chaotic, but if you were to simulate the whole thing, you couldn’t go around it, you would have to implement the whole complexity. For a more human example, history might be such subject. These things are complex in the same way compressing a random noise file is.

A software can have both kinds os complexity, they are different axes — and I argue that CRUD apps are usually of the second kind, most of the former kind of complexity are handled by external services/libraries (e.g. they might enter two addresses to a third party system to get two coordinates, and put it to another service to plan a trip between the two — the app only handles the communication). But these can get arbitrarily complex, and the specification is the program itself. That’s why we continue to run Fortran/Cobol software at certain banking firms.