Commentary: How to tell who your best programmer is
As software engineers work together, they determine who is knowledgeable and easy to work with. After working on a few projects together, the experts in particular technologies show themselves, and questions get routed to the right person. As people work together, they learn how to treat each other by the way that they are treated. Nature brings true expertise to the surface, and the team learns how to work with jerks to minimize their impact. For example, Team Member A might realize that Member B is the best person to talk to about a particular technology but that you shouldn’t do so in the morning and butter them up a bit before you ask the question.
But the manager doesn’t know this.
How to tell who your best programmer is is written not from a coworkers perspective but from that of a manager. It speaks to the struggle that people have in determining which experts to trust. When developers disagree, and you are their boss, and you have to determine which one of them is right - how do you do this?1 You need to figure out who to promote or give feedback to and you are not in the trenches watching the work happen, how do you do this?
Human nature dictates that you tend to do this based on several things that can easily become anti-patterns:
Conflict avoidance: this normally lets jerks win arguments
Deferring to power: the longer someone has worked somewhere, and the more secrets they know, the worse their behavior can become because people are afraid to cross them
Strong track record winning arguments: whenever there is a disagreement on the team, a certain person ends up being perceived as right, and this has to count for something, right? But they may have “won” because they started the argument to show how smart they are; the argument might have been a waste of time, and everyone might have just deferred to them to avoid it continuing to waste time
Loyalty: the developer has worked here as a Senior Software Engineer for 25 years! They must be great, everyone else leaves within a year! This pattern seems obvious when pushed to the extreme like this, but there are cases where a programmer has spent as much time defending their castle as building it well, so this builds them (false) job security and makes it harder for them to leave or for others to help.
Visibility leads to familiarity: you always see problem programmers; they somehow are always at the center of discussion on some problem (maybe they caused it and are most familiar with it). It can be hard to tell if someone is arriving as a hero or a suspect, you just know they are always around during situations
Genius stereotype problems: society reinforces the stereotype of the hard-to-work-with loner genius, and so at times we categorize loners and people that are hard to work with as geniuses when they aren’t.
This anti-pattern is about how people who are not easy to work with can sometimes be perceived as smarter than they are because of these default behaviors.
In an ideal world, programmers are instead judged on how well they help the team. In The Worst Programmer I Know, the case is laid out that measuring individual productivity is perilous because it misses those developers who elevate the team’s effectiveness. Mentorship and helpfulness do not always show up to a manager but are deeply felt by peers. If a developer is generally helpful and wants the work done, no matter who gets credit, they should be rewarded. And if they yell, bluster, and hold tight to areas of the system in an unhealthy way, they shouldn’t be.
As a manager, you likely should not settle arguments. Three people are involved, and the one who knows the least should settle it?