Seven Habits Of Highly Defective Programmers

1. Work alone, but insist your paradigm or technique is the best without supplying objective evidence.

2. Play RamboCoder politics with your PointyHairedBoss, so nobody can blame your code.

3. Learn your language well enough to play JobSecurity games

4. The only thing better than staying up all night to debug your code is making someone else do it.

5. Follow your vendor's example code closely, to maximize VendorLockIn.

6. Ensure your reward system tracks KLOC, not subjective things like a bug rate.

7. If your project is in trouble, make sure you get paid for it as long as possible, riding the ship down, until you can base your transfer strategy on promoting how you were the last best hope for a project that others obviously ruined.

---

7a. Not KnowingWhenToStop: listing more than seven habits.

7b. Insisting another paradigm or technique is flawed by not accepting subjective evidence.

7c. Being overly concerned that a list of seven contains more or less than seven. Being overly concerned with OffByOne?

7d. Filling wikis up with fights instead of beauty...

---

How about these

• Don't automate your processes (e.g. compile/build/deploy) and riddle them with un-intuitive steps, so only you know how do them: another JobSecurity game without the need for deep knowledge of anything at all.
• Extend the above by keeping as many processes manual instead of automated. This will keep you needlessly busy (so you have a good reason not to do anything new and risky) and make you indispensable in the day-to-day operation. More JobSecurity.
• Don't document anything.
• If required by your boss to document something, make sure your documentation is as obfuscated as possible.
• Write the documentation in some tool that is likely to be inconvenient for anyone else to use.

---

Defective and financially poor are often not the same thing. Manipulative slimeballs often go far.

Then perhaps we should add the "Seven Habits of Financially Poor Programmers"

• Hordes doughnuts at morning meetings and takes home doggy bags from lunch time meetings.
• Wears the same worn out blue jeans to work each day.

Uh, that's just "grunge slacker" culture.

---

Some of these are questionable, or at least questionably worded. For example, some truly impressive software systems have been written by individuals working `alone', any programmer fully competent in a language *could* play the job security game if they chose to, etc. Clearly this list was not meant to imply if you do any of these things, you are defective; it seems to me the thinking is a bit muddy though.

Memo to self. Please add this to the list of SevenHabitsOfHighlyDefectiveProgrammers

• Takes things way too seriously and can't appreciate a joke.

Jokes should contain humour; this one needs a *lot* of work.

Parodies are effective because you take the framework of another methodology, and reverse the items, like so:

From Independence to Dependence:

1. Be Reactive Even the most well-known issue should always be a surprise, and ideally an emergency.

2. Start Everything, Finish Nothing Develop anything and everything you alone think is a good idea. Pursue all possible angles concurrently but avoid ever making actual decisions. Have several ways of doing the same thing, then develop some more. Change your focus from day-to-day or even hour-to-hour. The more half-finished code you can write riddled with TODO, the better. KLOC is king!

3. Put First Things Last Develop a truly-shocking set of misplaced priorities, in your work and home life. Leave the really hard, awkward and important stuff right until the last possible moment or ignore it completely. Blame-storm, conduct audits and have a meeting every time there is a Production issue - the fix can wait.

From Interdependence to Independence:

4. Think Zero-Sum Two men enter, one man leaves! Anyone else's successes are your failures. Only quitters and losers ever compromise. Take no prisoners!You're always right, after all.

5. Seek Always To Impose Everyone else must benefit from your wisdom. Continually tell them all how it needs to be done because you know best. Don't bother trying to understand or be understood. Make the other person do all the work. If I didn't do it, it must be wrong, and I can prove it!

6. Compartmentalize! No code or method ever applies to any other system, so re-factoring is ridiculous. In addition, you are a visionary, whose genius goes far beyond the comprehension of mere mortals. Everything truly important belongs in your head - they wouldn't get it anyway. Make sure none of the parts fit properly together but if they must, ensure no-one else but you understands how or why. Build a group of individuals, not a team.

Continuous Status Quo:

7. Shoulder To The Wheel Never learn anything, ever, for any reason. You obviously don't make mistakes. Avoid change. The laziness of others is the most common cause of failure - they need to do more of the same... only harder!

---

This list (aimed at EmbeddedSystems) is from the paper The Seven Habits of Highly Defective Developers by JackGanssle (http://www.ganssle.com/articles/7habits.htm)

1. Overpromise
2. Defer Hardware Issues
3. Ignore Real Time
4. Glorify Globals
5. Discourage Understanding
6. Neglect Standards
7. Abandon Discipline

---

CategoryJoke