Skip to content

Know your developer type

The Magic Pudding

Coming up with a characterization for a developer is often handy for figuring out how to talk with them – both about technology and in marketing. As with all characteristics, you end up with something a little more useful than a paper mache mask, but it at least gives you the baseline to start thinking about how to deal with them. When I still “did something,” as I like to say of my years being a software developer, I’d come across all sorts of folks in person and through the “Internets” and made a fun game of slotting these developers into types. Very few people every fit perfectly into one slot, of course. Below are some of the types I’ve kept coming across, patterns of being, if you will.

There are many things that push a developer to one type or another. This can largely be determined by what they read, and don’t read. To some extent, demographics (age, nationality, gender, income bracket, geography, ethnicity) can be used – but I don’t know the specifics enough to generalize. Though, I do take a certain “becoming an old guy” pleasure in trying to track based on age, rather, family status. While we’d like to think that developers are motivated by being more productive, writing bug free code, and otherwise driven by “pure” engineering principals, that motivation is nuanced. Knowing their archtype(s) helps throw up guides to bump along. Some sample archtypes:

Developers Types

  • Snarky – believes most people are stupid and need to be ignored or coded around. You may have optimistic snarky people who simply deal with the drudgery of programming by being crass. Sarcasm is soma.
  • Optimistic – often smiley, works longer hours, willing to help other people. This is extremely rare, and can be confused with an arrogant-ignorant developer who thinks everything is happy-go-lucky just to get off-shored next week.
  • Lots of talk, little code – spends much time on the labor and process around coding, hoping that the smaller amount of time coding is done effectively by the measure twice cut once ideas. An anecdote: a NASA software developer walks into a his managers office, saying it’s great that they finally committed so much code this week. The manager has a dark look on his face, no, he says, think of all the bugs we’re about to discover.
  • Craftsman – interested in being better at what they do, but often lacks the tools to measure the betterment, or even get a baseline for how bad or good things are. Instead, they try new developer self-help programs (like Agile, etc.) and are always looking for the new thing that will help them be better.
  • Coders – spend most of their time simply coding in, mostly isolation, generating a lot of code. Managers love these types, other developers tend to bad mouth Coders behind their back as (a.) the Coders output amount “ruins the curve,” and, (b.) their code is not always liked by the group.
  • I just work here – just there for a good paying job, rarely works on becoming better but is often very dependable in getting work done, if only by using out of date methods.
  • Legacy – “this is like CICS all over again” is the kind of sentiment you get from these folks. They continually muse that 20 years ago, they were doing the same thing, except in all upper case.
  • Startup-dreamer – works at a “normal” company, but is always trying to start something: a company, an open source project, a service, etc.
  • Process-wonk – for these folks, the problem with software is the lack of discipline and group process. They may seem overly bureaucratic, but their trust is that if the group just got their act together, the code would work better. A negative version of this is Cargo Cult, a favorite derisive-term of developers.
  • The Debugger – whether they like it or not, this person is good at tracking down bugs. They’re often good at doing performance tuning as well.
  • The Baron – a developer who likes to build his own fief, an area of the overall project that no one else understands or can work on. See DBA, network admin, and “security.”
  • Architects – charged with being more technical than manager, they’re expected to “lead technically” and know enough about The Business to guide technical decisions. Having been successful developers, they’re often tasked with keeping that up as well.

(There are no doubt more! Have some to leave in the comments below?)

ISV vs. Corporate Developers

Of note, the distinction between an ISV developer and a corporate developer is even more high-level than the above. Many large ISV’s (Oracle, IBM, SAP, HP, Microsoft) constituency is the corporate developer, not the ISV developer.

ISV developers are even more tricky to market to (that is, get to use your software) as they expect to use very little that isn’t open source, if any at all. The reasons are many, but include: to drive down license costs per distribution, for the malleability of the code (see how many chunks of middleware Twitter has gone through in the past 2 years), and low barriers to entry to using OSS.

Also, many ISV developers are transitioning to mobile and SaaS development which traditional vendors are not necessarily well geared for. That said, the shift to centralized, at-scale deployments (SaaS) provides interesting opportunities among ISVs for these traditional ISVs, and new ones.

(Related, you might like my 2007 talk on Developer Marketing Do’s and Dont’s.)

Disclosure: IBM, SAP, and Microsoft are clients.

Categories: Marketing, Programming.

Comment Feed

11 Responses

  1. You meant maleability, not mailability, right?

    You forgot the type "minimalist": writing as little code as possible, but making sure that code is rock-solid. Not liked by management as never seeming to be doing any work, looking at clouds, etc.

  2. Zounds! It's malleability, with two l's like llamas.

  3. Chris: thanks, as always, for your vigilance!

  4. Agile = "new developer self-help program"? I hope you were just being "Snarky". If that's your definition of Agile, then I think that you may be missing the big picture of Agile.

    Ironman6September 21, 2010 @ 8:08 am
  5. Seems like all your types are negative, surely there are some developers you could stand to be around?

    BryanApril 28, 2011 @ 8:46 am
  6. Bryan: I wouldn't say *all* of those types are negative (some are, of course) – it depends what you want out of your developer. You could see, for example, the "just works here" as someone who's not "in it" enough. In reality, they may deliver solid code that meets the business need and get home in time to see their kids every day. Coders could be seen as putting out crap code, but the other end of that stick is that those who look down on them have too high of standards and delay getting working code out there that helps the company make money, despite the "lack of elegance" that may never be used (i.e. to easily extend some feature of "swap out" the database layer with some fancy O/R mapping layering abstrated to high-heave.). Clearly, "The Baron" is not too good, and the Process Wonk may err on the side of sticking to the old when newer "process" would be more beneficial.

    That defense aside, having done development for 10 years, it's easy for me to be snarky about the field, esp. when it comes to myself and the countless friends I have who, as they've gotten older, have seen development not as a dashing, bold adventure but as a job. Perhaps that's the most cynical take of all, or the most liberating depending on how much you use being a "coder" as part of your identity versus everything else that ends up happening in your life.

  7. Wow, except for the debugger, who doesn’t want to be one, these are all surprisingly negative.

    Rich SalzMay 3, 2011 @ 1:04 pm

Continuing the Discussion

  1. […] my esteemed colleague Coté took another stab at this recently- addressing the psychological aspects of developer types. He came up with this wonderful […]

  2. […] my esteemed colleague Coté took another stab at this recently- addressing the psychological aspects of developer types. He came up with this wonderful […]

  3. […] built. Hey “business people”, you’re not all the same, take the time to understand developers aren’t […]