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".
roslyn.nvim
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.