Programmer Classifications by Quadrant
Lately I've been spending a bit of time trying to find and hire programmers (due to having to spend time removing programmers). Hiring programmers is never an easy task as there are really good programmers out there and prying them away from their existing jobs is hard work. How to hire has been written on extensively.

But I've been thinking about personality types lately and which ones fit into projects and make good developers. Many years ago my brother, who is a WWII history guy, told me about Kurt von Hammerstein-Equord's method for classifying his officers. I don't usually take the advice of nazi generals, but this method seems to have resonated with me and every time I tell someone else about it they seem to smile and draw some value.

Basically he had four defining characteristics: smart, stupid, lazy, industrious: "I divide my officers into four classes; the clever, the lazy, the industrious, and the stupid. Most often two of these qualities come together. The officers who are clever and industrious are fitted for the highest staff appointments. Those who are stupid and lazy make up around 90% of every army in the world, and they can be used for routine work. The man who is clever and lazy however is for the very highest command; he has the temperament and nerves to deal with all situations. But whoever is stupid and industrious is a menace and must be removed immediately!"

I think this applies to programmers pretty closely. Regard the quadrant below:intelligent, stupid, lazy, industrious

Programmers who are stupid and lazy are all over the place. In large projects there is room for these types as there are always jobs for them to do. More importantly, they aren't dangerous as they'll be wasting time reading 4chan instead of injecting bugs. These are the types that are the reason why project managers micromanage "What do you mean you spent 8 hours editing a label on the welcome screen?"

Next are the smart and industrious programmers. I thought these were the prized employees, the ones you really want. Smart and hard-working is a good thing right? Yes, that's right these are the guys and ladies who will identify the problem and work hard until it's complete. Boy scouts of the programming world.

Closely related are the smart and lazy programmers. These are the guys who really waste time and mess around, but are able to re-use someone else's API to do the work better than spending 20 hours writing it from scratch. The trick here though is to make that they aren't too lazy. I mean you want them coming into work and all.

Finally, you have the stupid and industrious programmers. These are dangerous. These will ruin your project and make you miss dates. "I spent all week-end re-writing the login module so it will only use digital certificates instead of userid and password." or "I wrote a wonder configurator to set the properties in the project. But the configurator only works on a JVM we don't use and there's no other way to configure the project." Stuff like this will make the smart/lazies, stupid/lazies and smart/industriouses work overtime to get back to zero.

Update 2009.06.04 2154EDT: As pointed out below by thecodist, Hammerstein-Equord, although in the Nazi army, was actually against the Nazi party, hated Hitler and spent most of his later life trying to stop the Nazis.

Labels: , , ,

Actually the general was an ardent anti-Nazi and active in trying to kill Hitler. But that classification system makes a lot of sense to me. I see too many programmers who make this complicated instead of being lazy and clever finding a simple way.
the stupid/industrious programmers are the ones that have "net negative productivity." Despite all the code that they write, their overall effect on the project timelines/cost is worse than if they wrote no code at all.

The most dangerous ones are the ones that don't seem to affect project timelines, but the productivity of the company as a whole. They seem to get their work done on a project, but they busily create subtle bugs that don't appear they are in production, where it is very costly to fix or work around them (or actually cost the company revenue in lost opportunities).
I find the positive/negative attribute pairing in this method to be too disruptive. It's too limiting to work for most people.

If you put people into the right circumstance, mostly, they'll get a "reasonable" amount of work done. It's just of matter of finding where people fit.

If you stick someone who wants to think into a job that doesn't require it, they'll fail. If you stick someone who likes to dive into new things, into a job were they need to attend to the same old details, they'll also fail.

The best teams/organizations realize that they need a wide range of different personalities and talents, well deployed, in order to be successful. They also realize that slotting people into tight vertical niches leads to poor morale (even if you get it right initially, people change).

Hire people because they're nice and because they're energetic, then give them the space to find out how they can best help to keep things moving forward. Be prepared to fire a few.
Wonder where to classify the group of programmers who want to spend a week or two at the inception of a project to come up with a cute name, preferably some acronym with a variety of potential interpretations?
Stupid and industrious?
Post a Comment

<< Home
Technical and personal notes from Brian Lee, technologist/enterprise architect/software developer/soa guy.

February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / May 2007 / June 2007 / August 2007 / September 2007 / October 2007 / April 2008 / July 2008 / January 2009 / May 2009 / June 2009 /
My Photo
Name: Brian Lee
Location: Atlanta, Georgia, United States


Powered by Blogger