To me there are four distinct type of developers. There are the day-job developers, the lazy developers, the average developer, the programatic developers, and the passionate developers. These are the main types by my definitions.
The day-job developers are the ones that don’t care about what they do. They might not even like what they do. They still do it. They might reason that it’s a decently paid job, with good benefits and a high degree of freedom. At least that’s the case for most of the people employeed within the IT industry according to one of swedens IT newspapers (see link (in swedish)). This kind of developer never learns anything not shoved down his throat (in one way or another). Either by necessity to complete the task assigned or when attending some course he was sent to by his employeers (because he would never actively attend a course – unless perhaps for the chance to get up later in the morning and get home earlier in the afternoon). Even when it comes to completing a task this type more often then not asks someone else how to do it, then does it, instead of finding out for himself.
The lazy developers don’t do anything they don’t need to. What makes them any better then the day-job developers is that they actually have an interest in what they do. Not enough to make them work to get do anything outside the box (ie their assignment) but they still enjoy going to work and like what they do. They will happily attend courses, and even look ones up themselves, but they still don’t put in any effort outside of their job. It’s not that they are not interested enough, it’s just that they can’t get over the threshold of knowing how to start. When assigned a task they can’t handle the lazy-developer will try to find out themselves, but it will probably take them awhile since they are not accustomed to seeking out information, and they don’t know enough to really know where to look.
The average developer understands that he must evelove to stay attractive. He must learn as the industry changes. As such he will happily attend courses, seminars and read articles. He might not spend all that much time doing it outside work hours, but he will try. If there is, say, a usergroup, he will attend to learn more – because there will be someone else there to feed him information. As such he knows a bit about the industry trends, enough to know which articles and/or books to read, for example on the subway to and from work (maybe not as a daily routine, but when he finds something new and interesting). When faced with a task that he is unaccustomed to he will search for guidance and help in an effective maner, but there is still many areas with which he is unfamiliar. The average developer is more often then not specialized, and can’t go outside the frame too much, at least not without quite a bit of work – but he is not afraid or unwilling to take on new things.
The pragmatic developer is experienced. He has done the things he has read about or attended a course on. He sets himself apart from the average developer by having “been there, done that”. That doesn’t have to mean that he has necessarily done real world projects on all the topics he knows. Some he might only know in theory, but that’s enough to make him proficient in finding solutions to new problems in new areas. His knowledge spans a wider area then the average developers since he tries to learn more and new things as much as possible (see my previous post on prioritizing). More likely than not he has an area within which he is specialized, but he has a general understanding of a much wider area and are comfortable discussing most of the terms and concepts found within the industry.
Now the previous type sounds like a pretty decent one. One that I’d like to work with any day. What more could you wish for? I don’t consider there to be a category such as a complete developer, ie someone who is the pragmatic programmer and on top of that has the depth of knowledge that matches the specialists level on all or most of the topics available within the industry. There are a few people I would consider putting on that level, and I envy them, but they are too few to form a category, they are more of an exception that confirms a rule then anything else.
So the passionate programmer then? What sets him apart from the programmtic programmer? I’d say two things. The first is his strong desire too always learn more. He may still have priorities that contain other things, but he is passionate about learning more. He not only understands that he needs to learn more to stay ahead, he does it because he enoys it. The second thing is that he doesn’t do it all for himself, or the project goal he’s currently pursuing. He likes to share. He does his best to make others learn what he knows, to spread the word. This doesn’t necesarrily mean he’s a trainer, or organizing usergroups for that matter. It might be in a smaller scale. Not all passionate programmers are forward enough, or comfortable to be presenting to large groups. But the desire to share is there.
Now granted there are more to it then this, more aspects. Like knowledge about business, entrepreneurs, people with new ideas, carisma, naturally outgoing people as opposed to naturally quiet or nervous people. People that really stand up for the team as opposed to those who don’t. Ok, so where does the arcitect fit in? Etc… But the above categorization is one way to mirror the differences I see in how developers work in regards to their competency. I decided in part to write these posts after listening to an MSDN podcast (in swedish) featuring Patrik Löwendahl and a conversation we had with Johan Lindfors. There is also an article on the swedish forum Pellesoft written by Johan Normén here. It’s an interesting topic – this is how I see it.
1 thought on “Pragmatic or passionate? – part 2”
Nice article.I like the description of the Passionate Programmer. With the Pragmatic programmer i would add that this type knows the trade-offs and will avoid a topic far outside his/her core specialties if there is a more pressing need to pick up some extra skills in the main areas. After all, there are far too many technologies and skills to be developed and one person cannot try to know them all and possess all the skills. Spreading yourself too thin is risky.