Great points made, but with an unfortunate false dichotomy holding it all together. There is a continuum here, and the same individual can occupy different places on it in different contexts. I suspect most of us do. I lean “pragmatist” by default, especially when I don’t know much about a project. When I know more about value propositions, stakeholders, and other risk/reward factors, I adjust accordingly. For personal projects, research, or greenfield work where I know it’s safe, I’m as much an “enthusiast” as anyone else.
It’s basically seasoning in the industry.
If you are purely an enthusiast at work even after many years, you are probably haven’t improved much.
I’m not saying that you shouldn’t be enthusiastic, fun projects are fun, but seeing the problem as a solution to a goal and be technical/scientific about it needs to be the priority of a programmer. Coding a little thing during the weekend, doesn’t necessarily have the weight of a production level project.
It’s obviously a simplification (and I state that in the article), but for most people I think one or the other is dominant. In your case for work purposes you’re a pragmatist first, sounds like.
Same problem as with “introvert/extrovert”. I guess you could argue that any given person is inherently one or the other, but if they’re being realistic while working their craft (socialization, in this analogy), they might just seem like an extrovert to any outside observer. Same deal with “enthusiast/pragmatist”. (enthusiast : pragmatist :: introvert : extrovert)
What I’m saying is: it’s just a feeling, and if someone doesn’t feel like they’re on one end or the other of the dichotomy, then its universality is broken.
When I first started not just tinkering with computers but actually coding (around middle school, which for context was ~2010 or so for me) I was definitely an enthusiast. And because I always wanted to build cathedrals of code and have grand fancy architectures that I didn’t need, just for fun (and use new technology to boot), I never actually got anything done.
It’s not the whole story but a big reason that I’m not stuck there anymore is because over time my definition of quality software changed. I believe in and more importantly understand the Unix philosophy now in a way I didn’t then. So even though I think I still have a big element of enthusiast, I’m enthusiastic for code that is really, really aggressively simple. And that’s much easier to build. The article frames the enthusiast as writing code for the sake of the art and being beautiful, and I love that metaphor, because beauty is in the eye of the beholder.