To paraphrase LeoTolstoy?, "Good programmers are all alike; every bad programmer is bad in his own way".
To paraphrase the bard, "Some are born bad, some achieve badness, and some have badness thrust upon them".
Programmers can be compared by a number of factors, including education, programming language and operating system preferences, now an new factor has been added and that is by their pathology!
This idea stems from the discussion/argument/bitching on the subject of the MicrosoftProgrammerMentality, where it was observed that although one can become a bad programmer through being brought up on MicroSoft programming tools, there are other ways to become a bad programmer.
So, varieties of bad programmer:
I would disconnect pathology from the concept of "good" or "bad" programmer and associate it with motivations for programming.
FanaticOrientedProgramming asserts like-minded developers tend to be more productive together. Thus, if you put a bunch of Perl fanatics or Smalltalk fanatics in the same room, productivity goes up under this theory. The less mixing of diverse viewpoints, the less chance for HolyWars. The flip theory is that diversity keeps a form of checks and balances.
Just because Perl code looks goofy to me does not mean that it will to a Perl fan also. Perhaps the challenge of reading obtuse code keeps Perlers awake and less bored, preventing burnout.
Notwithstanding the LimitsOfHierarchies, can we divide these up a little? It might help to avoid ThreadMode, or allow the conversation to fan out a bit.
I recall a PathologyOfProjectFailures? mentioned a few months back, provided as a link to an external MS Word doc or similar?
http://www.thomsett.com.au/main/articles/path/toc.htm is mentioned on RealStoryAboutDeveloperTurnedManager. Is that it?
See also ProgrammerStereotype