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.
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..