Developers are a self-reflective lot. On any given day, /r/programming will boast a handful of new posts pontificating on "what makes a 'good' developer" or the "X types of programmers". So I know the topic space is over-tread...but I don't care. As a virtual rite of passage of a developer-blogger, I feel duty bound to submit my own classification of developers. Here goes...
After 15 years in industry, I've come to realize that the most defining quality of a developer is his source of motivation. It undergirds all of his decisions and interactions. It predicts what kind of code he'll write, what technologies he'll prefer, and even how he'll succeed on a given assignment. And it's often quite easy to peg for any given developer after just a few days of working with him or her.
There are three and only three sources of motivation (so say I!), and they can be visualized as a radar chart, like so:
At each vertex is the motivational force, and right smack in the center is the absence of any motivation at all (i.e. "don't give a crap"). You know who I'm talking about. Anyway, each developer has his or her own unique "shape", where the greater the area of his triangle, the more motivation. For instance, here's how I'd draw me, plus or minus:
Although a developer might be driven in some portion by all motivators, there is always one force that is most dominant. I'll explain each:
Business Motivated: Driven most by a desire to get things done for the customer, these developers are often the "favorites" of the business folks because they deliver functionality quickly without many questions. Need a new feature at the last minute? No problem. These guys have a can-do attitude (even when a little push-back might benefit the integrity of the system's architecture). In terms of code, they think more concretely, and aren't always the best at creating abstractions that support re-use or other non-functional goals. They just want to get 'er done and see a functional product. On every project, a few of these developers are crucial. They get things done, and don't make waves.
Technology Motivated: These developers love learning new things for its own sake. They're always eager to find the newest framework, language, or methodology and will take every opportunity to try it out on their current project. The library was just released last week and was written by 1 guy over a weekend? Let's give it a shot! These guys know all the trending technologies, and have probably dabbled with them over nights and weekends. They love to try things out, and understand which tools work best. On a greenfield project they thrive, but when the field turns "brown" and new code turns into legacy, they look for greener pastures, or possibly worse, look for ways to shoe-horn in technology even if it's to the detriment of the system.
Problem Motivated: Hard problems excite these developers, independent of whether what technology is employed or even it adds value for the business. It's all about the puzzle. Coming up with an elegant, clever, or quality solution is the victory. If it helps the business in the process, great (and often it does). These developers are interested in new technology insofar as it presents better ways of solving problems, but not so much interested in dabbling just to know what's out there. While their solutions are solid, sometimes the details slip.
Now of course this isn't the "right" classification system, but I've found that it is useful to think about my fellow developers as one of these 3 (or actually 4) types - the get 'er done's, the technologists, the problem solvers, and the don't-give-a-craps. An awareness of each of our differences is helpful. I know that each will have certain strengths and weaknesses, and will contribute to the project in different ways, and in different parts of the life-cycle.
For instance, when starting a new project, we look for the technologists to help inform us about what framework or library on the horizon could be most useful. Or when the team gets stuck in the weeds of over-analysis, we rely on the get 'er done's to just dig in and start delivering working code. And when a problem is particularly thorny and needs to be thought through, we look for the problem solvers to step back and find a way out of the swamp.
In other words, everyone contributes in a different way. Understanding people's underlying sources of motivation can help you get the most out of your team. It can also make you cognizant of keeping a team in balance - too many of any particular type is never healthy, and in fact can spell disaster for your project. Whereas a team of all technologists or problem solvers might obsess about the infrastructure and never deliver value to the business, a team of all get 'er done's might more quickly create a big ball of mud.
Anyway, let me know what you think! What type of developer are you? And does it matter?
