Five Kinds of Programmers

I recently had a conversation with one of the long-time programmers on Pirates that got me thinking about how I think about programmers. Over the course of my career I’ve run into several archetypes of professional programmers. I thought it might be interesting to formalize my thinking on the subject, and this is the result.

The Researcher

These programmers are more scientist than engineer. If your organization has a research lab, it is probably stocked with Researchers. Since academia is just one giant lab, it is almost entire filled with Researchers.

The Researcher loves to find solutions to problems that are poorly understood. They are on the bleeding edge of their technological specialty. If there are no papers out there that explain how to do something they will write one.

One downside of the Researcher is that there are so many interesting problems out there that need solving that they have trouble actually finishing any solution before they move on to the next thing. When you can get these guys to check in some code it’s usually great, but it takes them far longer than it would take other kinds of programmers to actually implement anything. They are also the most likely archetype to suffer from Not Invented Here Syndrome.

The Explorer

Like the Researcher, the Explorer is unafraid of the poorly defined dark corners of technology. The key difference is that when the Explorer delves those depths it is to get things done, not for the joy of the exploration itself.

When you have a really thorny problem that you don’t know how to solve, this is the programmer you give it to. Explorers will dig into unfamiliar code-bases and problem domains with a shocking level of energy. These programmers are by far the quickest learners, and are a great resource for other programmers who are trying come behind them into new territory.

The downside of Explorers is that their single-minded practicality can make their code a little sloppy. These programmers dedicate a lot more time to putting their current task behind them than they do to writing code they would want to maintain years down the road. This doesn’t mean that the code won’t work, but that if an extra #include or circular dependency will save an hour the Explorer is always tempted to cut that corner.

The Craftsman

The highest quality code in your code-base was probably written by a Craftsman. Your QA department loves Craftsmen. They value the quality of their work above all else.

When a new system just has to work, you give it to a Craftsman. They will do a great job coding it, and then test it until it is perfect. Craftsmen are absolutely the best programmers when it comes to handling exceptional conditions and corner cases. In my experience Craftsmen also excel at writing maintainable code because they know that they’re going to have to come back to it someday.

Unfortunately all that quality comes at a price. The Craftsmen on your team are the slowest programmers you have. When they estimate tasks they generate the most accurate estimates, but also the biggest. (Partly because they always include the debugging time that everyone else hopes won’t be necessary.) Their emphasis on quality and reliability also means that Craftsmen are terrified of unfamiliar parts of the code-base or poorly defined problems.

The Activist

You know that guy on your team who is pushing Test-Driven Development, is constantly refactoring code, and actually uses the names of design patterns? That guy is your Activist. They are the driving force for architectural and process improvements on your team.

Activists want the code quality in your project to be as high as it can be. They give tough code reviews, and even tougher design reviews, but that’s a good thing. Every time someone on the team listens to the Activist, they are improving as a programmer.

On the other hand, their ceaseless pursuit of perfect code hurts the productivity of the Activist. Quick hacks are physically painful to them, even when that is exactly what the situation calls for. Paradoxically, they also often introduce bugs with their refactoring that never would have come up otherwise. (On the plus side, the refactoring makes fixing that bug far easier.)

The Workhorse

In their various ways, all of the programmers above are sacrificing some of their capacity to their particular quirks. Workhorse programmers don’t do that. They are in a single-minded pursuit of adding as much to the system as possible, and as a result end up owning vast chunks of the code-base.

If you were count lines of code per programmer, the Workhorses would come out ahead. (That’s assuming you don’t count generated code from the Activists.) Sheer output is the domain of these kind of programmers. If you have a few great Workhorses on your team you will be able to do things that other teams only dream of.

The dark flip side of what a great workhorse can accomplish is that a bad one will do absurd amounts of damage to your code-base. Workhorses don’t have any significant dedication to quality that allows them to avoid doing bad things. Sometimes make up for this by having enough time to build the system two or three times in the time that a Craftsman would build it once, but that’s always painful. A single bad Workhorse can do enough damage to negate the positive effect of one or two other programmers.

What kind of programmer are you?

You will notice that none of these archetypes are particularly bad or particularly good. There can be good or bad programmers of any archetype. All the teams I’ve ever been on have had a mix of archetypes. For that matter, very few programmers could be assigned to one archetype.

