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.
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!
> the split between people who want to abstract the application domain and people who want to engage with it
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'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".
Do you use "emdash" because you love to use it but don't want to be mistaken as AI-generated?
haha, yeah, just a little cheeky human humor.
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.
If there's one archetype that haunts math forums, it has to be the Retired Engineer that took a look at the Collatz conjecture or the Reimann Zeta zeroes and just came up with a theory.
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?
My favorite physics crank was the guy who convinced himself that curves don’t exist; they’re merely lots of line segments pasted together. He proceeded to derive a whole lot of remarkable nonsense about astrodynamics, and maybe relativity? It’s been a while.
Maybe ironically, the idea that curves don't exist hasn't gone away, it's still a serious idea: spacetime could be discrete, in which case curves really are a series of discrete line segments. Loop quantum gravity is one such theory, and I would hardly say it's crackpot physics.
Or the medical doctor who invented Riemann integral in 2000s and actually published a paper in a medical(?) journal. It was hilarious.
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.
Yes, I think you're spot on with that distinction. One can be conscientious and impure (in the article's parlance). That would be a further way to explain why some people love LLM output and others deride it.
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.
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.
Maybe "practical" engineering is a better label?
You could go for "pragmatic" but then it's taking sides :-)
If instead of "pure" you use "purist" you completed the loop!
Impure software engineering generates too much technical debt.
That's a pretty absolutist statement for what the article states is a very broad subject, well beyond code. Can you elaborate what you mean, or whether you have a different definition of impure software engineering?
I agree, but not because impure engineering is bad (like OP is suggesting). It's because tech debt is often a result of changing requirements. It's part of the nature of impure software development. Thinking tech debt is a reflection of poor engineering or bad practices is just plain wrong, imo. It's part of the job.
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.
Impure software engineering funds your paycheck
And impure engineers would say that that pure engineering produces too much bankruptcy because you never ship a viable product. ;-)
lol.
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.
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.
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.
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.
> 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.
> 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.
...on the site; you can't enforce those rules on other websites, they're referring to expected behaviour of users of HN.
Quite a bit of speculation and generalisation here..
Classic case of empowering two keywords and going to town with cliches, like most self help book style.
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.
How do you mean? To me this reads like the author is proposing a framework for interpreting known phenomena in the tech industry.
I can't be bothered doing more than the first paragraph but you can see where I'm going..
>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.
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"
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.
You can drink pure water just fine. The trace minerals in it are not significant relative to what you get from the other things you consume.
I hoped this was the pure of Haskell. It is very much not and I enjoy reading it. You did not I guess.
It's the same conceit.
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.
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.
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
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!
> the split between people who want to abstract the application domain and people who want to engage with it
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'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".
Do you use "emdash" because you love to use it but don't want to be mistaken as AI-generated?
haha, yeah, just a little cheeky human humor.
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.
If there's one archetype that haunts math forums, it has to be the Retired Engineer that took a look at the Collatz conjecture or the Reimann Zeta zeroes and just came up with a theory.
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?
My favorite physics crank was the guy who convinced himself that curves don’t exist; they’re merely lots of line segments pasted together. He proceeded to derive a whole lot of remarkable nonsense about astrodynamics, and maybe relativity? It’s been a while.
Maybe ironically, the idea that curves don't exist hasn't gone away, it's still a serious idea: spacetime could be discrete, in which case curves really are a series of discrete line segments. Loop quantum gravity is one such theory, and I would hardly say it's crackpot physics.
Or the medical doctor who invented Riemann integral in 2000s and actually published a paper in a medical(?) journal. It was hilarious.
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.
Yes, I think you're spot on with that distinction. One can be conscientious and impure (in the article's parlance). That would be a further way to explain why some people love LLM output and others deride it.
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.
Worse is better
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
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.
Maybe "practical" engineering is a better label?
You could go for "pragmatic" but then it's taking sides :-) If instead of "pure" you use "purist" you completed the loop!
Impure software engineering generates too much technical debt.
That's a pretty absolutist statement for what the article states is a very broad subject, well beyond code. Can you elaborate what you mean, or whether you have a different definition of impure software engineering?
I agree, but not because impure engineering is bad (like OP is suggesting). It's because tech debt is often a result of changing requirements. It's part of the nature of impure software development. Thinking tech debt is a reflection of poor engineering or bad practices is just plain wrong, imo. It's part of the job.
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.
Impure software engineering funds your paycheck
And impure engineers would say that that pure engineering produces too much bankruptcy because you never ship a viable product. ;-)
lol.
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.
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.
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.
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.
> 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.
> 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?
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.
...on the site; you can't enforce those rules on other websites, they're referring to expected behaviour of users of HN.
Quite a bit of speculation and generalisation here..
Classic case of empowering two keywords and going to town with cliches, like most self help book style.
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.
How do you mean? To me this reads like the author is proposing a framework for interpreting known phenomena in the tech industry.
I can't be bothered doing more than the first paragraph but you can see where I'm going..
>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.
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"
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.
You can drink pure water just fine. The trace minerals in it are not significant relative to what you get from the other things you consume.
I hoped this was the pure of Haskell. It is very much not and I enjoy reading it. You did not I guess.
It's the same conceit.
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.
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.