Before we can talk about computer programming, we should probably talk about the word program itself—because it had a perfectly respectable career for centuries before anyone ever plugged in a monitor.

The Programme at the County Fair

If you've ever been to a county fair—and if you grew up anywhere in America, you probably have—you may remember getting a printed sheet at the entrance. The programme. It told you what was happening, where, and when. The horse judging at 10. The pie contest at noon. The square dance at 7. It was, in the most literal sense, a plan: a sequence of events, laid out in order.

That's really all a program has ever been. A plan. An ordered list of things that are going to happen. The word comes from the Greek programma—"a written public notice"—and for most of its history, that's exactly what it meant. Here's what's going to happen. Follow along.

The Program at the Concert Hall

Same idea, fancier venue. When you attend a symphony or a play, the usher hands you a program. It tells you the order of the pieces, the names of the performers, maybe a note from the conductor about why he chose this particular tempo for Beethoven's Fifth's Second Movement. The program doesn't perform the music. It describes what's going to be performed.

This distinction matters more than you might think. A program is not the thing itself. (It's the map, not the territory, as they say.) It's the description of the thing. The recipe, not the cake. Keep that in the back of your mind—it's going to come up again.

Enter the "Programmer"

In the early days of electronic computing, a "programmer" was the person who set up the machine to perform a specific sequence of operations. On the earliest machines, this meant physically plugging cables into a patch panel—literally rewiring the computer for each new task. The "program" was the configuration: the plan for what the machine would do, expressed in copper and plug connections. My co-worker Felix from the Florida State Division of Forestry had been one of these programmers; it gave him a nervous breakdown and he quit to become a forester, thinking that computers would "never find him there". He was wrong.

By the 1950s and '60s, programming had moved from patch panels to punch cards and typed instructions. But the core idea hadn't changed at all. You were still writing a plan—a sequence of steps—for the machine to follow. The only difference was that now you could express that plan in something closer to human language, instead of in wires.

And the programmer? Still the same person, fundamentally: someone who could break a problem down into steps small enough for a very fast, very literal-minded machine to follow. The machine wouldn't guess what you meant. It wouldn't fill in the gaps. It would do exactly what you told it to, and heaven help you if what you told it was wrong.

When the Job Started to Blur

For the first couple of decades, the line was pretty clear. Programmers wrote code. Everybody else did everything else. But as computers moved from mainframes to desktops, the edges started getting fuzzy.

I saw this firsthand in the late 1980s, working on a government project called FTS-2000. The project employed graphic artists to design the user interface—the dialog boxes, the menus, the buttons. Sounds reasonable, right? Artists are good at making things look nice.

The problem was, these artists did their work on Apple Macintoshes. And the software we were building ran on Windows. The dialog boxes they designed were serviceable—but completely impossible to build. They had rounded corners where Windows only did square. They used fonts we didn't have. They put buttons in places the Windows toolkit wouldn't allow. It was like having an architect design a house under the assumption it would be constructed of Legos.

A programmer wouldn't have made that mistake. Not because programmers are smarter than artists, but because a programmer understands the medium. When you write code, you learn very quickly what the platform can and can't do. An artist working in a different environment doesn't have that constraint, and without it, they're designing in a vacuum.

So Who's a Programmer Now?

Fast forward to today, and the question gets even thornier. Is a web designer a programmer? They write HTML and CSS, which are certainly languages, but the result is certainly not a program in the county-fair sense—a plan that the browser follows. While HTML (hypertext markup language) proceeds in a straightforward top-to-bottom way, it doesn't have loops, or conditionals, or variables. It doesn't make decisions. It's a description, not a set of instructions. And CSS (cascading style sheets) only say how to format things, not what to do with them. And yet, because programming itself has evolved to include non-linear execution, those of us making websites do think of ourselves as programmers, and we do include those aspects of it, part of our jobs.

What about someone who writes JavaScript? That's definitely programming—it's got all the hallmarks. Variables, loops, functions, the works. But plenty of JavaScript developers would bristle at being called "programmers." They're "front-end developers" or "UX engineers" or some other title that distances them from the image of a person in a basement staring at green text on a black screen. Nevertheless, they are programmers as far as I am concerned.

And now—here in 2026—we've got people who build entire applications by describing what they want to an AI. No code written by human hands at all. Is that programming? In one sense, absolutely: you're creating a plan, a set of instructions, for a machine to follow. You're just doing it in English instead of Visual Basic or vb.net. Still, in another sense, it's something entirely new—because the "machine" you're instructing is itself making decisions about how to implement your plan. That's never happened before.

The Thread That Connects It All

Here's what I keep coming back to, after all these years. Whether you're printing a programme for the county fair, plugging cables into an ENIAC, writing COBOL on punch cards, or chatting with an AI about what your web app should do—you're doing the same fundamental thing. You're creating a plan. You're describing, in whatever language is available to you, a sequence of things that should happen.

The tools change. The languages change. The level of abstraction changes—dramatically. But the core activity? That's been the same since some clerk in ancient Greece wrote down the order of events for the Olympic Games.

Which means, in a sense, we've all been programmers. We just didn't know it yet.