Mastering engineering modes
I recently read this thought-provoking piece by Sean Goedecke about how there are two types of software engineering: pure and impure. In short, Goedecke argues, the pure kind is driven by a sense of aesthetics, like art or research, whilst the impure kind is pragmatic, driven by external needs.
Though I agree with most of the article, it did raise questions in me:
- is it really a dichotomy?
- is an engineer one or the other?
- can you improve these “engineering modes”?
- how does it impact team composition?
I think a better way to look at pure and impure engineering is as distinct modes Here’s why.
A spectrum, not a dichotomy
Pure and impure engineering is a useful mental model, but it requires nuance. In reality, depending on the situation, you need both types of engineering, even within the same project1.
For instance, given a looming deadline, a team of engineers will likely shift to an impure type of engineering. Work needs doing, there’s a need for outcome, and impure engineering is the mode best suited for the job.
However, at other times, work might shift towards pure engineering. Perhaps you’re building something entirely new in the codebase, and you need to blaze a new trail, make choices (and trade-offs) on how to achieve the functionality, and make it simple2 so that others might follow.
I remember a case like this at NS (Dutch Railways). We worked on an application that detected conflicts in what operators want to do with trainsets, such as whether the combination of trainsets fits all platforms along its route. After a while, a need arose for another type of conflict, with many more cases to come. Pure engineering laid a solid foundation after which we churned out value with impure engineering3.
Whether you need pure or impure engineering depends on context. Perhaps the application is short-lived and favors impure engineering, or maybe, like at NS, your application is mission-critical for public infrastructure. Here the scales would tip towards a balance between pure and impure engineering.
Time, change, and uncertainty are the true stressors to the software we build4. As you expect more stressors, work will resemble a pendulum moving between pure and impure engineering, rather than being a fixed point on the spectrum. Strong engineers have a good sense of judgment regarding this predicament.
Shifting modes
The article frames pure/impure engineering as types of work and engineers, but I think of them as distinct modes. Not only do you land somewhere on the spectrum by nature, you can leverage them separately. A strong engineer shifts between modes based on necessity.
This is a valuable skill in engineers. It makes them adaptable to situations and able to tackle a variety of projects. In a way, it’s the difference between being a specialist and a generalist, and I’d argue most companies would do well with a majority of generalists5.
I also think it’s a skill available mostly to strong engineers. It’s rare to see inexperienced engineers capable of both, but I’ve seen plenty possessing one or the other. In fact, I was one of them, highly favoring pure engineering.
However, I do think you can develop these engineering modes, although you’ll most likely be inclined to one or the other. If you’re aware of these modes and your own tendencies, you can improve the weaker one (or capitalize on the strong one).
I’ve experienced this growth firsthand. In recent years, I’ve worked on my impure mode. I learned to consider context in everything that I do and to leverage the impure mode when needed. For instance, when we recently did a proof of concept at NS, I deliberately favored speed and results over elegant code. This would’ve been incredibly difficult in my early years. Back then, I didn’t even realize there was an option other than the pure one.
A case for heterogeneous teams
Most projects require a blend of both pure and impure engineering, which is why team heterogeneity is important. Since each engineer is probably better at one or the other mode, having a team consist of engineers of both types is a good idea. The weaknesses of one engineer are dampened by the strengths of another. It also provides opportunities to learn. It’s a good opportunity to see someone excel at your weakness up close.
Pure-engineering-inclined individuals such as myself benefit from the presence of impure ones. Whenever I’m on the verge of starting a pure engineering expedition6, I can count on teammates calling me back. Vice versa, when I see an impure-inclined engineer move at breakneck speed, I will be sure to point out dealbreakers in the results or discuss guardrails upfront. Together we strike a solid balance and learn along the way, albeit with some (healthy) friction.
Conclusion
The distinction between pure and impure engineering is a valuable lens to possess. Using it, you can assess what type of work something is, how best to tackle it, and use it to spot opportunities for growth in yourself and your teams. Pure and impure engineering are distinct modes on either end of a spectrum. Mastering the engineering modes can make you an even better engineer.
Though there are always exceptions. Niche projects, like Goedecke mentions, where pure engineers might excel; startups where the impure engineers shine; et cetera.↩
Simple, in the wise words of Rich Hickey, ain’t easy.↩
Goedecke rightfully mentions that this is where AI has most leverage. Perhaps my pure inclination is also why I’m not sold on its application yet.↩
Residuality Theory by Barry O’Reilly radically changed my perspective on software. Highly recommended.↩
I imagine that the majority of companies do not operate in niche domains where specialists shine, though I suspect that as a company grows so will its demand for specialists.↩
If someone from my team reads this, I imagine them nodding their heads with unrivaled intensity right about now.↩