Developer Archetypes

I’ve been thinking a lot about software developer archetypes recently. The way I see it, there are 3. I call them the trailblazer, the artist, and the engineer.

The trailblazer just wants to see something work. They don’t sweat the details. Getting something on the screen makes them happy, and visible progress in turn makes marketing happy. Trailblazers are happy to glue together libraries. They are the most likely to enjoy agentic workflows. If AI generates what appears to be a working system, that’s perfect - the customer asked for X, and this fits the shape of X.

The artist is the exact opposite. They sweat every detail. These tend to be backend folks, as frontends aren’t what appeals to them - an elegant system is. They love the craft of coding for its own sake. Artists can burn a full day on API design. They probably care less about the schedule then they should. However, when they build systems you can count on them to be rock solid.

The engineer cares about the process. They will make sure you are following the necessary standards and regulations. Engineers sweat the requirements and the schedule. They are rule followers, so they will attempt to design up front and build a well tested system. However, they are also pragmatic. They will time-box initiatives, and are willing to accept some technical debt to cross the finish line. This happy medium makes them the most likely of the 3 to be a productive manager.

None of these archetypes are inherently better than the other. A large organization will need all 3 to succeed. The goal of people management is to allocate them where they belong.

You want to allocate your engineers to positions where they can manage stakeholders and build the core of individual products.

You want to allocate your artists to organization-wide middleware, libraries, and services.

You want to allocate your trailblazers to feature development - the leaf code that customers want, but other developers don’t need to build on.

People managers fail when they mis-allocate. When they see a trailblazer create many lines of code and put them on libraries. When they see how meticulous an artist is and assumes that passion translates to people management. When they see an engineers flexibility but constrain them to a box of just writing tests.