Worst programmer in your team, how to tell?

There are certainly many methodologies available to figure out bad programmers. But these methodologies miss many aspects like programmers’ ethics, understanding, estimation etc. Following data is compiled from a small survey conducted on LinkedIn by Esther Schindler.

Don't care about the quality of their work. This shows in both personal attitude and in code quality (such as a lack of software testing). "The worst programmers tend to not buy into the project emotionally, intellectually and professionally," wrote one computer consultant. "They tend to show up, do the bare minimum to get by, and then leave." Their lack of engagement usually hurts the project, he says, in big ways (such as misses in requirements) and subtle ones, too. Or, as another described concisely, "The one [who] makes most money out of least work."

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


Cost the team in time and frustration. One Java developer explained, "A bad programmer is someone who, simply by working, creates more work for the others on his team. When he codes something, he breaks other things, such that just because he did his job, the jobs of others become harder."
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."


Have a poor sense of timeliness. Software project estimation can be a black art, but a developer who cannot grasp a timeline or meet a non-arbitrary deadline is a big problem.


Do not offer or ask for help. Wrote one project manager, "I expect developers to seek help when they need it, to collaborate with others, and to raise any concerns and/or opportunities for improvement to their manager." Team players learn from others and teach others, and that shows in their mutual appreciation for one another.


Are arrogant. I'm hesitant to use that term, because a true expert's self-confidence can easily be mistaken as "Who the heck does she think she is?", but several people pointed out that the worst programmer often has a superiority complex. Wrote one software engineer, that individual knows he is always right and knows everything even (or especially) if he is just out of school. "Argues with everyone including software architect. Makes every meeting painful and long. Sneaks in unapproved tools/software/programming languages/databases."

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.


And a good manager wrote this note:

"If I were to give a short answer, it would be that the worst programmer on a team is the one who spends his/her time trying to identify the worst programmer on the team. (And that's the worst manager, too.)" "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."