Pure and Impure Software Engineering
seangoedecke.com
seangoedecke.com
The actual division I see is between programmers arguing for simpler, more direct solutions to problems (e.g see Casey's blog post on semantic compression, or the hype around HTMX) and those who want to architect the "perfect" scalable and extensible system. The latter is much more common in enterprise settings, usually performs worse, and is the source of a lot of incidental complexity.
The article mentions microservices and event driven systems as an example of "pure engineering", but I think it's the exact opposite. I always see the "pure" crowd advocating for single binaries, fewer dependencies, fewer network hops, and less future-proofing.
That being said, there is an objective way out of this trap emdash check out Dave Farley's work on Modern Software Engineering [1].
It is a very clever approach to convert the process of software delivery into a software problem itself, with a minimal criteria of shipping new code safely every 24 hours.
When your "pure" engineers optimize around that, the distinction between your "pure" and "practical" devs tends to be pretty small.
It’s probably clear where my sympathies lie here, so I’ll balance that by saying something nice about abstraction: it really can help you see the problem more clearly. It’s a great tool to avoid solving the same problem over and over again. Just make sure you’ve correctly identified the problem first!
That sounds like the classic dichotomy of Theoria and Praxis.
> The philosopher Aristotle held that there were three basic activities of humans: theoria (thinking), poiesis (making), and praxis (doing).
> Corresponding to these activities were three types of knowledge: theoretical, the end goal being truth; poietical, the end goal being production; and practical, the end goal being action.
I can see these aspects exist within an individual, and as a group such as the academic field and practical culture of computer science.
There's a temptation toward theory building, elaborate architecture and systems, abstraction for the sake of it. The field is richer for it, but it's also a risk of distraction and source of incidental complexity.
The call to action, to return to the making at hand. Working with the material, applying the ideas in practice, keeping what works and throwing out what doesn't. Learning through doing. Sometimes the solving of a problem or need is achieved first, then the pattern is recognized, the ideas and theory to explain why it works.
I believe it's healthier to attain some kind of pure-leaning... centrism(?) if we were to present pure/impure as black/white choices. I find it easier to imagine someone who deeply cares about squeezing performance through min-maxing to suddenly shift gears and deliberately introduce debt and just ship-ship-ship for the sake of pushing the product out, because they know exactly the price of the corner that they're cutting.
So I don't see it as a "you're either this or that" but more like "you should be this, and also be that when it's deemed appropriate".
I do not however agree with the author that "pure engineering" is going away:
> But like I said, those times are gone. Tech companies now have to make money.
Tech companies have always had to make money... in a vacuum. The return of an AI hype-train laden with VC cash has in many senses recreated some of the air of extravagance of the 2010s-era; perhaps with even more frivolity than last time. I think the author is mistaking a decline in OSS library and tooling spending by companies -- for human use -- as fall in pure engineering efforts. I'd argue instead that the definition of what counts as a "pure engineering" effort has simply shifted to AI-based tooling. We see now, and will continue to see, lots of high-octane-brain-power effort and money being sunk into building the "best" protocols, interfaces, and libraries to interface with AI... which will also likely be OSS too!
The purist flamewars will just be about a lack of understanding of MCP rather than how to use Rust. :)
> This view is kind of like saying that engineers are just people who weren’t smart enough to do physics, or physicists aren’t smart enough to pure mathematics.
To some extent that’s true though. :) Source: I have an MSc in Engineering Physics.
This also happens in physics, but physics crackpots can come from anywhere. Especially now, having been reassured that they've hit the key insight, and you're absolutely right, it's not just a theory of everything — it's a revolutionary new foundation for physics! Would you like me to help you write a convincing paper delving more into these ideas?
No, you just have to really, really get it into your head that perfection most often results in missed deadlines and never truly finishing anything.
One of my hot takes is that anybody that considers themselves a perfectionist but can also list off things they've completed doesn't actually understand what true perfectionism means. They're just bragging about their attention to detail.
Back to redefinition: what's perfect for you may not be what's perfect for your team, your division, your line of business, your company, your personal project, whatever. Is part of the perfection metric time to deliver? Customer (user) satisfaction? Reduction of support requests? I'm not saying any one of these is right, but I believe there's a framework of compromise out there that can help you should you want to change this area of your professional life. In short, think outside the core problem and expand the radius of context from just you and that notion of perfection, to something larger, something more systemic - I believe that can help.
On the other hand, if your drive for whatever you believe perfection is, works for you, then, meh, do you! We do need folks to scream that x or y isn't good enough, even if only to evaluate if we should find a better compromise than the current one.
But his latter take always reminds me the authorization/authentication mess that we are all in right now.
There is this fantasy (primarily pushed by the pure devs), that impure/enterprise dev is like following a recipe. The stakeholder gives you the requirements (ingredients, how to cook) and your job is to execute that. And anyone that has spent a non-trivial amount of time in the enterprise world knows this just not how it works. Unlike a video game where there will eventually be an end date, impure devs often have to build solutions that don't have an expiration date. And that's not easy development, trust me.
I mean, of course it does? Requirements change, priorities change, rules/laws change, which all contributes to a constantly moving codebase.
When you're building a video game, do you have to worry about Congress changing healthcare laws? Cmon.
There is a reason you see some shops perfectly happy using old tools like unity 2022lts, UE4, etc., and others constantly upgrading to the latest new version. In the later case, the quest for purity has outstripped all other priorities - We must be on the latest and greatest at all times. In the former case, they've already experienced the later case and realized that it can never be clean. It's always going to be messy somewhere when you are working on something this complicated. Might as well use the engine that has already been deployed to a billion devices and proven itself over a decade.
Those who have been in the industry for a while can often tell when an indie dev is going to fail at launching a game simply by how they talk about the technology they intend to use. Shopping for tools is fun. It's pure and clean. You haven't really committed to anything when you buy a screw driver or a hammer. The moment you use that hammer to tear into that first piece of drywall, you have a kinetic, messy situation on your hands. Tooling might still be important but it needs to take a back seat to the mission at that point.
Not to be that guy, but is this not in violation of the guidelines?
Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.It's a shame it became about that because there are some good points in there. Proper engineering used to be a bigger part of the whole tech industry.
>Why do solo game developers tend to get into fights with big tech engineers?
Do they? Often enough for it to be recognised as more than simply two loud, opinionated members of each set each having a twitter account?
>Why do high-profile external hires to large companies often fizzle out?
'Often'? More vibes-based analysis?
>Those two types of engineers often assume their counterparts are simply incompetent, but they’re really just working in different fields.
'Often' again?
If one wants to make generalisations about an entire field of diverse individuals working in diverse roles, that themselves can vary significantly in scope, I think I need more than some flaky premises cobbled together from cherry picked scenarios and assertions based on, realisitically, minimal exposure to those individuals and roles. Look at the author's resume on his site: 2 employers. Don't get me wrong, he's free and should continue to pontificate, but I'm also free to reject it as naive and unconvincing.
Purity is an illusion. Water looks pure even when it's tainted with lead.
Purity isn't good. If you only drank pure water you'd be starving your body of necessary minerals.
The real antagonists are idealists and pragmatists.
Idealists are fun to talk to but terrible to work with.
People who love programming but hate software development believe what they're doing is "pure" because it's untainted by external influence.
A pure function can still be badly written and full of bugs. Pure art can still be reactionary and derivative.
This is just as true for computer science as it is for material science, eg. good luck flying to the moon without first developing the table of periodic elements.
Yes, that sometimes this can take more time, and yes, you can often take shortcuts and mishmash something together that works well enough for many if not most currently pressing purposes. Only distilled forms are guaranteed to have enduring impact though.