> 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?
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.
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".
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!
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. :)
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.
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.
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.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.
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.
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.
000ooo000•3h ago
n4r9•3h ago
keyle•3h ago
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.
Cthulhu_•1h ago