And that's fine, it encourages thought and a framework and whatnot. Given it's a personal blog and not a paper, I'll file it under "author's personal opinion" more than "generally accepted fact"
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.
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.
I'm kind on the fence, but not with the article. It's true that there are engineers who lean more towards one or the other way. For example, since the author brings up the switch from Neovim to VS Code due to features, I do love using Neovim for my TypeScript and Golang needs. But, if I were to work with Java or C# I'm switching to IntelliJ or Rider.
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 think the article picks the wrong pure / impure dichotomy. Much more interesting to me is the split between people who want to abstract the application domain and people who want to engage with it. To the former, a CRUD app is a CRUD app. To the latter, CRUD is still a useful framework, but it’s just a tool that’s subordinate to a bigger purpose. Or take game dev; the decision to go deep on game engine design can be driven by your opinions about shipping versus tinkering, or it can result from having a game in mind and picking the best way to realize its mechanics. CS attracts a lot of abstract thinkers, and CS degrees reinforce the abstraction of the application domain, so I find that a lot of programmers take it as a point of pride that they don’t engage with it.
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 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.
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. :)
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?
Redefine what perfection is (although I'd argue you'd probably do well to work on disabusing yourself of the idea of perfection altogether - but that's for another time).
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.
> Is that just an early-career thing, or is there some way I can get better at giving up the idea of perfection?
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.
Judging a perfect solution requires first asking, whose problem are you solving? If you only ever insist on addressing your own aesthetics and properties of interest, you're only solving your own problems, not a problem anybody else has. That can be fine sometimes, but probably not for all problems. People will appreciate solutions that save even 20% of their time now. Saving them 50% if only you could work on it for 2 more years has less value.
> 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've always interpreted that as applying more to comments, but I didn't write or enforce the rules. It's a text version of the list of 'share on social media' icons I think.
The reason purity is good is because you've distilled something to its simplest, most essential and parsimonious form. It is only in this form that you can truly understand something, and only from this form do you have maximum flexibility to combine it with other pure elements to achieve any possible goal.
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.
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.
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.
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.
Dijkstra's paper "On the cruelty of teaching computing science" makes a different distinction that is worth reading about. CS work as in developing algorithms, etc.; and "software engineering" in the sense of solving problems with software that create more problems. His words, not mine...
But his latter take always reminds me the authorization/authentication mess that we are all in right now.
27 comments
[ 2.9 ms ] story [ 56.5 ms ] thread> 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.
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
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!
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
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?
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.
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.
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.
But his latter take always reminds me the authorization/authentication mess that we are all in right now.