My interpretation is that as engineers, we attempt to justify all of our choices through purely rational means. However, as humans, we cannot really make said choices without also being at least somewhat influenced by our subjective affections.
Perhaps I'm stretching the author's message, but at least I believe that the argument extends to all engineering conclusions. The author's call is that we acknowledge this subjective side.
Essentially, true engineering is about tradeoffs, there is no X that is objectively better than Y in all circumstances and contexts.
> The author's call is that we acknowledge this subjective side.
I think that acknowledging the subjective side is a necessary step to making more rational choices. If you don't know your motivations, you will be a motivated reasoner.
When you can add "I like this tech because it helps me build an identity I aspire to" as an item in the pros column, you realize you no longer have to.
There’s a handful of things like Emacs and APL/J/K that HN introduced to me a decade ago that actively reduce my productivity — and I don’t need your explanations for how I’m using them wrong. They’re, to me, like a good book I’ve already read but keep rereading in-place of books I haven’t read. The reduced productivity is fine because we’re some unknown time away from nuclear war or falling down the stairs.
I have tried to go fully into the "Emacs mindset" (org-mode for everything, multiple pages of custom hydra keybinds etc.) a number of times and I always bounce off. I always feel there is some activation threshold that if I could cross it, I could enter editor nirvana.
I used to joke that the way I use Emacs is I open it, give the empty buffer a very meaningful look, C-x C-c, and open VS Code.