Two Types of Software Engineers
I recently came across Thorsten Ball’s post about there being two types of software engineers. To paraphrase his thoughts, Type 1 sees system changes as being isolated within that system, whereas Type 2 sees system changes as being inescapably interrelated to other systems.
To illustrate, Type 1 engineers often believe that a change in a human process is sufficient to solve a problem. Type 2 engineers see a change in process as requiring adjustments from humans who are their own complex systems. Type 2 engineers recognize that the interaction between these complex systems makes process changes and process-oriented solutions prone to failure.
Fundamentally, each type perceives success differently. A successful deploy of a bug-free software change to enact a process change might be the end of the story for a Type 1 engineer - our work was undoubtedly successful. Whereas with Type 2, if that process change resulted in increased difficulty for the users in getting their work done, that is clearly a failure.
Another way to look at this is through the common “Outputs vs Outcomes” framework. Type 1 is focused on the Outputs: the successful deploy of a software change. Whereas Type 2 is focused on Outcomes: this change didn’t help our users get more work done.
Thorsten admits that he believes Type 2 engineers are more useful because they are better at considering the impacts of their decisions on their users, and therefore they implicitly make better decisions overall.
Me (and you)
As a systems thinker, I of course see the value in being a Type 2 engineer. We don’t just think about the outcomes of our work for our users, but any “external” impacts that we might be generating – for example, on the reliability of downstream systems, or on our cloud bill, or on the planet. Site Reliability Engineering is just a specific application of systems thinking.
We Type 2s also think about how we are affected by other systems’ “external” impacts. For example, how inefficient Agile processes can lead to poor user experiences, or how an organization that does not prioritize having a strong engineering community will often end up with weak engineering practices.
Different but equal
I do, however, think it’s likely a bit short-sighted to say that Type 2 is simply globally better than Type 1. Most ecosystems thrive on diversity.
While I’m not a Type 1 myself and so can’t speak to those advantages, I’m sure they exist. My guess is that Type 1 engineers might be better at solving problems that don’t require extended systems thinking, if nothing else because they can devote 100% of their mental resources to a pure “zero-externalities” approach.
If I’m correct, that brings up a series of interesting questions:
- If Type 1 and Type 2 engineers each bring unique strengths, then how should we reflect that in hiring / mentoring / performance evaluation / etc?
- What is the best balance of Type 1 and Type 2 engineers for your org?
- What is the balance today? How do you know?
- Does your org currently value or recognize the contributions of one type over the other?
- What are the differences in the ways that Type 1 and Type 2 perceive success? How can we cater to those differences so that everyone finds fulfillment in their work?
Better is better
Thorsten has been around a while and worked with many engineers (probably more than I have), so … maybe he’s right. Maybe Type 2 is simply better.
If so, that still raises a lot of interesting questions:
- How can you determine someone’s “Type 2” skillset, either for hiring or performance purposes?
- How can you coach it? Is this something we can learn from Pluralsight or Coursera? Can we become certified Type 2 thinkers?
- Is this even coachable, or is this fundamental human diversity here? Like asking a violinist to perform the shot put?
- Most pressing of all: how can we accommodate those that haven’t yet “ascended” to Type 2 without minimizing them as lesser-than?
Better is worse
If Type 2 really is Type 1 but more, then if you’re a Type 2 you’re simply better, right? Everything is good for you, because you’re so amazing. Unless you happen to find yourself in one of the following scenarios:
- You work in an organization that only values Type 1 achievements. (Typically, with arbitrary deadlines.)
- You work in an organization that thinks that Type 2 work is reserved for management silos, and actively discourages Type 2 contributions from engineers.
- You work in an organization that is run by Type 1 thinkers, which repeatedly suffers the entirely-predictable consequences but shifts the blame to the ICs or their managers.
- You’re looking for an engineering job, since most interviews today focus so heavily on Type 1 skills that leetcode is now a requirement regardless of experience or track record.
All of these scenarios are not only common, they’re effectively the norm. I’ve encountered all of these in some form at nearly every medium or large corporation, and at several of the smaller ones. Regardless of whether you think Type 2 is superior or not, it certainly doesn’t come without its downsides.
- What are the downsides of being Type 1? …