I’ve long held the belief that having the right mix of people in a development team is essential to that team being able to turn out good code. I’ve seen first hand the problems that occur if you have a dev team that consists of solely academics – nothing ever gets done because there is always another academic issue to solve, and the converse problems if you have a team full of people who think they are superstars – normally they aren’t and the ego clashes again prevent any real work ever getting done However recently I came across a paper (via the blog assertTrue) that tried to breakdown developers into 3 distinct types. The 3 classifications are, by the very fact that there are only 3 of them, simplistic, but do cover a fair chunk of developers that I have worked with over the years. They are as follows:
THE SYSTEMATIC DEVELOPER: Writes code defensively. Does everything he or she can to protect code from unstable and untrustworthy processes running in parallel with their code. Develops a deep understanding of a technology before using it. Prides himself or herself on building elegant solutions. THE PRAGMATIC DEVELOPER: Writes code methodically. Develops sufficient understanding of a technology to enable competent use of it. Prides himself or herself on building robust applications. THE OPPORTUNISTIC DEVELOPER: Writes code in an exploratory fashion. Develops a sufficient understanding of a technology to understand how it can solve a business problem. Prides himself/herself on solving business problems.
Now as I said above I strongly feel that a mix of development styles makes a development team much stronger, and looking at our current team and trying to fit them into the three classifications shows that we have a nice mix of all three. Personally I fall strongly into the Opportunistic box, which makes for rapid development, but also leads to situations where somebody says “What happens if I do this” and I go, “You know what, that’s a very good question”. However some other members of the team are much more in the Pragmatic box, and are capable of taking the work that I have produced and tightening it up to produce a much more repeatable product. Which leads to the other thing that makes a strong development team, you have to leave your ego at the door (something I find difficult sometimes). You have to realise that if you have someone who you have hired to be the code optimisation guy, then you have to let him do his job and actually optimise the code, not build little walls around your work going, its mine I tell you. Fortunately being busy soon sorts out all those problems, hard to keep the code you worked on under your control if you have 50 other things that you are supposed to be doing as well.