Pure and impure software engineering
https://www.seangoedecke.com/pure-and-impure-engineering/
The first kind - pure engineering - is interested in solving a technical problem as perfectly as possible.
In pure software engineering, what you’re doing is close to art or research.
Impure software engineering is more like plumbing or construction. The engineer’s aesthetic sense is subordinated to someone else’s (usually their employer’s) needs. They’re building a solution to someone else’s problem. And since it’s someone else’s problem, it has to actually be finished to schedule, which means compromising.
But in my experience, engineers who are mainly interested in pure work do impure work badly: they struggle to compromise, they panic under deadlines, they aren’t as good as holding unwieldy codebases in their head, and so on.
engineers who are mainly interested in impure work (like me!) struggle with pure work: they’re too eager to settle for a working hacky solution, and they often don’t have the technical expertise to see the right path forward.
if you’re a pure engineer with a particular area of expertise, you can almost always outperform impure engineers who are working inside a tech company to build a product
I think many pure engineers underrate just how hard it is to do impure engineering well. When you’re doing pure engineering, it’s just you against the problem. By comparison, impure engineering is a brawl: you’re fighting decades of previous technical decisions, competing political views about how the product ought to work, consensus among your colleagues or the company at large, and in general much more incidental complexity driven by the accumulation of wicked features that provide enormous business value at the cost of adding drag to every single piece of feature work. There’s a reason that impure engineering is so highly paid.