This dichotomy exists, and the author states the illusion of "competent" vs "incompetent", but I think it's more "Conscientious" vs "Indifferent". Tech business competition breeds indifference, because when you optimize around minimizing technical debt, your competitor will eat your lunch with worse code. Lots of competent engineers incur tons of technical debt, because they'll eventually be paid to swim in it, and they don't care. Open source projects tend to be written with much more care, because the reward mechanism is different.

Interesting take, and there is some truth to the "practical vs ideological" split, but I feel like it's a bit mixed up here.

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.

I liked this article because I think it is a fairly charitable "strongman" take of the "pure" engineering camp from someone who identifies with the other camp.

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.

[1]: https://a.co/d/eLvZYcE

The dichotomy being presented here is great, and I appreciate the tact in presenting each side's strengths -- a tasteful and enjoyable read. It _is_ possible after all to exist on either branch of this bifurcation and have respect for the other side, even though (hint hint I'm looking at you, "pure" engineers) such a divide is the root of much intellectually-veiled baiting.

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. :)

Good read. I’ve thought about this distinction myself, but this was definitely more clearly articulated.

> 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.

Worse is better

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

Impure software engineering generates too much technical debt.

I dont like the "impure" label. But the guts of it is right. Most software solves a business problem. Even the "pure" ones could choose to deliver value sooner with tech debt.

Game development is likely the most bipolar example of this. You get both flavors as strongly as possible in the same place. Part of it is incredibly pure as mentioned in the article. Building an engine that can run on all targets is impressive. But then you have to meet all of these artists and customers in the middle which requires some of the messiest work imaginable. You'll end up with odd game objects hidden under the scene that manage elaborate things because the technical team had no way to anticipate the messiness of the impure world of art and emergent gameplay mechanics. The best they can do is continue to support the pure aspects as best they can and account for this mess in their future engine designs.

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.

> If you liked this post, consider [...] sharing it on Hacker News.

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.

I'm very perfectionistic and find it really difficult to accept imperfect solutions to a problem, to the point where I'll just lock up until I can come up with a better way. Is that just an early-career thing, or is there some way I can get better at giving up the idea of perfection?

Quite a bit of speculation and generalisation here..

I have to think they borrowed "pure" from haskell. It's such a stupid word to use in both cases.

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.