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:
- The MicrosoftProgrammerMentality - If management likes it, it must be good
- The PerlProgrammerMentality? - code as fast as possible. If it's imperfect in any way, scratch it and start over.
- The LispProgrammerMentality? - cleverness for cleverness' sake!
- The CprogrammerMentality? - I like a language that lets me write my own malloc. Mine will be faster anyway.
- The SqlRdmsProgrammerMentality -- If we just join these 7 tables and use a computed having clause, the answer is correct by implication. (RelationalWeenie perhaps?)
- The OoMentality? - Make a big hand-programmed NavigationalDatabase in code, and tell anybody who thinks it is a mess, "you just don't get it".
Note that the names reflect stereotypes; not every Perl programmer suffers the Perl pathology, and there are people who use languages other than Perl who do. The names are simply convenient (if perhaps unhelpful)
I would disconnect pathology from the concept of "good" or "bad" programmer and associate it with motivations for programming.
The second quickly become managers :-)
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 HolyWar
s. 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.
- Personality disorders (!)
- Probably acquired/learned (and can therefore be corrected)
- Probably genetic: Aspergers, et al.
- Management structure
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