It's quite fascinating to read arguments from someone with such a fundamentally naive and unquestioning trust in authority. It's no wonder we don't see eye to eye - it's obvious that your default assumption is that the people in power are always the right and best people to be in power, and the threshold for evidence to prove otherwise seems unreasonably high. Your extremely narrowly selected examples make this authoritarian starting point abundantly clear. Let me present a far more realistic scenario:
A talented and experienced, but (slightly?) temperamental developer has worked on the same project for many years, and has gotten used to a specific way of thinking and approaching development. A new person joins the project, with talent and experience but no knowledge of the specific workings of this working group or the established norms for the project. The new developer makes a suggestion, which gets shot down harshly and unprofessionally by the experienced developer. This might be because the suggestion was bad, or because the suggestion followed a logic or approach that didn't match the norms of the development team (but might thus have lead to better solutions in the long run, as more diverse solutions attempted = better solutions arrived at).
Either way, there are three possible outcomes here.
- The new developer lets the established one know that the response was inappropriate, and the experienced developer accepts and apologizes. They address this as adults, reach a productive compromise (whether this is the new developer adapting to established approaches, or the experienced developer recognizing the value of a solution outside of their normal mode of operation), and the problem goes away. This is likely to increase both productivity and quality of output.
- The new developer lets the established one know the response was inappropriate, but the experienced developer rejects this entirely, and refuses to adjust their behaviour on the grounds of seniority and experience (neither of which are relevant to interpersonal behaviour). The new developer is less motivated because of this, feels devalued and looked down on, and either produces lacklustre code, or just quits. This reduces the productivity and quality of output of the group, and the group loses out on potential improvements.
- The new developer lets the established one know the response was inappropriate, but the experienced developer rejects this entirely, and refuses to adjust their behaviour on the grounds of seniority and experience (neither of which are relevant to interpersonal behaviour). The situation escalates, and the less experienced developer is fired/expelled from the group, as the senior developer has more authority. Again, this reduces the productivity and quality of output of the group, and the group loses out on potential improvements.
This scenario is
far more likely, as it's highly unlikely that a "fresh off the boat" programmer is given a significant position in a team at a level even remotely like this (does the TAB include anyone and everyone who says they want to join?). Your example draws up an extreme situation where one person has all the skill, ability, experience, power and status. Why would a situation like this arise at all?
As you can see, there's only one outcome that doesn't actively harm the efforts of the group. Having previously established and enforceable norms and rules of behaviour makes it
far more likely that the productive solution is the one reached, as otherwise the decision is likely to default to the person with the most power and authority, even if they were in the wrong. And even if that person were in the right, it's still detrimental to the quality of work and level of productivity for them to unilaterally exert power over other contributors, as this harms group cohesion and undermines cooperation.
Besides this, what you're describing isn't a meritocracy. As such, the term post-meritocracy is kind of silly (given that there never has been one), but it needs to be used as people like you keep harping on it. The meritocracy isn't, and has never been real. Ever. Period. There is no such thing as pure merit outside of abstract thought experiments or oversimplifications irrelevant to real life, and no workplace has ever been free of social interaction and thus complex social dynamics. Judging from their manifesto, the post-meritocracy movement is doing nothing more than recognizing and underscoring this simple, plain
fact. If you choose to deny this fact, that's on you. But please stop acting like you're promoting some sort of Platonic ideal of a meritocracy. Real life doesn't work that way, and if you can't see that, that's a failure of your perception of the world, not my arguments.
Also, again:
please stop it with the damn straw man arguments. Have I suggested replacing programmers with sociologists and psychologists? Don't be absurd. Seriously, I'm getting tired of these silly attempts at derailing the discussion. (And, not that it matters, but it's not like academics are even remotely less anti-social than programmers.) You're (purposely?) reading my argument fundamentally wrong. My point is this: being a talented programmer does not mean that you're a talented group leader, manager, or strategist. Some, of course, will be one of all of these, but some will of course not be. The ability to write good code is not at all a predictor of the ability to create a good working environment. As such, saying "person X is a talented programmer and is as such the best person to decide on the future long-term developmental goals and strategies" is a misunderstanding of the point of making software. Software has a purpose, and that purpose is not "to be programmed well" - quality programming will make the software
better, but it won't make it
useful or
suited to its purpose. As such, planning, strategy and management requires insight into how the software is likely to be used to at least an equivalent degree as it requires insight into how the program is written.
This alone shows how your idea of a "meritocracy" is incompatible with reality outside of projects where the use case is simple and predefined/known and there is one developer (or very few who already know each other and thus have already established norms of conduct). Linux - or any piece of complex software created by a team - does not fit within this description. It might thus very well be a mediocre coder has the best vision of how to best decide the future direction of development, or that an excellent coder has chronic strategic tunnel vision and can't understand how and why people use the software. The requirements for creating good software is thus not simply "have good coders". You also need good leaders, good plans, good teamwork, and good relations. The latter two
require mutually agreed-upon and
enforceable rules and norms, otherwise you'll either have unproductive chaos, or waste time solving simple, silly situations, both of which are antithetical to making good software.
