The difference between a coder and a programmer

If you look up the term coder and programmer you will most likely find that those terms are used interchangably. I don’t use them that way and to my delight I discovered that Leslie Lamport uses the terms the same way I do: “Coding is to programming what typing is to writing”.

A few years ago I was talking to a newly minted MSc over lunch. Either he had expressed an interest in working for me, or someone on my team had suggested that he was a smart kid, so we should hire him. Either way, I sat down with him to get a feel for who he was.

After talking a bit about what he had been studying, his thesis work, and some of the project based work they had done, I tried to get a feel for how he approaches and solves problems. Which was important to me because I ran a department that explored novel ideas to see if they could be made practical. After asking a few questions trying to ascertain his grasp of the rudiments (algorithms, complexity, useful bits of math etc) he said something along the lines of (and I’m paraphrasing here): “devloping software isn’t about knowing stuff, or being able to understand; it is just about gluing together various existing components”.

I must admit I was a bit floored.

There is a large portion of the software industry that consists of relatively mindless work, assembling bits and bobs into something that implements solutions to well understood problems. Like following someone else’s spec to write a piece of business software that does something entirely routine.

I tend to think of these people as coders.

A coder is a form of blue collar worker. People who do as instructed, leaving the intellectual heavy lifting to someone else. There isn’t a lot of creative thinking or problem solving going on. Not unlike typists in the past - people who turn words in one form (tapes, shorthand) into another (typed pages).

To squeeze a bit more out of the typist analogy, what he said was akin to someone telling me they had just completed a graduate degree in English and then aspiring to find a job in a typist pool. Turning shorthand into typed pages.

Recent advancements in AI suggests that perhaps we don’t need coders in the future. It wouldn’t be the first time a blue collar workers are replaced by machines. (That being said, we’re not there yet. LLMs are notoriously unreliable and it is no less work to verify generated code than it is to write it. Unless, of course, you don’t verify. But you wouldn’t be that unprofessional, would you?)

Don’t aspire to less if you are capable of more

Now you might expect me to say that I’m not making a value judgement, but that would be disingenuous of me. I am making value judgements here. Sure, there are roles that are “coder roles” and “coder jobs” where your ability to be more is limited, but to aspire to less when you are capable of more isn’t something that impresses me as a prospective employer.

Programmers and coders

There is no formal difference between coders and programmers that I am aware of. At least dictionaries and such do not seem to make a clear distinction. But I have observed that some peope distinguish between the two in the same way I do. (Leslie Lamport is apparently one of them).

To explain what I mean by programmer, we have to go back a few decades to my first job, and my first mentor. I worked for a guy who did manufacturing automation. He would spend perhaps half a year working at, and studying, the customer’s business. Exposing himself to every part of their organization, from manufacturing floor to board room. Then he would spend a bit more than that analyzing what he had seen, understand all the processes, and figuring out what parts of the business required redesign. Then work with the customers to adapt the company to where manufacturing could be automated, and perhaps optimize the company a bit along the way.

Only then would the process of actually writing any software start.

This taught me that a programmer is first and foremost someone who understands a problem. Once you understand the problem, it is much easier to explore the solution space, or indeed, start thinking about how to formulate solutions.

And before you say that this is an architect’s job: an architect must have a skillset that significantly overlaps with that of a programmer. There are architects who do not qualify under this requirement, and this is unfortunate. In my experience, this tends to be a factor when, especially, large projects fail. It is essentially about letting unqualified people make key decisions.

My role back then was most certainly as a coder. I was an inexperienced kid in my teens still going to school. But his patient mentorship showed me the difference and it made me aspire to be a programmer.

He also got me my first independent consulting gigs, which were perfect for someone who wants to become a programmer: deal with people who know nothing of computers, but have real problems that need solving. This forces you to speak their language, to understand their field, and their challenges in order to create solutions that actually solve their problems.

As a programmer you often end up having a better formal understanding of someone else’s problem, in a different field, than they themselves have. And if you don’t: how can you expect to solve problems for other people?

Afterword

I think distinguishing between coders and programmers is useful. Yes, I know they are used interchangably in everyday speech, but it is useful to make the distinction. Not least because it clarifies that there are subsets and supersets of skills that delineate what you can expect people to be able to do.

I hope I was wrong about the new graduate I talked to. I hope he had bigger ambitions than just blindly assembling bits and pieces other people have already created. But as the industry has grown, the frequency with which I encounter people who aspire to only have blue collar IT jobs and not do too much of their own thinking has gone up.

If you think the bar for “programmer” is unreasonably high: well, perhaps you should instead ask yourself what is keeping you from making that bar instead of trying to talk it down.