"Programming" and "Programmers" Mean Different Things to Different People

Blog archive

Late last year on my blog I published “How Might Generative AI Change Programming?”. Although I’m slightly biased, I’m still comfortable with that post’s high-level message. However, there is one important aspect that I think I failed to bring out as explicitly as I should have: different communities’ programmers will be affected in different ways.

One reason I made this mistake is that I had overlooked how different communities’ assumptions about “programming” and “programmer” [1] have diverged. As with most instances of incommensurability, the people involved (e.g. me) often don’t realise that they’re talking about slightly different things.

As a concrete example, a couple of weeks back, the Economist – whose coverage of areas I know about I find to be rather good – published an article with the following claim:

An AI “co-pilot” on GitHub, a Microsoft-owned platform for open-source programs, improves coders’ productivity by 30%.

My initial reaction was incredulity. AI tools are not currently even remotely close to speeding up my “day job” programming – which involves careful development of programming language tools like compilers – by anywhere near 30%.

But, after a little thought, I realised that this statement is true for some of the programming I have to do. Recently I had to do a little bit of JavaScript programming, a language which I barely know, and which I am therefore rather unproductive in. After a quick query using ChatGPT I had gained enough insight to find a webpage that let me quickly do the task I needed. I expect that, overall, I was able to complete this task in half the time I would have been able to before ChatGPT came along.

What this highlighted to me is that there are at least two very different styles of programming that I engage in. In one style, AI/ML has, so far, had virtually no effect on me; in the other style, it can be a noticeable productivity boon.

It didn’t take me long to realise that was a specific instance of something more general: different people increasingly mean different things when they talk about “programming” and “programmers”. Some of this is due to the gradual, and inevitably incomplete, diffusion of understanding about software throughout wider society. But even within the communities of people whose livelihoods involve staring at screens, there are important differences of understanding that can mean we end up talking past each other.

In this post I’m going to define what seem to me to be the three major categories of “programming” and “programmers” I come across, moving from the narrowest to the broadest. While I have my own preferences as to which categories I personally attach the terms “programming” and “programmers”, I’m not interested in dying in a ditch over terminology. Rather, it’s already helped me better understand what other people mean when I’m talking to them.

The “narrow” category

When I have to write a short description of what I do for work, I use two words: programmer, researcher. The ordering is deliberate: I was a programmer before I was a researcher [2] and I think of programming as my craft.

My self image of myself as a programmer is reflected in the way I approach programming. Most obviously, I am willing to attempt – though I may not always succeed at! – hard programming tasks (e.g. writing low-level and/or highly optimised code). Less obviously, I think of programs and programming itself as something worth careful and continual consideration. I put deliberate effort into practising programming and I spend a lot of time trying to make existing programs better. In many ways, how I program, and the quality of the result, is more important to me than what I am programming.

Although I am nervous of suggesting I am representative of anything other than my own odd self, I believe that many of the people I meet professionally have a similar outlook. We call ourselves “programmers” not just because that’s how we spend most of our time, but because it is the activity we care most about. We therefore tend to put a lot of effort into thinking about programming, and how to improve the programs we’re working on. We are willing to move between organisations who want us to program very different things because we want to program and we’re often less worried what we program.

The “midpoint” category

You will probably not be surprised to learn that the “narrow” definition of “programmer” and “programming” is the one that I implicitly used for much of my programming journey.

The first time I realised that my definition didn’t work well was when I interacted more closely with system administrators. These are the folk who keep computing services such as servers running. When I started my PhD, my department had a small but gifted group of system administrators. I enjoyed the company of the “sysadmins” (as we abbreviated their title) a great deal, in no small part because they were the most technical people in the entire department [3]! I learnt a great deal from this group because a good proportion of the tasks they undertook clearly involved programming. Their programming wasn’t the same as mine – it was smaller scale, with many of the programs deliberately “throwaway” – but it was similar enough that we could talk productively to one another.

Since then, I’ve encountered ever more groups of people who are using computers in a way that, at the very least, can be thought of as “programming lite”. One obvious group are the most sophisticated of spreadsheet users who create complex expressions that, in conjunction with a spreadsheet’s inherently reactive mode of operation, make my head hurt. More generally, there are a surprising number of users of “domain specific languages” (of which spreadsheet expressions are arguably a special, albeit wide-spread, case) who are commanding a computer in ways that are often like full-blown programming.

