Hi Esther,

I'd like to add a few (mostly qualitative) metrics to your and "LinkedIn's" set of criteria. These are what I use:

• She never asks inconvenient questions and always agrees with concepts that are descended on her from above.

• Any new thing is a pain for her. For example, she very reluctantly switches from one part of the system to another

• She prefers working by herself. Other folks prefer not to take her as a programming pair

• The amount of refactoring her code needs to go through is huge

• When you consider assigning a tough task, her name isn’t the first that comes to your head. It’s not the second either.

• Your key developers are very careful selecting the words while qualifying her work

• Her salary is below average in your team (I firmly believe that if you are letting go your highest paid guys, this just means you are poor manager and must be let go first)

Please note that I do not talk about personality misfit. This goes without saying. I also don't talk about the amount of work since this has already been covered.

I would add that I saw two types of bad programmers. One type is shy and quiet: they know what they are and try to get under the radar. Another type has absolutely inadequate self-assessment – those are easier to weed out.

Truly,
Eugene Nizker
Evident Point Software

I enjoyed Ms. Schindler's article very much but somewhat disagree (or at least need to qualify) her final example about the programmer who writes very "tight" and "optimized" code which is "difficult to read and understand".

In truth, easy-to-read and understand code almost always trumps tight and optimized code, especially in the context of who is the "best" programmer on the team.

Many programmers have an internal need to be clever and write the "best" code, when in truth, "good enough" but highly maintainable and understandable is usually better for the overall project.

Stuart

I think a development process may help a lot at identifying fast bad practices by team members (developers or managers). If these problems are not addressed, the badness virus will spread, even to the best programmers. They will start to care less and less and try to leave.

Agile processes produce work in short iterations, so they will highlight weak spots in the projects very fast, whatever their level is (dev, management, design, ...). In Scrum for example, teams meet daily, so trashing (be stuck on a problem for days) can be avoided. And Iterations post mortem is the place to wrap up what has worked great and what has not. Lessons are learned from each iteration.

What is interesting is absolute stereotypes are hard (if ever) to find. Between absolute black and white, there are many shades of gray and developers generally have combination of good and bad traits. This is what confuses non-coding managers big time identifying the bad apples or the weakest link.