Article: 3 Tribes of Programming
This is a review of an article classifying programmers into 3 archetypes by Joseph Gentle. It is one of the best articles I read recently, and potentially an all-time favorite. I had always thought about this and even wrote about it a little bit (actually more than once), but I think this article has a better way of fleshing out this concept.
So, let’s get into it. But first…
Why Bother?
Why am I so excited about this article and reviewing it in my own writing? And why should you care as well?
Generally speaking, it’s good, maybe even important, to learn about human psychology and personalities. We’re all different, and each of us has their own way of thinking, their own ideals, and their own feelings towards certain things. Learning more about that stuff can give you a better understanding of yourself and people around you. It also affects the way you express yourself and communicate with others.
This here is the same thing but specific to programming. These archetypes are pretty much like personalities because each archetype represents a philosophy, a style, and an overall set of principles and ideals that a programmer prioritizes above all else. Differences between these tribes have been, and will likely continue to be, the source of internet debates and flame wars. So, it’s good to not lose perspective and see where each side of a debate comes from.
With that out of the way, let’s talk about the actual tribes!
The Poet
The author likens those “poets” to mathematicians. In terms of code, the poet’s highest priority is to write simple and beautiful code. It should clearly express its intent, which brings itself more naturally the declarative (as opposed to the imperative) paradigm. In terms of languages, Clojure gets a mention (and its creator Rich Hickey) in that part of the article along with Haskell. Unsurprisingly, all the languages mentioned and almost all of the characterizations of the poet play very well with functional programming.
This archetype is what I previously referred to as the idealist, and if you know me by any means, you could pretty much see that I strongly belong to this category (and if you don’t, you do now). His description of the poet focuses on words and concepts that I would say myself or at least find fascinating when others talk about it: things like language design, elegance, simplicity, etc.
Personally, what keeps drawing me closer to programming up to a point where I want to seriously shift my career into software engineering is that it can feel very close to maths at times while still being grounded in reality and not too abstract or theoretical. The “mathiness” of code is especially true in functional programming, and I wrote an article about my fondness of it. FP in general, and functional languages in particular, combine a lot of theoretical concepts to produce an elegant way of solving real world problems.
What’s not great about poets, including myself, is that sometimes they get too attached to their code to a degree where the UI or the product is merely a side effect (which it literally is from that perspective). I do try my best to prevent the poet persona from taking all over mine, especially when it comes to work and money, but I will always be a strong poet at heart!
The Hacker
The “hackers” are the ones who work at lower levels than the other two groups - they play it close to hardware both in terms of the languages and their way of thinking. Not surprisingly, they are more performance-oriented as well and their code is usually imperative and full of mutations, because that is more or less how hardware itself works. As the author states, this knowledge is becoming less important in general, but the hackers still have their own specialties like game development, embedded systems, etc.
This is the programmer archetype that I wasn’t thinking of in my previous contemplations, which is expected given that my experience only spans statistical programming, web development, and some Linux tinkering here and there. Also, the concepts that fascinate the hacker the most fascinate me the least. I’m not that much into hardware and, being quite the poet type, I favor the declarative paradigm over the imperative, which is admittedly farther from the hardware’s logic.
Interestingly, the author wrote about the conflicts between hackers and poets. They are polar opposites when it comes to mutation. For hackers, mutation is how hardware works, but poets (functional purists) think it’s the root of all evil. Garbage collectors are dead weight for hackers but less bugs for poets. Abstraction obfuscates code for hackers but gives poets better ways of reasoning about code.
The Maker
In my article’s phrasing, that would be the pragmatist who considers programming only a means to an end. In that sense, “makers” only care about the end-result: the product. While they might care about stuff that characterized the other two groups, that stuff would be less important than shipping the product. So, their priorities are speed of iteration and user experience.
As the author says, this is where the money is (mostly) and, consequently, most professional software engineers belong to this camp. However, their result-oriented nature is in heavy conflict with the two other groups, each for their own reason. Their code can be messy and ugly for the poet and inefficient for the hacker. Needless to say, this is the root of lots of online debates. Another couple of interesting points raised by the author is that makers are the most welcoming and forgiving community, and they can be a bit “soulless” (stating that the latter accusation can be pointed to any of the 3 groups.)
While I proudly consider myself a poet, my current job has “polluted” the purity of my poetic tendencies with some pragmatism. I’ve been dealing with clients and non-technical management long enough to see some of their perspective. Not only that, I even thought at a certain point that I was about to be converted to this camp. While I am thankful for the little bit of pragmatism in my current thinking, I found too much of it to be uncomfortable for me. I allowed myself to be messy for the sake of making good products, but I am not happy about that in retrospect.
All in all, I respect the practical and business aspects of programming and can consider them in my coding, but never all the way.
Conclusion
“What makes a good programmer” is a topic that has been under discussion and debate for as long as (and even before) I got into this thing. The only “correct” answer I could give is a general one: it means different things to different people in different settings, so it absolutely depends! This article should’ve formed a clearer picture as to why this is the case.
Hope you enjoyed the article!