When I was a team leader in a smallish shop, there were several folks who I had to have reassigned (neither I or my direct supervisor had termination capability without a ton of Red Tape) or to have no contract renewal at the end of the current engagement. Some of the types enumerated also worked for other team leaders, and they pretty much took the same view. Things which took folks into the "Bad Programmer" category in my book:

1. Untrainable or Ossified in the past.
   When the 'programmer' doesn't seem to be able to absorb the new system, new tool or whatever is being deployed, no matter how the training/education is done. Has to repeat said training on a frequent basis.
   When the 'programmer' only knows the technology or coding paradigm that they used 10 or 15 years ago. It was good enough then, so why should they change?
2. Cowboy coder
   The person who codes first, without a plan. The 'programmer' who makes untested changes to the production code and/or data "because we gotta get it fixed now" and then is surprised when the "fix" fails.
3. The weather-vane
   

When I was a team leader in a smallish shop, there were several folks who I had to have reassigned (neither I or my direct supervisor had termination capability without a ton of Red Tape and a pile of documentation.) or to have no contract renewal at the end of the current engagement. Some of the types enumerated also worked for other team leaders, and they pretty much took the same view. Things which took folks into the "Bad Programmer" category in my book:

1. Untrainable or Ossified in the past
   When the 'programmer' doesn't seem to be able to absorb the new system, new tool or whatever is being deployed, no matter how the training/education is done. Has to repeat said training on a frequent basis.
   When the 'programmer' only knows the technology or coding paradigm that they used 10 or 15 years ago. It was good enough then, so why should they change?
2. Cowboy coder
   The person who codes first, without a plan. The 'programmer' who makes untested changes to the production code and/or data "because we gotta get it fixed now" and then is surprised when the "fix" fails.
   The Cowboy is also most definitely not a team player. Doesn't need no stinkin' team.
3. The weather-vane
   This 'programmer' is enamored with the "technology du jour" and sees every new framework, language, methodology or whatever is new and hot as the
4. The "Big Brain"
   This 'programmer' is so sure of his talent and capabilities that things are done which don't make a lot of project sense. e.g. Rewriting a standard library "because it is inefficient for our system" or introducing tools and techniques not suitable for the problem at hand. e.g. Introducing Lisp or Forth in a mainframe environment.
5. LOC ^a. Sandbagger
   This 'programmer' uses obfuscation and mis-direction to increase the ^a. LOC: Lines of Code that get paid for. I have seen code in this situation that was was page after page, screen after screen of duplicate structure and logic, with only the paragraph or control variable names changed to pump up the line count.
6. Indispensable Expert
   The 'programmer' who has the domain knowledge to solve the problems at hand, but since they "know" everything about it. As a matter of fact, if they were to be hit by a bus, then the whole organization would come crashing down. {Observation: Those who think they are indispensable usually are. (Anyone got the source on this aphorism?)}
7. The Pasta Chef
   This 'programmer' specializes in spaghetti code, spiced with identifiers that are just too hard to follow without a syntactically implemented IDE. e.g. IndexI1O0, Index1I0O, etc.
8. Summer Intern - Specifically subtype Walking Disaster
   My old shop used to hire a number of late high school or college age interns. One time a department needed a small database to track some equipment usage, (now this was waay back, and it was using dBase III). The guy coded along all summer, but was not done when college started in the fall. He got a one week extension then a second week. At the end of the second week, I got sent out to take his project over and bring it back in to Systems Development to be finished. He showed me the stuff he had done, and then the unfinished part. What worked had nice eye candy, but the application was incomplete. When I opened the new box of formatted floppies to get copies, he said, "just a second, let me delete my test files..." and before I could say anything, he'd deleted a bunch of files.
   Being the suspicious sort, and finding that his application was almost nothing but eye candy when I got back to my shop, I went back to the department and pulled out Norton and undeleted the files he'd deleted, trying to find some additional logic, even if incomplete.
   I found, not bad logic, but bad behavior. The printer attached to the PC he was using was a daisy wheel printer. The character set normally mounted was a swiss variant. The output of the deleted programs put out a name, address, DOB, some letter codes and some type of id number. The format and layout bothered me. All the birth dates for multiple people were barely legal drinking age. Most of the addresses were not there, when I looked them up in our criss-cross directory. When I showed the printouts to his supervisor, he looked at me and said "Driver's licenses, don't you think?" I said I did so. He said that was why he'd found the transparency stock all cut up in the trash next to the Xerox. Our bad boy had made overlays to adjust his and and his friends ages on their drivers licenses. We reported it to the authorities. He was not paid for his last two weeks.

These are just some of the bad characters I have had to work with....

/s/ BezantSoft