> For routine tasks, professional programmers have a narrower range of productivity than we first supposed, but almost half of the variation in individual productivity is noise, making programmer rankings suspect.

> Focus only on Programming Effort (limit the scope)

> This is for small programs that should not exceed normal capability

Yes, when you eliminate most of the sources of variation, there is a lot less variation. The most efficient developers aren't more efficient because they churn out boilerplate code faster.

Top talent in big tech are not working as programmers. They work as engineers. They often do a limited amount of actual programming, most of the contribution is leadership, design and architecture.

I agree completely, I think this is really the distinction that is lacking when people talk about superstar developers. Most aren't developing much of anything in terms of raw implementation, they're redesigning existing architectures, theorizing new approaches, bridging domains, etc.

Those skills are often tied to specific domains that are not quickly transferable so what talented engineer A does efficiently or makes them a superstar is specific to engineer A. Talented engineer B probably does something a bit different or has their own sets of expertise they're superstars at.

There are a lot of misguided organizations hiring on the wrong premise though, that there are developers who just churn out implementations at 10-100x speed so they can reduce their workforce. What they should focus on is engineering talent that makes sure they're tackling the correct problems and focus on the right solutions to those problems as opposed to something silly like developer velocity.

You explained the fundamental philosophical divide in software development today. One group sees development as a process of production. They still think of developers as people who produce code. The other group sees software development as a process of problem discovery and definition. Programming is an exploratory learning process that, at its best, refines and condenses human concepts and symbols into concrete representations automated by a computer. In my opinion the latter group will always outperform the former (barring massive resource discrepancies) because they have a more powerful theoretical grip on their activities.

A great design/architect will mean you need to write 1/10th as much code.

Well, not really but maybe 1/2

Dominique Brezinski's latest Spark Summit talk is what cemented my feeling that superstar economics are at play in the current marketplace (in certain fields): https://databricks.com/session_na20/patterns-and-operational...

He talks about the data processing framework he built that's ingesting "hundreds of terabytes, approaching a petabyte a day".

New technologies let small teams do tons of work.

Quite. 10 fresh graduates of the University of North Central Tennessee’s CS program are capable of doing a better job of anything in the CS realm than Notch, Jeff Dean or Linus Torvalds.

I highly doubt that for Dean and Torvalds. They are not programmers, they are software engineers. Both guide others to make 10x or 100x impacts to the world. 10 new grads, in most cases, cannot do that. Let alone this takes for granted both of their algorithms and data structures knowladge.

While Jeff is a great programer, writing code has not been his primary contribution at Google.

When you have multiple people, there's an increasing amount of overhead, from communication, from coordination, needing someone to manage and lead. Now if a single person is able to do the work of multiple people, or even more so multiple people from different disciplines and different teams, then you are gaining much more efficiency. Because you've now replaced 4 people, and then you're moving 4x faster than those 4 people were working together, because there's no overhead required. So now it's actually a 16x speedup. In the same time that it took someone to schedule a meeting with the other team's manager to ask for resources to prioritize time in the next sprint, for someone to review the design and then help out, your superstar already did the whole thing herself after lunch.