In the past few months, I’ve had the opportunity to talk with a lot of organizations. One of the common topics that comes up is technical and people leadership. I have some strong opinions and some (likely bad) ideas. But I found myself describing this gradient of career professionalism for software engineers as well as getting feedback that it was interesting.

Now, I don’t know if that is “interesting” as in “that’s nice, I’m glad to move on from this subject” or whether it’s “interesting” in the sense of being thought provoking and worth exploring deeper. So I figured I’d toss it up on a blog post and inflict these thoughts on others.

The Hacker-Programmer-Engineer Gradient

I have a thought that one of the goals for leaders of software engineering teams is to help their staff move away from the Hacker paradigm and deeper into the Engineer paradigm. I’ll unpack these in a bit, but I want to acknowledge that there’s a gradient across these three terms.

Hackers are at the end of one spectrum. As they become more professionally engaged, they’ll move into the Programmer role. Programmers who lose some of that professional zeal can move back into the Hacker role. However, they can be coached and mentored into the Engineer role. Engineers who aren’t properly supported can lose bits of their professionalism and return to the Programmer role.

That’s the movement between these roles in brief. That said, this is a gradient. There aren’t three distinct stages. Rather, I would estimate that most people tend to hover around the middle points of these roles most of the time but could easily be in transitional stages at any given time.

Now, on to the roles.

Hacker

I love Hackers. As a literary trope goes, they can carry a lot of dramatic tension and/or humor. As members of my team, they can often get a lot done very, very quickly.

However, I’ve also seen Hackers get very little done within reasonable time frames.

Similarly, I’ve seen Hackers toss up pristine, poetic, and even poignant code from time to time while also seeing Hackers throw out garbage that barely passed half of the requirements.

These illustrates the defining trait of Hackers. They are highly motivated by their passions and desires. They demonstrate high energy, craft, and motivation when they are tasked with something that they love or feel passionate about. They also can show disdain for tasks that don’t excite them or move their spirits.

For Hackers, the output of their work is highly variable. Similarly, the need for support from technical leaders is highly variable, often exhausting.

Hackers are motivated by emotional investment and the quality of their output reflects how much they’ve fallen in love with the task at hand.

Programmers

I love Programmers. Sure, they are the butt of cliché jokes in a lot of media, but they’re amazing dynamic and interesting people in real life. As members of my team, I find that their output isn’t quite as rapid as I might like but I’m also rarely surprised at how little got done.

Programmers understand that they have a job to do. They may not always like the job, but that isn’t necessary to get them to do it. The work may be a trudge. And I’ll get less creativity (and unit tests) back. But the work will get done.

On the other hand, Programmers aren’t expected to go the extra mile for most tasks. Even if they’re highly motivated out of personal desire to get something done, they also know that there’s just another ticket to pull after this one. The work won’t end and the output is therefore sublimated. Programmers will do better on the things that they like but the bounds between the highs and the lows are much narrower than Hackers.

Programmers are not motivated by personal desire. Rather, they are professionals who will get the job done. Leaders can expect variability in output and enthusiasm, but seldom need to intervene.

Engineers

I love Engineers. That’s a difficult title. The overlap with other engineering professions muddies the definition for software engineers. That said, the Engineers that I’ve worked with demonstrate an internal desire to produce high quality software that withstands scrutiny.

Engineers aren’t motivated by passion. Their internal feelings about a particular project won’t affect their contributions. They give the same effort hether they are fixing a bug, designing the architecture for large systems, or trudging through a tedious manual process.

Engineers are motivated by a commitment to excellence in craft.

As such, even when Engineers have the mindset that they are just doing their jobs, they still engage with a high degree of professionalism and the desire to demonstrate their best work. Small changes are opportunities to perform some code cleanup. Large changes are opportunities to define well-structured APIs that others can easily understand and use. Even if there aren’t opportunities to improve adjacent areas of the codebase, specific code changes will show precision and elegance.

Leaders rarely, if ever, need to intervene with Engineers. Project estimates and timelines are relatively safer with a team of Engineers. Rather, technical leaders are often tasked with removing roadblocks and finding ways to keep Engineers motivated and executing at this high level.

Getting Past Generalizations

I want to acknowledge that this is a huge, hand-wavy abstraction. It doesn’t speak to real world experiences. It’s just a simplified framework for basing expectations and understandings as a jumping off point for better conversations.

At any given moment, an Engineer may behave like a Hacker for any number of reasons. Similarly, someone between the Programmer and Engineer roles may be frustratingly variable on some assignments but absolutely bankable on others.

As a technical leaders, I never assigned anyone on my team to one of these three roles. Instead, I asked myself (and, often, them!) what behaviors were they demonstrating on the projects that we were working on. In moving the conversation away from their person and onto their behaviors, I hoped to avoid assigning them identities.

For example, a person that I was managing was performing Hacker role on my team and came to me asking for a promotion. I realized I could bring some of these aspects into the conversation. I had notes about projects that were performed exceptionally well as well as some that, well, weren’t. By presenting these observations and getting their buy-in that there was variability in execution, we could talk about how to demonstrate more consistent behaviors that were aligned with the rubrics of the role that they wanted.

They were not a hacker. Instead, they were at a stage in their career where they found some things much more interesting to work on than others. Because I could recognize this, I had the opportunity to reflect it back to them and let them understand how they would need to grow in order to meet the company’s expectations.

This individual moved well past the Programmer role and started performing behaviors that often aligned with expectations for Engineers. That said, it was somewhere between the two on the gradient. It was a healthy amount of growth that lead to a promotion that year. But, since I could recognize how motivation was still a factor, I had the insights that I need to spur that next phase of career growth for the individual.

Conclusion

This is just one of many ways that I think about engineering teams and their processes. It’s a generalized means to answer the question of how technical leadership should serve the careers of their staff. My answer is that good technical leaders help their staff move away from Hacker roles and deeply into Engineer roles.

It’s incomplete and certainly doesn’t cover all of the ways that technical leaders can grow their team. But it’s an efficient shorthand to describe how I try to coach my team to their professional goals without resorting to conversations about rubrics. It’s general and it’s simple.

That is, after I’ve taken all this time to describe it…