For those who work inside Google, it's well worth it to look at Jeff & Sanjay's commit history and code review dashboard. They aren't actually all that much more productive in terms of code written than a decent SWE3 who knows his codebase.
The reason they have a reputation as rockstars is that they can apply this productivity to things that really matter; they're able to pick out the really important parts of the problem and then focus their efforts there, so that the end result ends up being much more impactful than what the SWE3 wrote. The SWE3 may spend his time writing a bunch of unit tests that catch bugs that wouldn't really have happened anyway, or migrating from one system to another that isn't really a large improvement, or going down an architectural dead end that'll just have to be rewritten later. Jeff or Sanjay (or any of the other folks operating at that level) will spend their time running a proposed API by clients to ensure it meets their needs, or measuring the performance of subsystems so they fully understand their building blocks, or mentally simulating the operation of the system before building it so they rapidly test out alternatives. They don't actually write more code than a junior developer (oftentimes, they write less), but the code they do write gives them more information, which makes them ensure that they write the right code.
I feel like this point needs to be stressed a whole lot more than it is, as there's a whole mythology that's grown up around 10x developers that's not all that helpful. In particular, people need to realize that these developers rapidly become 1x developers (or worse) if you don't let them make their own architectural choices - the reason they're excellent in the first place is because they know how to determine if certain work is going to be useless and avoid doing it in the first place. If you dictate that they do it anyway, they're going to be just as slow as any other developer.
You've really hit the nail on the head here, and my response to the article was along the same lines:
Solving the right problem in the right way is the key of programmer productivity. Every programmer in existence who has a baseline of critical thinking has written the wrong code before, and then reflected on it and improved it. You can do this at any level of abstraction from the details of bit flipping all the way up to whole systems architectures. The very best programmers are the ones who are able to think about the gestalt most effectively. This is a tremendously difficult task give our limited conscious brain capacity, and I constantly feel myself bumping up against the edges of it when I work on a big project.
One example of a programmer I really look up to is Yehuda Katz because of his work on Bundler. Rubygems had an awful lot of pain points for large projects, and worse, it had a culture of borderline denial about the existence of these pain points. Yehuda and Carl Lerche worked relentlessly to come up with a solution that addressed 99% of all the recurring projects across a wide variety of scenarios. Then they powered through over a year or more to hammer it into a reliable solution built independently and only loosely coupled with Rubygems. Sure it took months and months and untold hours of hard work, but in the end they effected in a sea change in Ruby dependency management which would have been impossible without the ability to see all sides of a very multi-faceted problem. To me that goes beyond 10x because you could have 1000 good engineers and still not be able to design Bundler.
That's the right lesson. The difference is actually even more stark than that: if you extend it out to picking the right project in the right company in the right industry, there're positions where you can be easily 1000x more productive. Project selection probably determines more of your productivity than almost any day-to-day coding decision.
And in fact, writing scads of dumb code is often the sign of a poor developer. It often follows from the "never turn back" mentality, that leads them to follow an initial poor choice of solution through to the bitter end.
> The reason they have a reputation as rockstars is that they can apply this productivity to things that really matter; they're able to pick out the really important parts
That is the same thing as saying that they are, in fact, more productive.
Productivity is improved by one's ability to synthesize technical concepts and experience; to market (internally, amongst peers) one's ideas; to communicate; to convince; to adapt; to select; and to balance all of these tensions.
> They don't actually write more code
The "10x developer" meme was never a claim on LOC. At least I hope not.
> the code they do write gives them more information, which makes them ensure that they write the right code.
The reason they have a reputation as rockstars is that they can apply this productivity to things that really matter; they're able to pick out the really important parts of the problem and then focus their efforts there, so that the end result ends up being much more impactful than what the SWE3 wrote. The SWE3 may spend his time writing a bunch of unit tests that catch bugs that wouldn't really have happened anyway, or migrating from one system to another that isn't really a large improvement, or going down an architectural dead end that'll just have to be rewritten later. Jeff or Sanjay (or any of the other folks operating at that level) will spend their time running a proposed API by clients to ensure it meets their needs, or measuring the performance of subsystems so they fully understand their building blocks, or mentally simulating the operation of the system before building it so they rapidly test out alternatives. They don't actually write more code than a junior developer (oftentimes, they write less), but the code they do write gives them more information, which makes them ensure that they write the right code.
I feel like this point needs to be stressed a whole lot more than it is, as there's a whole mythology that's grown up around 10x developers that's not all that helpful. In particular, people need to realize that these developers rapidly become 1x developers (or worse) if you don't let them make their own architectural choices - the reason they're excellent in the first place is because they know how to determine if certain work is going to be useless and avoid doing it in the first place. If you dictate that they do it anyway, they're going to be just as slow as any other developer.