It seems to me that two things unite “programmers” and “programming” in this category.

First, the people involved rarely call themselves “programmers”. They are “system administrators” or “scientists” or “accountants” and so on. In other words, they invariably have a non-programming role that programming just so happens to help them with.

Second, “programming” is both a help and a hindrance to them. If you’re trying to crunch a load of data from astronomy experiments, you probably need to program a computer to deal with the sheer quantity of data. However, the time spent programming is a cost to be born in pursuit of a bigger task: the less time you spend programming, the more time you spend on the thing you care most about.

These two factors combine in an interesting way. In general (though there are exceptions), the programs that programmers in this category write tend to be smaller than those in the “narrow” category. Typically, the people involved also put less effort into learning exotic tooling [4] and writing “better” programs than in the “narrow” category. This has some interesting knock-on effects. For example, those of us in the “narrow” category are often obsessed with making software as reusable as possible; in the “midpoint” category, there tends to be a lot more “copy, paste, and tweak”. It’s easy for people like me to dismiss this as sloppy workmanship, but that misses the point: people in this category necessarily have to reserve much (probably most) of their time and mental bandwidth for the non-programming aspects of their role.

The “broad” definition

I can still remember the first time that I saw a CV that claimed one of the programming languages this person knew was HTML. I scoffed: HTML isn’t a programming language! After all, all one is doing with it is writing down how text and images should be formatted for humans to read — that’s a long way from doing the sort of fiddly control flow manipulation that I associate with programming!

I’ve now lost track of how many people I’ve seen claim HTML as one of the programming languages they know. I’ve also encountered a growing number of people who talk about “programming” HTML (by which they mean HTML and CSS, though not JavaScript unless stated explicitly). The latter group are interesting as virtually none of them would claim that they could program non-HTML/CSS software and, indeed, I don’t think I’ve ever heard any of them call themselves a “programmer” even when they say they’re “programming”.

Before I start to sound too snobby, it’s now clear to me that creating a good modern web page is a difficult task, which is why my own website is both basic and ugly. Whenever I want a webpage to do something even moderately complex, such as display nicely on a mobile device, I either spend inordinate time on the task, or plead with someone for help. For some reason, I struggle to make sense of the way that CSS elements interact with each other, and it’s not like I’ve only spent 5 minutes trying to understand it. Clearly this stuff is more complex [5] than I once gave it credit for!

It seems to me that what makes programming in this category (which one also sees in some “domain specific languages”) different to the previous two categories is that it has little or no notion of “time”. In most of the programming I do, I have to think about “if X then happens then Y happens which means that Z can then happen”. Put formally, the system continually changes state (in the sense of “statemachine” state), and I have to reason about each state individually. In contrast, one can generally think of HTML as occupying a single state. That means that the reasoning programmers in this group have to do about the system state is generally much more restricted in nature than those in the “narrow” definition from earlier. This isn’t a bad thing — anyone who’s tried to write a GUI in a fully-fledged programming language will know that the flexibility this offers comes with costs that can be borne repeatedly over time!

Summary

A pithy summary of the three categories, in order, are:

• Programmers who always call themselves programmers, call the activity they engage in programming, and who write arbitrarily complicated programs.
• Programmers who generally don’t call themselves programmers, generally call the activity they engage in programming, and who tend to write slightly less complicated programs.
• Non-programmers who don’t call themselves programmers but who sometimes call the activity they engage in programming.

These categories are, inevitably, too simplistic to capture the messiness of the real world. The categories are better thought of as highlighting portions of a sliding spectrum rather than as discrete buckets. They are also not mutually exclusive: any given individual might find themselves, at different points, inhabiting different categories. Still, despite these limitations, I hope the high-level point is useful.

Exactly where you consider the cut-off point for a “programmer” or for “programming” is an individual choice. I have my own preferences, but it doesn’t worry me if you use a different definition. I also hope that I’ll now be aware enough to realise how you’re using the term, so that you and I will communicate more effectively!

Acknowledgements: thanks to Martin Berger, Lukas Diekmann, and Hillel Wayne for comments.

Footnotes

Comments