Praise for the pragmatic third camp

16 Mar 2023

Some years ago I came across a blog post that described programmers as being in one of three camps. It’s a fun, short post, so I encourage you to go read that real quick, but the gist of it is that programmers generally fall into one of three categories according to what they primarily value:

Applied mathematicians, who appreciate elegant solutions to problems. Program execution on von Neumann machines is incidental. These programmers like high-level languages and mathematically correct reasoning about programs.
Bit hackers, who like making the machine run as efficiently as possible. Without a von Neumann machine, programs are pointless. These programmers like low-level languages that let them get into the guts of things.
Product makers, who care about the ideals of the first and second camps in as much as they help them accomplish the task of delivering more features. Most industry programmers probably fall into this category. They like high-level languages as long as performance doesn’t suffer too much and that it’s pragmatic. (E.g. JavaScript, Ruby, Python, Go, etc.)

The author of the post talks a little bit about the tension between the camps. I won’t reproduce it here, but it can be amusing, so you should give it a read.

I’ll go ahead and add one more camp to the list: the code monkey for whom coding is just a job. They care about the quality of their work in as much as it allows them to hit their deadlines and collect a paycheck. They don’t care too much about what language they use, as long as it’s the one they learned in school or their bootcamp. They’re generally not curious about learning new languages, understanding how things are implemented, or making a good UI.

Most people I’ve worked with have fallen into the first three camps, fortunately. I’ve encountered a few who fall into the fourth camp I just outlined, and they’re miserable to work with if you care about anything. When you work with someone from camps 1–3, there’s some passion there to channel to make a better program, for whatever your metric of “better” is—and you can usually come to some consensus so that a program is better on multiple axes. But with the fourth, there’s nothing there to push on.

I’ve found it to be a helpful paradigm: whenever I have a disagreement about someone about what constitutes good or valuable programming, I consider what kinds of things they value. (In a way, it’s a little like Jonathan Haidt’s Moral Foundations Theory for programmers.) Maybe you can think back to some disagreement you had and see the value mismatch manifesting.

The other day I experienced a burst of appreciation for camp 3—the pragmatic makers—more so than I had ever felt before. I was fighting with a crappy health insurance website. Instead of a <select> dropdown element, they had built a <div> with some on-click handler to make a faux dropdown. The website was janky, bloated, slow, and difficult to navigate. It must have been made by programmers in camp 4.

I realized that the only camp that stands a chance of fighting this kind of crappy experience online is those programmers in camp 3: the soldiers who care about their craft enough to make the user happy. I realized that I would never ever want to build a better insurance site because that’s not an interesting problem to me, but there are those who have different motivations than I do, and these people can channel those motivations into hammering out better experiences for all of us.

So, here’s to the pragmatists—the people who care about the end and not so much the means. I’m going to stay in my camp working on more elegant tools for you to use. It’s nice that there’s some symbiosis between the three groups. We should all recognize that we need each other.

Except for camp 4. You’re the reason why we have crappy insurance portals.