When you compare artists, it's very easy to see their differences. Even non-artists have no trouble distinguishing between major categories like painters, actors, and musicians. No one would approach a sculptor and ask them to sing at their wedding reception. When it comes to software engineers, however, the distinctions are harder for people to see. It's fairly obvious why, and it's not really a problem, so who cares? Well actually, you do. Or, rather, you should.
As a manager of a software engineering team, you need to understand and learn to recognize the differences. Of course there are the outward things--the learned skills. Some people are more proficient than others in certain technologies, but that's easy to spot. I'm talking about something deeper. Their motivations. The way their minds work. Why are they a software engineer? What do they love about it?
Sure, a sculptor is more proficient with a chisel than a guitarist is, but that's not really what makes the sculptor a good sculptor. In the same way, technological proficiency is certainly an important factor, but if that's the only thing that you know about your engineers, then you are missing out on a great deal of insight. When you need a portrait painted of one of your children, you don't start by looking through a crowd and asking "who is good with a paintbrush". The proficiency with the tool is not of primary importance. In the same way, a good manager doesn't start by looking for a developer that's proficient in a particular technology. A good manager starts by looking for the right kind of developer for the project. The technology is secondary.
In the next series of articles, I'm going to do my best to describe the most common personality-types among software engineers. I will describe what they are like, how to identify them, as well as their typical strengths and weaknesses. It will by no means be a complete list. I'm sure that some developers will feel under-represented by my descriptions. I will likely add more personality-type articles as I think of them or as they are brought to my attention.
It goes without saying, but I'll say it anyway... Since everyone is different, sometimes the lines may be a little blurred. Not everyone will fit into one neat little category. My intention is not to create a scientific method for definitively classifying developers. My goal is to help you to see past the surface proficiencies and to start recognizing the underlying differences. It's more of an art than a science, but once you are able to recognize the differences, you will stand a much better chance at assigning developers to the tasks that suit them best. Doing so will lead to faster development times, more stable products, happier developers, and, consequently, better team-moral.