Agreed, this post gets a lot of things right IMO.

An idea I've had on 10x developers (or whatever the multiplier..) is not that they can code and solve problems this much faster, but in the long term they steer the code base as a whole in a direction such that the impact is that large. (But of course recognizing this, or being able to compare it to the other would-be ways the code could have gone, is a non-trivial matter :).

> An idea I've had on 10x developers... in the long term they steer the code base...

Agreed. And on the flip side, you can have -10x developers that make all the wrong choices, like inventing and entrenching their own language or crappy framework for reasons of boredom or ego.

I suspect that junior developers are less likely to be net-negative to that degree. Perhaps it's one unarticulated reason employers tend to prefer inexperienced engineers. If the employer can't tell the difference between a 10X and a -10X developer (the guy pitching the UML-based python code generator or the guy who really likes cucumber?), it's typically easier to hire smart people who are still learning and trust your existing technical leaders can get value out of them.

And sometimes they invent a framework that hits all the right design points, but junior engineers can't read a book about them or take a class about them, so don't understand and badmouth them as crappy and a result of boredom or ego.

Its hard to invent something, and have it get no traction because nobody else wants to move forward.

I've been at two startups that had frameworks that solved all the problems in the product space, efficiently and nearly perfectly. And failed because as the company grew, new Engineers all clamored for something simpler or something they already knew. They outnumbered the designer with their voices and management steered the company off the rails. It's tragic.

This is an incentive alignment problem. Developers want to maximize their human capital since they usually don't have significant capital in the business itself. With experience in all the latest buzzword technologies, they can get good offers elsewhere, or use the leverage to increase their pay. Whereas sinking all their effort into an in-house framework is fantastic for the business in multiple dimensions: it's a custom fit so it's more productive, but it also locks in the employees, reducing their employability elsewhere and BATNA.

I do wonder if incentives can be aligned for things like this, or if it's just a structural problem we need to live with.

> Whereas sinking all their effort into an in-house framework is fantastic for the business in multiple dimensions

Well, it's fantastic until it isn't anyway. Companies do fail, at least fail to own new markets, by being tied down into legacy architectures.

I think that's orthogonal. You can fall behind just as easily by not addressing technical debt. Consider how easily it is, particularly in the JS world, to accrue multiple different bits of UI written in different frameworks du jour.

Rewriting stuff is very seldom in the business' interest, but stuff gets out of date at a rate controlled by the ecosystem, not the company.

That's a lot to unpack.

Generally speaking, the worst kind of legacy code is the kind that cannot be easily rewritten. That's why I particularly called out custom frameworks and custom languages. Replacing custom service implementations, in comparison, doesn't even count as "replacing stuff" since it's so trivial.

It's not in the company's best interest, generally, to write business-critical things in ways that are hard to replace and/or pivot on. This means that a company needs to account for the whims of "the ecosystem" in both its business plan and in its technical strategy. If it's a huge concern, the profit margins need to stay high enough and customer expectations need to stay flexible enough to mitigate the concern. Also, if "the ecosystem" is a huge concern, technical strategies also need to help mitigate. For example, if you're running the same JS code both client and server side and you're worried about changes in the client-side ecosystem, you might want to think about implementing the backend in something more boring and stable just to mitigate ecosystem risk.

The code that you can't afford to rewrite is the code that is hairy with details. The details are some mix of essential and incidental complexity. The ratio is dependent on the degree of fit between your business logic and the framework, the primitives it's built out of, whether it's third-party, custom framework, custom language, whatever. And of course any custom component has its own complexity; it should be additive, but it may still be large. A good fit - an excellent fit - means your business logic is clear, concise, and is operating over abstractions that map directly to the business concepts. A poor fit is speaking haltingly in unidiomatic language, too verbose, aggregating globs of ugly code, losing track of the forest for the trees, etc. But it'll be easier to find average devs who are familiar with the particular style of thicket that ends up coming out. We even have names for the scar tissues that grow around each glob, helping them interface - we call them design patterns.

There's no hard and fast rules, it seems to me. Use a small fraction of lots of different third party bits and pieces and you get a recipe for pain. I'm fairly certain there's no more productive way for engineers to code than to raise the level of their language into their business domain - http://www.paulgraham.com/progbot.html - but this is the custom framework / language approach. I'm also fairly sure that it's hard to scale an organization around this approach because of the incentive problem when hiring developers. I think it only really works for startups that are composed of a bunch of hackers with decent equity stakes. It doesn't work out for employees, unless the company ends up moving the needle industry wide, like Java or Rust or React, and that's really rare, too rare to bet on.

Well, my thought is that, on average, learning people have less organizational impact than experienced people, both in a positive and a negative direction. You get the risk more concentrated in super-senior engineers. Hiring a dozen net-uninformed college grads would do the trick, too, though.

Its the medium-experience Engineers that pose the risk then, of having enough knowledge to talk, but not enough experience to appreciate the fine points of what they're talking about. They fool management with plausible but wrong arguments. In my experience anyway.

And today, the demographic may be skewed toward just that group.

It's unfortunate that we try to measure this kind of thing on a single dimension. There's certainly a type of developer/mentor who does do a good job of setting helpful directions in a large-team setting. At the other extreme, there are people who don't necessarily thrive in a "team setting" at all, but on the other hand can build big things (or, better yet, small things than solve big problems) remarkably quickly. Both "high multiples", but quite different skills.

(There does seem to have been a fair amount of devaluation of solo-working over the last few years, which perhaps leads to less appreciation of the second kind of high-multiple than was once the case).

> Of course, make sure those people are also compatible, as half the 10x devs I know are loners who don't mix well and work best when left alone.

This is absolutely a great point, and the author also addresses this:

> That doesn’t mean that a top-performing developer will write 10x as much code or crank out 10x as many features. What it means is that they’ll deliver 10x as much organizational value.

I too have seen developers who are very talented actually cause negative organizational value, due to their inability to work well with others.