What Is a Program? Human Knowledge Captured in Instructions

In the previous article, we discovered that the CPU spends its entire life doing one thing: fetching an instruction, decoding it, executing it, and moving immediately to the next. Billions of times per second, without pause. But that explanation left a question hanging in the air — what exactly is the CPU fetching? Where do these instructions come from? Who wrote them? And what are they, really? The answer to all of that is a program.

Every morning, somewhere in an office, someone opens a spreadsheet, downloads a report, updates a set of numbers, checks for errors, saves the file, and emails it to a client. Then they do it again tomorrow. And the day after that. After a few weeks, a quiet frustration sets in — not because the work is hard, but because it's identical. Every click the same. Every step the same. Every outcome the same. And somewhere in that frustration, a question forms: why can't the computer just do this? That question is older than modern computing. And the answer to it is a program.

From Knowledge Inside a Head to Instructions on a Machine

Suppose a new colleague joins your team and you spend a week showing them how to handle a process. At first they ask questions — why this option, why that field, why escalate this case and not that one. And as you answer, you start to notice something uncomfortable: most of what you know exists only inside your head. Your experience isn't written down. Your judgment isn't documented. Your decisions are invisible to everyone but you.

Now imagine you want a machine to perform that same work. Suddenly "just knowing how to do it" isn't enough. You have to explain every step, every rule, every condition, every exception — in a form precise enough that nothing can be misunderstood. You have to take knowledge that lives inside a human mind and convert it into instructions a machine can follow without interpretation. That conversion is the birth of a program. And it's harder than it sounds, because machines cannot infer. They cannot assume. They cannot fill in the gaps. Every gap you leave becomes a failure.

What a Programmer Actually Does

Most people think a programmer's job is to write code. Code is only the final step. Before a single line is written, something more important happens: the programmer has to fully understand a process — its patterns, its rules, its edge cases, its exceptions — well enough to leave nothing to interpretation. Only then can that understanding be expressed in a language a machine can execute. The code is the record of that understanding. The thinking came first. This is why the hardest part of building software is rarely the programming. It's the clarity required before programming begins.

The Most Obedient Employee in the World

One of the most useful ways to think about a program is as an employee with a very specific set of qualities. This employee never gets tired, never gets distracted, never skips a step, and never takes a day off. They follow every instruction exactly as written, every single time, at a speed no human can match. On the surface, this sounds ideal. But there's a catch that changes everything: this employee never questions the instructions. Never asks whether they still make sense. Never notices when a rule has become outdated. Never improvises when something unexpected happens. If the instructions contain a mistake, they will execute that mistake — perfectly, repeatedly, at scale.

This is one of the most important ideas in computing. Programs don't create mistakes. Programs faithfully execute them. When software behaves incorrectly, the problem is almost never the machine. The problem is the instructions it was given. The machine did exactly what it was told.

What a Program Looks Like to a CPU

Here's the layer most explanations skip. When you open Excel or click a button in your CRM, it feels like the software is doing something intelligent — making decisions, responding to you, understanding your intent. But follow that action down to the CPU and the picture changes entirely. What the CPU receives is not a spreadsheet. Not a button click. Not an instruction written in plain English. It receives a sequence of operations so primitive they would seem almost absurd in isolation: load this value from this memory address, compare it to that value, jump to a different part of the program if the result meets a condition, store this result here, move to the next instruction.

Each of these operations maps directly to the Fetch-Decode-Execute cycle we explored in the previous article. The CPU fetches one instruction, decodes it, executes it, and immediately moves to the next. What you experience as "opening a file" is the CPU executing thousands of these primitive instructions in sequence — each one trivial, the combination of them producing something that feels, from the outside, like intelligent behaviour. A program written by a human — whether in Excel formulas, Python, or any other language — eventually gets translated all the way down into these primitive operations. The sophistication lives in the sequence. The CPU itself only ever does one tiny thing at a time.

Programs Free Intelligence. They Don't Replace It.

There's a misconception worth addressing directly. Programs are sometimes described as replacing human work. A more accurate framing is that they replace human repetition — and that's a meaningful distinction. Humans are not built for endless identical execution. We are built for judgment, pattern recognition, creativity, and improvement. A program handles the part of work that doesn't change. The human focuses on the part that does. In that sense, every useful program ever written represents a transfer: repetitive execution moves to the machine, and human attention moves to higher-value work. The program doesn't think. It executes. And by executing reliably, it frees the people who built it to think about something more important.

The Insight Underneath Everything

When you open Excel, your CRM, a browser, or any other tool, what you're looking at is the surface of something much older. Somewhere, someone observed a process, understood its rules well enough to leave nothing ambiguous, and translated that understanding into a sequence of instructions precise enough for a machine to follow without interpretation. The machine now executes those instructions millions of times a day, faithfully, without fatigue, without variation. A program is human knowledge captured in a form a machine can repeat forever. The screen is just where the execution becomes visible.

Where This Leads

We now understand what a program is and what it looks like all the way down to the CPU. But a new question follows: how do humans actually write these instructions? Translating human knowledge into machine instructions requires a language — one that sits between human thinking and machine execution. That language is what we'll explore next.

Next: What Is a Programming Language? The Bridge Between Human and Machine