You know that famous inverse square root code? Apple basic?

Some things just cannot be pair programmed. They are simply impenetrable to average minds at the time.

Your argument sounds like one for a Handicapper General, to be honest. (If missing the reference Google it). You want to handicap everyone actually competent with a slower partner. And before you claim the usual: it is ok to write suboptimal but simple to understand code, consider that in some cases we actually DO care for performance and size of code..

99.9% of modern software does not require that level of cleverness. Also, the fast inverse square root code is a poor example as it's:

1) A very small amount of code

2) Isolated from everything else

3) Conceptually easy to understand what it's accomplishing (even if the implementation itself is interesting and non-obvious)

Most people would kill for a colleague who wrote code like that.

No, instead what you most often get out of people like the OP is mentioning (because I too have worked with and been burned by them) is some weird pseudo-ORM they wrote from scratch because they don't like how Hibernate handles joins.

Naturally, there's no documentation or even comments because it should be obvious why paxos was poorly implemented in this weird pseudo-ORM framework. And of course, the entire codebase was rewritten overnight to use this new framework as well.

Metaphorically speaking, some mountain routes require a very, very good climber to scale. If it is a team that you are trying to get to the top, that amazing lead climber still needs to throw a rope down to the rest of the team.

I do agree that sometimes managers want to fit "chefs" into a McDonald's like cooking process.

"team-oriented behavior"? So the talented individual gets to write all the code and explain it to other people at the same time?

This is a well known major impediment for creative persons in any field. You can explain things after they are done, not while you are doing them.

This is why average developers create such a drag on productivity. They always want meetings, explanations -- in short, anything that slows down the work horse and make them look productive in the process.

This is not 10x, this -10x. If a developer churns out tech debt in a vacuum, they're a liability, not an asset.

The parent post seems to assume that a "heroic sprint of productivity" would not include communication and documentation, i.e. that productivity only means coding. I don't see that assumption reflected in the grandparent post, and moreover if you don't consider communication productive in its own right, you're going to have much bigger problems than people taking a day off.