[zmmmmm]

> above average programmers, if nothing else than because they are engaged

But are you really "above average" if you are incapable of actually producing something large scale because your temperament is such that you can't stand working in a "boring" "unproductive" language?

It's sort a tortoise or hare type situation: the hare runs really fast but if that doesn't win you the race, who cares? There is an even rarer breed of programmer who operates as both the tortoise or the hare. Those are the true "above average" programmers in my view, but you can pretty much exclude the elite crowd of folks who "refuse to program in Java" or will confine their entire job search to companies that use their favorite language from that category.

[cutler]

Good point. When I discovered Clojure and saw the light after listening to Rich Hickey's sermons on The Mount I found it almost impossible to work with OO code. Years later I asked myself if this had actually benefited me professionally, other than simply broadening my mind, and I concluded it hadn't because it limited me to the tiny number of Clojure jobs available and ruled-out earning good money working on existing code. In recent years I've had to reverse-engineer this experience and get to grips with the likes of Java, Kotlin, Ruby and Python.

[goatlover]

> But are you really "above average" if you are incapable of actually producing something large scale

Wasn't the OP's conclusion that large scale was due to not being able to scale the team into the hundreds and not any limitation of a small team?

There's only so much code that a handful of programmers can write and maintain in any language. The scaling issues comes up when you need to make your team a lot larger.

[zmmmmm]

Yes. I think one of the interesting things in software is the irrational amount of productivity that a small team can accomplish, but that it can only be done by doing things in a way that can never be executed by a 50 person team.

So it is possible for 3 - 10 developers to maintain a product that perhaps, would need 50 developers using fully maintainable methods. But the 3-10 developers can never produce what 500 developers can. And there's a valley of death between about 10 and 30 where you actually go backwards. With 20 developers you might accomplish less than with 10 unless you very carefully and strictly compartmentalise the team (at which point you have two teams of 10 developers that don't interact ...).