A "Motivation Model" of developer archetypes

An amazing and empathetic former boss of mine, Scott Blomquist, liked to talk about the different types of developers: Hackers, Engineers and Computer Scientists.

In the 15 years since, I've forgotten the exact qualities that formed these groups (help me out Scott!) but as the years went on, I never forgot the grouping and started to notice patterns of my own.

As an intrinsically-motivated individual, I started paying attention to what seemed to motivate the different developers who fall into these groups.

After a few years of thinking on this, I arrived at the following x/y grid:

Value Expression

It's a given that developers write code. But when we think about an intrinsic value model, I think we can place developers on spectrum from "the code I write is valuable" to "the system created by such code is valuable". Another way to put this: do you enjoy that the code is a tangible expression of a system? Or do you enjoy that the system is proven by some tangible code?

Problem Space

The second criteria is the problem space. All developers are brilliant problem solvers. Some, however, are motivated by a solution that is more local than global and vice-versa.

You've seen this I'm sure – a developer who can't seem to be satisfied by solving the timezone-related issue on invites, without defining a new timezone system for everything.

Conversely there's the developer who breaks work tasks down into such small bite-size portions, that their pull requests always include 5-10 files or functions with laser-precision purposes. simple utilities on their own, but when combined, they solve the problem.

The Archetypes in Summary

Because of this contrived combination of spectrum, we can define 4 archetypes that represent each quadrant.

The Hacker

The hacker gets it done, and knows that its done because its... done. The button works, the payment processes, the game loads. It doesn't always matter how, or whether it can be repeated. But then again, why does that matter? We have the "thing" we needed, and now we can move on to the next thing we need. Without hackers, we'd have nothing that's "cool" – we'd just have a bunch of working, but boring apps. Its up to the hacker to create the "cow paths" that we then pave over with proper roads (and documentation).

The Programmer

The programmer is good. And they know it. We all know it too. Look at that code. Look at those STATIC TYPES. Its SOLID and DRY. Their APIs never overlook CRUD and their teams win at DORA. The programmer got into this field to do just that: write code, and do it well. They take pride in their abstractions and N+1 issues cause physical pain. The programmer has languages they would rather die than touch – and if your life is in danger, you better hope a programmer wrote the code on that life-saving device.

The Engineer

To an engineer, the model of the system is everything. In fact, lets define a domain-specific language to properly map this problem space ! The result: the business, the product, the team and the code – are all one – sharing one language, sharing one glorious purpose, in total alignment. There's nothing more jarring to an engineer than a constraint or requirement that shows up late and out-of-the blue. Psych ! They don't mind at all – they already accounted for those edge cases, and intentionally accounted for a degraded but functional experience, in favor of preserving the golden path.

The Computer Scientist

For the Computer Scientist, development is experimentation. Problems? Solution? These are all simply evidence added to the ongoing dialogue between man and machine. Motivated by knowledge and pushing boundaries, a Computer Scientist gets as much joy discussing an algorithm as implementing it.