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.