Personally, I think I’m mostly a Workhorse with a little bit of Activist and Explorer mixed in. I am put to shame by the ability of the some of the programmers around me to suss out how to do some radical new thing. I’m not hard-core enough about process or code quality to keep up with the Activists on the team. The one way I compete is on quantity, and most of that code is fortunately good enough to not doom any projects I’ve been on up to this point.

What about you? Where would you fit in this taxonomy? Do you recognize any programmers you know?


17 Responses to “Five Kinds of Programmers”

  1. Darius K. commented on :

    Heh, I am definitely an explorer (although calling myself a programmer is probably a disservice to programmers). Jeff is very clearly a 50/50 craftsman/activist!

  2. Drealmer said on :

    Nice article! I think I fall into the 50/50 craftsman/activist category, or at least I do my best to belong in there :)

  3. Peter Freese wrote on :

    I’m not sure if this fits into one of your five types (perhaps Researcher or Craftsman) but it feels distinct to me.

    The Architect

    The Architect is the programmer who wants to be able to hold all the code for the entire project in his head. He is made uneasy by and distrustful of parts of the system that are unknown to him. The Architect tends to see weaknesses and bugs in components before they arise, which can make him unpopular among Workhorse programmers. He tends to think about systems abstractly, and can get bogged down when required to actually implement a particular system, usually because he’s too involved in thinking about how it interfaces with everything else. Architects can be invaluable assets to a project, but they can become frustrated if required to produce a large volume of code.

  4. ejengstrom wrote on :


    That’s a great break down of personalities and outcomes at work. 22 years in IT and I concur with each of your classifications.

    People may laugh at this framework you’ve developed and trivialize it to some degree, but there is a reason why these types of filters and measures exist – effective management.

    If you can’t understand and balance tasks to the proper resource you’re toast! (and your products suck)

    In my last salaried position (I run my own company now) I was run ragged by just under a hundred technology people for a financial trading company. I managed the whole startup technology aspect, so design, operations, development, quality, and external partnerships and vendors and as a fairly experienced senior manager at that point I thought all the gimmicks about personalities and (don’t get me started on) “emotional intelligence” were a load of hogwash… Until I nearly fired “Bob”.

    I hand picked and built the organization over the period of a year and one of the real interview “go-getters” named “Bob” just wasn’t working out.

    “Bob” was originally hired to be the gatekeeper of all code and deliveries from the development team and do environment preparation and installations. He did this well in his first few months but as we built beyond substrate levels, his original goal lessened as we automated him out of his role. I didn’t get this right away of course, and as a senior qualified quality engineer I left him to his own devices with his own areas of responsibilities.

    Since I practice the old skool style of management I call “Management by Walking Around”, every time I passed by “Bob”‘s cubicle, he was shopping, or playing a game. Working 15 hour days myself, I started to resent this and quietly went about talking to his direct manager (the QA equivalent of “Activist”, a 4’11″ lady with f’in laserbeams in her head).

    I took this very personally of course, since I had so many hard working people on that team. One day I went for a coffee with a biochemist I stole from a local pharma company (and my best employee – ever, I mean ever). I started probing around on his feelings about “Bob”, would or did he resent the lack of output coming from him. As this kid was a junior type, perhaps he’d want “Bob”‘s role when I finally canned the guy’s lazy butt.

    He was horrified, never having managed anything more than a petri dish before, I wasn’t inclined at first to ask him for leadership advice, but here ya go:

    “Bob’s, the core of the team! He’s hard working, he’s funny, he’s always at work. (Blah blah…) You fire him, we’ll lose all the morale in the testing team!” I think I dropped my double latte on hearing this, I certainly was shocked.

    It ended up that “Bob” was a hyperactive Workhorse. He was so set on completing his objectives and getting the job done, he was often done long before anyone else had finished their workload, even though we did a pretty good job on the gannt and white board of sharing work loads. This star employee of mine gave me really good advice; he instructed me to give a list of tasks to “Bob”. Small, sometimes meaningless tasks. Repetitive tasks (I was all about repeatable, reusable processes anyway and automating redundancy) that no one else wanted to do, “Bob” ended up doing quickly, efficiently and without complaint. He was simply running out of work to do and was always willing to do more. He ended up being the go to guy for all the junior people and neither his manager or I knew this.

    We eventually achieved a high maturity and capability model based on weekly releases. It wouldn’t have been possible without giving the Workhorse “Bob” a lot of little things to succeed at (and do every day). As a Craftsman myself, I was loathe to saddle any one person with a bulk of repetitive, non-challenging, uncreative work. I had long since believed that monotonous repetition was bad for quality and automated 90% of the mundane work we had to perform as a team. “Bob” ended up delivering the other 10% regularly, quickly and efficiently. I really hadn’t, even after all the years and projects I had worked on, thought about what makes other people tick. Your article shows you have a strong grasp on that in terms of your work place. Huzzah!

    I had to go through a period of observation and evaluation and have to say that this lesson was the single most important one I’ve had in my management career. It’s not enough to simply understand people, but more about understanding how they fit into a team and what they need to be at their best and when best to assign them to a specific task or goal. The balance of that team is the manager’s primary challenge. The forward momentum of that team, which is hard to maintain without understanding the talents and needs of the team, is the primary job of the manager.

    The aggregate results of a team, or even a task within a unit of labor can be more effectively managed and the outcome more reasonably assured. Once the cares and needs of the team are managed, considering any particular project task to need a dash of Workhorse, with a touch of Activitist and a couple of ripe Craftsmen, a pair of fresh Researchers and a half to one and a half Explorers and you’re good to go.

    I really enjoyed your entry, I think it deserves mention elsewhere.



  5. ejengstrom commented on :


    On further late night reflection:

    Have you ever had to deal with competition amongst these archetypes?

    I’ve had a lot of trouble with workhorses and have had to constantly reign them in for the exact downside you mention in your article.

    How have you managed to not FIRE all your Researchers? I hate these guys.

    Love to read more.


  6. Joe said on :

    Peter: I almost put an Architect archetype (say that 5 times fast) in, but realized I couldn’t actually think of a person who really fit that role in my own experience. Wouldn’t there be a lot of overlap between Activist and Architect (maybe with the fear of the unknown from Craftsman thrown in?)

  7. Joe thought on :

    Ejengstrom: Heh. Of all these, Researchers have the hardest time fitting into a product team. Sometimes there are problems that no one else can solve, though, and you need some of these guys.

  8. Peter Freese said on :

    Maybe I’m misconstruing your definition of the Activist. What came to mind when I read your description was the guys who wanted to use template meta-programming when everyone else was still coming up to speed on the STL. I see these guys as bleeding edge afficianados – they’re the ones most likely to have the very latest version of the compiler that they built from the source code they downloaded last night.

  9. Joe wrote on :

    No, that’s definitely an Activist.

    I guess the key difference is that the Activist sees the system as a collection of buzzwords and whizzy technology where the Architect sees it as a coherent whole. I’ve known a few people who did this, but none of them had any fear whatsoever of unfamiliar areas of code. They understood the whole structure well enough to have a good idea what a new chunk of code was going to do. What the DID hate was somebody messing with the architecture without their consent.

  10. Luke said on :

    Well, clearly I’m an Activist (a.k.a. “refactoring/TDD grognard”), though I don’t know about the “buzzwords and whizzy technology” angle you just mentioned (though I’ll confess to having engaged in some template metaprogramming and loved it). I see some familiarity in “Craftsman” as well, so maybe I’ve got an Activist sun sign with a rising moon in Craftsman (har).

    As far as collaboration with different types of programmers, the person in my career I had the hardest time getting along with was a definite Explorer and we butted heads constantly; I hated dealing with his code, and we couldn’t agree on anything.

  11. ejengstrom said on :


    I’m a Craftsman (Activist/Workhorse) if we want to get into astrological terms. I constantly beat myself senseless trying to do quality work while incorporating FORWARD and if I do it poorly, start all over again. I’m such a terrible programmer, I would fire myself, fortunately I’m the boss and can look the other way.


    Does GreyNoten blog anywhere that you know of?


  12. Jeff replied on :

    Darius says I’m 50/50 craftsman/activist, and he’s right about the activist part, but I find that I switch a lot depending on what I’m doing or what’s needed. I find at orbus, I definitely do that 50/50, but at Bethesda I definitely did a lot of explorer programming, and in college (obviously) I did a lot of researcher programming. I find the only one that I don’t do (and I find doesn’t really work well with me) is the workhorse. They may be fast, but in me experience you always end up paying for that speed. They’re awesome prototypers, but can’t be relied on in the long run.

  13. BugHunter commented on :

    This is a terrific explanation. I’m curious if anyone else notices consistent relationship issues between certain groups.

    For instance, I’ve never met an activist that can get along with a researcher…and vice versa.

    I’d like to see a relationship model similar to the bartle types or something.

  14. jonathan said on :

    god! I’m a reseacher… can i get cured? hehehe

    besides everyone having something of this 6 (including the architect) i’m pretty sure i’m more of a reasearcher with a little activism in my hearth cause i like to follow the stadarts.

    my actual job somethimes requires that i “incarnate” the five kinds, as many programmers on small statup companies do

    … but i simplily love to look to new solutions and different ways to the problems (and to the solutions ;) … sometimes i’m in the shower and when i reallyse i’m wondering about semantincs and search engines…

    today this character plays a vital role in my career and in my company.

  15. BDKR commented on :

    This was a fantastic read for me. Seriously. Having just been canned for not being fast enough, I decided that after 10 years in IT it was time to evaluate exactly what type of programmer I am.

    So what am I? I can easily say that I am all of the first three you mentioned. Researcher, Explorer, and Craftsman. And exactly which depends on what I’m doing at the time.

    Truth be told, I pretty much knew this all along (and come to think of it, I’m frackin’ proud of it!) and have long wondered how much of a liability this was going to be. It’s feeling more and more like a liability all the time and I am really wondering exactly how to deal with it.

    And hence the reason I ended up here.

    Do I really want to change? No actually. I just may need to learn how to be a little workhorse-ish from time to time.

    Great write Joe!

  16. rooterbob wrote on :

    The correct expression for what the workhorse does is to create negative productivity. There is such a thing as programming economy that I have invented to quantify many of these situations. You have negative and positive productivity. Your profit or loss is positive productivity minus negative productivity where both are positive integers. In the worse case you have a loss. Generally, the workhorse have very high positive but also high negative so high revenue and little profit. Being able to put it in these terms really helps upper management get a perspective on it.

    I would like to introduce you to a variant similar to the workhorse. This is the bloater. In a way, a subset of the workhorse and one of the worse kinds. The bloater like the work horse produces vast amounts of code of generally low quality. Such a programmer might take a hundred lines to do what a decent programmer can do in ten lines while making it more readable and spaced out, faster, less buggy, etc.

    It is important not to confuse the bloater with a stupid or lazy programmer. While the bloater may lack some skill the bloat cannot be merely explained by this. The bloater’s code will confound you when you try to work out the motives of their actions in code. You will not think were they lazy or stupid but in stead were they trying to sabotage the project, thought they were being paid by line, thought their productivity would be measured in lines of code, etc?

    Programmers of this type are skilled masters of anti-patterns that lead to bloat. Denormalisation, inconsistency, unrolling, Rosetta comments, copy and paste, etc. Instead of DRY, it is as though they follow a philosophy of Write Everything Twice.

    What the bloater does can be compared to money fraud. To a decent programmer it is immediately apparent that all the bloater has done is to greatly increase inflation. To a management that is code illiterate however, it will look as though the bloater has done a great deal of complex work.

  17. Jack R replied on :

    I’m craftsman through & through. When I worked at Xerox, a teammate, who could always envision the entire thing, and write the “widest” code, said to me, “I’m a framer, and you’re a cabinet maker. I knock out the frame, put up walls, throw down cabling. You hone the cabinetry, do the built-in entertainment center, the game room, the 6-sided colored windows, etc. So true.

    When I was in video games, I did, for example, the graphic engine- lighting effects, shadowing, and so on. The fun math stuff: based on matrices, cross products, ray-casting, etc. And it took me a long time to bring it in, but when I did, it had some wow to it.

    Places that value speed over quality are hell for us. On large projects, we’re nothing without framers/explorers.

Leave a Reply