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:
- 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.