Who’s the worst programmer on your team? How can you tell?

I bet you could point to the weakest software developer in your department with little hesitation. But if I asked you to identify your criteria, it’s unlikely that “metrics” would play any part in that judgment.

Since the earliest days of software development, the Suits have grasped at metrics to evaluate programmer performance. They started out by looking at the number of lines of code generated, and then the methods got even sillier. Every discussion about programming metrics begins by saying, “We know this is only slightly useful, but….”

The purported goal in collecting such measurements is to judge team members’ production. With the best of intentions, a manager wants to use that data to strengthen and reward top performers, and also to identify weaker team members so they can be trained and improved. (Right. Its usefulness in “Who to fire or lay off” would never be relevant, I’m sure.)

The problem is… the metrics don’t really help managers accomplish that. Just as you shouldn’t confuse the map with the territory, looking too hard at metrics—any metrics—causes you to put your attention on the ruler, not the object being measured. Looking only at the yardstick makes you lose sight of the mission, which is probably something like “create happy users” or “deploy useful software on time and on budget.”

I do understand the goal. Nobody wants to work with someone who is bad at what they do. Managers want to be fair and… well, not dispassionate, exactly, but at least even-handed. But judging a team member’s contributions isn’t easy. It’s even harder if you’re not looking at the developer’s code day-to-day, or if your lack of technical expertise keeps you from understanding what you’re looking at. (That’s okay; you’re a manager. Developers don’t always expect you to write code anymore.)

Yet, I think you could do a quiet survey in any programming shop, asking everyone who the weakest contributor is—and probably get the same answer from most team members. (My gut tells me that you’d get less consensus from “Who’s the best programmer?” but that’s another discussion.) This all came to mind recently when, in the comments to James Turner’s When Agile Projects Go Bad, a few Agile un-fans recommended that companies just “fire the bad programmers.” Okay, maybe—but how do you know who they are?

That was the question I posed on LinkedIn and almost immediately I got a few dozen responses. You can read through the entire discussion if you like (I think it’s fascinating), but in the rest of this blog post I summarize the wisdom I gained from some very smart software developers, and then follow with a few thoughts of my own. You’ll notice one important thing: metrics aren’t part of the criteria.

Developers whom others label as bad:

Attitude matters a lot to team members, much more than does technical skill. (Ignorance is curable, after all.) “There is a difference between someone who has potential vs. someone who just does not get it,” wrote a project manager, “Even if the latter may be stalled in development but temporarily appears superior to the one with potential.” Wrote one woman, “The worst programmer on the team is the person who creates a counterproductive environment for other team members. Regardless of this person’s technical ability or volume of output, he/she has a net negative effect on the team’s productivity.”

Bad developers create buggy code that needs to be reworked, reducing the team’s ability to Get The Job Done. “This should be obvious from change logs and QA reports,” pointed out one respondent—one of the few places where “metrics” enters into the equation.

From the business viewpoint, what matters is the end result: the quality of the software. “Code speaks louder than words,” wrote one person. But many managers can’t differentiate between good and bad programmers and, he added, “They can’t distinguish good software design from bad one[s] either.”

Personally, I’d refine the sentiment to stress that the “arrogant” label is heavily tied to the previous “unwilling[ness] to learn from others.” The hallmark of a true expert is that she knows how much she doesn’t know; ersatz experts assume their work is perfect.

Instead, Weinberg says, “We’re not in the ‘worst programmer’ business. We’re in the producing good products business, and that’s a team job, so we’re good or bad together, not as individuals. (Obviously, certain extreme cases shouldn’t be on the team in the first place, but those are rare, though memorable.) Quit asking this question. It’s a sign of bad, bad management, and will destroy most teams.”

I take Weinberg’s point, particularly keeping in mind Rudy’s Rutabega Rule from his Secrets of Consulting book. Or to use my own analogy, looking at a tree to see which branches to whack off only tunes you to look for dead wood, instead of recognizing whether the tree needs water or fertilizer.

However, I don’t regret asking the question. I’ve encountered a few truly bad programmers in my time, people who made me say, “How can this person possibly have five years of experience?” and yet who manage to stay employed. One such “experienced” rotten programmer burst into tears when she couldn’t understand an ordinary nested IF statement (I am not making this up) and wanted another team member to turn every branch into a standalone procedure. Another’s idea of debugging was to copy-and-paste code everywhere, with plenty of GOTO statements; Ken sure would have looked good in those Lines of Code charts.

One thing that’s clear to me (and should reassure some readers) is that the “worst” developer on a team is not necessarily the least experienced. Someone who knows his strengths and is actively trying to address his weaknesses is often appreciated for the former and cheerfully mentored for the latter. Savvy managers enable the process because, as Weinberg says, the team is good or bad together.

I could end off right here and feel as though I represented a cross-section of developer opinion, but that wouldn’t take into account another important aspect of team-building: the team members’ average intelligence and ability. Because “bad” extends past “incompetent.”

For example, brilliant programmers create work for the not-so-brilliant around them. Mediocre programmers might well think those übersmart developers are the “bad” programmers because the smart developers are not conformists. They do things that make the rest of the team stretch (such as, when the team culture is to take the easy way out and use too many shortcuts). They force team members to work outside their comfort zone.

By my observation, mediocre programmers imagine that every line of code should be written for their benefit, and brilliance should come for free. For example, I know one programmer who writes incredibly dense, super-optimized code which generates very fast applications; it’s not necessarily easy to read, and learning how the code works requires a developer to rethink design assumptions. But the effort is worth it, because the people around him say, “Oh! Wow!” when they “get it.” Fortunately for everyone in that open-source community, his work is appreciated. (I suspect that the willingness to accept other’s input is among the strengths of open-source development, but that too is another discussion.)

What did I miss? If I asked you to tell me about the worst person on your team (let’s make it from a previous employer, so you don’t have to worry about career-limiting moves), who would it be… and why?