What is a program?

What is a program?

This is the first video in this course. And we begin with the most fundamental question.

Not "how do I write a program." Not "what language should I use." But: what is a program? What are we actually making when we write code?

This might seem like a simple question. But most programmers cannot answer it clearly. They know how to write code. They do not know what a program truly is.

Today, we will build that understanding.

Let us start by being honest.

If someone asks you: "What is a program?" — what do you say?

You might say: "It is code." But that is not an answer. That is just a different word for the same thing.

You might say: "It is instructions for a computer." That is closer. But it is still incomplete. Instructions to do what? How? Why?

You might say: "It is software." Again, just another word.

The problem is this: we use programs every day. We write programs. We debug programs. But we rarely stop to think about what a program actually is.

And this matters. Because if you do not have a clear mental model of what you are building, you will make mistakes. You will misunderstand problems. You will write code that does not do what you expect.

So let us build that mental model. From the ground up.

First, let us clear away some confusion.

A program is not code. Code is how we write a program. Code is the representation. But the program itself is something more fundamental.

Think of it this way. A recipe is not the ink on the page. The ink is how we write the recipe down. The recipe itself is the idea — the sequence of steps, the relationships between ingredients and actions.

Similarly, a program is not the text in your editor. That text is just how we express the program. The program itself is the idea underneath.

This is an important distinction. Because the same program can be written in many different languages. The code looks different. But the program — the fundamental idea — remains the same.

So if a program is not code, what is it?

A program is a description of computation. Let that sentence sit for a moment.

What is computation? Computation is the process of transforming data. You start with some data. You apply some rules. You end with different data. That is all computation is.

A program is the description of those rules. It tells the computer: when you receive this data, do these things to it, and produce that result.

This is the mental model I want you to hold. A program is not mysterious. It is not magic. A program is simply a precise description of how to transform data.

Every program you have ever used follows this same pattern. From a simple calculator to a complex operating system. Data in. Transformation. Data out.

Now I need to introduce an important term. State.

State is a snapshot of system data.

Let me explain what that means.

At any moment, a running program has data. Variables hold values. Memory contains information. Files store content. All of this data, at one specific moment, is the state.

Think of state as a photograph. A photograph captures one instant. State captures one instant of all the data in your program.

Before your program runs, there is some initial state. Maybe it is the input the user provided. Maybe it is data read from a file. Maybe it is just some starting values.

After your program runs, there is some final state. The output. The result. The transformed data.

A program, then, describes how to get from the initial state to the final state.

This is the core of the mental model. State in. Program runs. State out.

The initial state is transformed into the final state. That transformation is what the program describes.

How does a program describe this transformation?

Through instructions.

An instruction is a single step. One small action. One small change.

A program is made of many instructions. These instructions are organized. They have an order. They have relationships. Some instructions depend on others. Some instructions repeat. Some instructions only happen under certain conditions.

But fundamentally, each instruction describes one small transformation. Take this piece of data. Do this thing to it. Store the result.

When you write code, you are writing instructions. Each line of code, each statement, describes one step in the transformation from initial state to final state.

The computer executes these instructions one at a time. It follows the description you provided. It transforms the state according to your rules.

This is what a program is. A collection of instructions that describe how to transform state.

Let us make this concrete with the simplest possible example.

Imagine a program that adds two numbers.

What is the initial state? Two numbers. Let us say: five and three.

What is the final state? One number. The sum. Eight.

What does the program describe? How to transform two numbers into their sum.

The instruction is simple: take the first number, add the second number, produce the result.

That is the entire program. Initial state: two numbers. Instruction: add them. Final state: the sum.

Every program, no matter how complex, follows this same pattern. The initial state might be enormous. The instructions might number in the millions. The final state might be complicated. But the fundamental structure is the same.

Data in. Transformation described by instructions. Data out.

Let me state the pattern clearly.

Every program has three parts.

One: initial state. The data that exists before the program runs. The input. The starting point.

Two: instructions. The description of how to transform the data. The rules. The steps. The logic.

Three: final state. The data that exists after the program runs. The output. The result.

This is the mental model. This is what a program is.

When you write a program, you are describing a transformation. You are saying: given this initial state, apply these instructions, and produce this final state.

When you run a program, the computer follows your description. It starts with the initial state. It applies each instruction. It produces the final state.

When you debug a program, you are finding where the transformation went wrong. The initial state was correct. The final state was not what you expected. So somewhere in the instructions, something is not right.

This mental model helps you understand, write, and fix programs. Keep it in your mind.

Let us see this in code. We will use Kotlin.

Imagine a simple function called "add" that takes two integers as input and returns their sum.

This is a function. It describes a transformation.

What is the initial state? Two integers, named a and b.

What is the instruction? Add them together.

What is the final state? The result of the addition.

The function takes initial state as input. It applies the instruction. It returns the final state as output.

Now imagine a main function. It creates two values: x is five, y is three. Then it calls "add" to compute their sum. Then it prints the result.

What is happening here?

First, we establish initial state. We create two values: x is five, y is three.

Then we apply a transformation. We call "add," which transforms those two numbers into their sum.

Then we produce output. We print the result.

Initial state: two numbers. Instructions: add them, print the result. Final state: the sum has been computed and displayed.

This is a complete program. And it follows the pattern exactly.

You might think: "This is too simple. Real programs are more complex."

Yes, real programs have more instructions. Yes, real programs have more data. Yes, real programs have loops and conditions and functions and objects.

But the fundamental pattern does not change.

A web browser? Initial state: a URL. Instructions: fetch the page, parse the HTML, render the content. Final state: a displayed web page.

A video game? Initial state: the game world. Instructions: read player input, update positions, check collisions, render graphics. Final state: the next frame of the game.

A banking system? Initial state: account balances. Instructions: validate the transaction, update the balances, record the history. Final state: new account balances.

The scale is different. The complexity is different. But the pattern is the same. Data in. Transformation. Data out.

This is what a program is.

Why does this mental model matter?

Because it gives you clarity.

When you understand that a program is a description of transformation, you can think about programs more clearly.

You can ask: what is the initial state? What data do I start with? What assumptions am I making?

You can ask: what is the final state? What result do I want? What should be true when the program finishes?

You can ask: what transformation do I need? How do I get from here to there? What instructions will produce the correct result?

These are the fundamental questions of programming. And they all come from this mental model.

When something goes wrong, you can ask: was the initial state correct? Were the instructions correct? Was the final state what I expected?

This gives you a framework for thinking. Not just writing code, but thinking about code.

And thinking clearly is what separates good programmers from everyone else.

Let us summarize what we have learned.

A program is a description of computation. It describes how to transform data from an initial state to a final state.

State is a snapshot of system data. It is all the data in your program at one moment.

A program consists of instructions. Each instruction describes one step in the transformation.

The pattern is always the same: initial state, instructions, final state. Data in, transformation, data out.

This is true for every program. From the simplest script to the most complex system. The scale changes. The pattern does not.

Hold this mental model in your mind. It is the foundation for everything that comes next.

A program is a description of how to transform state. That is what we are building when we write code.