What developers call themselves

I got an email from a friend this week in response to my column about coding domains that no developer understands. He wrote:

Bro, if you don’t understand Kubernetes, it just means your claim to have evolved from coder to developer is sketchy at best.

He’s known me a long time, and I’m guessing he was referring back to a long-lost review I wrote about a terrific book called Coder to Developer by Mike Gunderloy. It’s a terrific book, and up until about four minutes ago in AI time, it was totally relevant to our profession. The book covers the things that you need to be doing that aren’t actually writing code in order to be an actual professional in this business (whatever “professional” means here).

All that got me thinking about the words that we use to describe ourselves and how those words convey different meanings and purposes and layers of exactly what it means to be in the software development business.

Sockets, switches, and dials

The first computers weren’t coded with words or languages, but by manipulating physical entities to do fairly basic calculations. “Programmers” would plug wires into sockets, set switches, turn dials, and spin rotors. It was, at the time, considered “women’s work” because it was mostly clerical. But setting that aside, it was all mechanical in nature. These workers didn’t call themselves “programmers” but “operators” because they physically operated the machine. There was no separation between the machine and the logic used to run the machine. They were the same thing.

It wasn’t until the abstraction of a “computer language” came along that the term “programmer” was introduced. Programming languages allowed for a distinct separation between the logic used to execute a program and the physical device used to execute that logic. As computers became more generalized, the notion of being a “computer programmer” arose. 

Early on, computer programs were “linear” or task-bound—that is, they started at Point A and ran to Point B, most often doing calculations of some sort. Sure, they had branching, looping, and flow control, but most often the programs started with some input and produced some output. 

I remember back in high school when our programming assignments consisted of typing out the program on cards, turning those cards in to the “computer rat” in the computer lab, who would run it and neatly wrap the paper output around the cards with a rubber band. 

As an aside, I often fantasize about what you could do if you took a laptop computer in a time machine and showed the Army in 1942 an Excel spreadsheet that could calculate the ballistic tables that rooms full of people with adding machines were slowly and laboriously calculating.

Boundaries, modules, and interfaces

But systems grew more complex, the machines grew more generalized, and the software grew more varied. The notion of user interface became an issue. Code became unwieldy, reusable, varied, and intertwined. Programmers had to start thinking in terms of boundaries and modules. The interfaces between these boundaries and modules became of great concern. Versioning became a thing. Managing all of that gave rise to the notion of “software engineering.” (I personally have never liked that term. I’ve always fallen on the side that considers software development an art, not a science.) 

All of these developments have rendered the term “programmer” a bit old-fashioned. Instead, the notion of being a “software developer” arose. Thirty years ago, one might have described oneself as a “computer programmer,” but I hardly ever hear that term used by people in the business anymore. Most everyone describes themself as a “software developer” or “software engineer” these days.

These terms imply a level of knowledge and skill above the mere act of writing code. Code is still at the core, but as Gunderloy wrote in his book, there is a lot more to the job these days than writing code. Code is still at the core, but there are now layers of abstraction and complexity on top that render the term “programmer” inadequate for describing what it is we do.

And that brings us to the point we are at today — what, exactly, does it mean to be a “software developer” now? As I have argued, it seems like the “programming” portion of that is becoming less and less prevalent. Agentic AI is starting to do all the “clerical” work of software development. It writes the code. At most, we will be spot checking what it writes, but let’s face it, even that spot checking will go by the wayside. 

Operator. Programmer. Developer. Engineer. What we call ourselves has changed over the years, as has exactly what it is that we do. At every step, it took a while for the function to get a new title. I wonder when we’ll come up with a new word to describe what it is that we do when wielding our coding agents. I’m pretty sure we eventually will.