What Is Programming?

Core path: 30 minutes

What are we actually doing when we write code?

Start with a problem, not Python

Before there is Python, there is a problem somebody wants a machine to solve.

Imagine four marked floor positions arranged like this:

• A is where the robot starts.
• B is the next position to the right.
• C is the corner where the robot must turn.
• D is the goal directly below C.

The letters are positions on the floor. They are not commands. The robot starts on A facing right. Its job is to move across B and C, turn right at C, move down to D, and stop.

Run the model once without touching Step. Then reset it and step through one instruction at a time.

Notice something important: TURN RIGHT does not move the robot to a new position. It changes the robot's direction while it stays on C. The next MOVE FORWARD means something different because the robot is now facing a different direction.

A human can look at the floor and say:

Go over there, turn at the corner, and stop at the bottom.

Another human can probably fill in the missing details.

A computer cannot safely do that. "Over there" is not a position. "At the corner" assumes the machine already knows which corner matters. "Stop at the bottom" assumes it can identify the goal from context.

For the robot, we need something closer to:

MOVE FORWARD
MOVE FORWARD
TURN RIGHT
MOVE FORWARD
STOP

Now every step has a specific meaning.

That sequence is an algorithm.

An algorithm is an ordered set of steps for solving a problem or completing a task. Algorithms exist outside programming: recipes, evacuation procedures, troubleshooting checklists, assembly instructions, and driving directions can all be algorithms.

The useful part is not the fancy word. The useful part is that we took an intention that existed in somebody's head and turned it into steps another system can follow.

Precision changes the result

Suppose a recipe says:

Cook the chicken until it is done.

A person with experience might make that work. The instruction still leaves a lot undefined.

Now compare it with:

Cook until the thickest part reaches an internal temperature of 165°F.

The second instruction gives us something we can actually test.

Programming works the same way. "Make the score high" is vague. score >= 100 is testable. "Move over there" is vague. MOVE FORWARD means one defined action.

This is one of programming's first red-pill moments: the computer you imagine in your head and the computer that is actually executing instructions are not always the same machine.

The gap between those two is where a surprising number of bugs live.

The computer does not receive your intention

A beginner often looks at broken code and thinks, "But it knows what I meant."

It does not.

The computer receives instructions, data, and whatever state already exists in the system. Your intention is not secretly transmitted along with the code.

If an instruction is missing, ambiguous, or wrong, the machine may:

• stop with an error;
• keep running and produce the wrong result; or
• do exactly what you wrote while making it painfully obvious that what you wrote was not what you intended.

That last one is going to happen a lot.

The goal is not to become afraid of mistakes. The goal is to get comfortable tracing the difference between what you expected and what actually happened.

So where does Python enter the picture?

Computers ultimately operate using low-level machine instructions represented as bits. Humans generally do not want to build ordinary applications by writing raw machine instructions directly.

Programming languages give us a more usable way to describe computation.

Python is one of many languages. Others include JavaScript, Java, C, C++, Rust, and Go. Different languages make different tradeoffs. C gives developers very direct control over memory. JavaScript is deeply tied to the web platform. Rust puts a lot of effort into catching certain memory-safety problems before software ships.

We are using Python because it lets us focus on the ideas behind programming without making every first step a fight with punctuation and low-level memory details.

Python still demands precision. It just gives us a cleaner surface to learn on.

Source code is the written instruction

When you write:

print("Robot online")

you are writing source code.

Source code is the human-readable text that describes what the program should do. It is not the program actively running. A file such as hello.py can sit on disk for a week doing absolutely nothing.

Think about the difference between a recipe card and a meal. The recipe contains instructions. Something still has to carry them out.

That "something" for our Python files is the subject of Lesson 2: the Python interpreter.

Tiny change, different instruction

Before running this, predict both lines of output:

Now run the example and compare the result with your prediction:

Run the code to see output.

The first line contains text inside quotation marks, so Python prints the characters 3 + 4.

The second line contains a numeric expression, so Python evaluates the expression first and prints the result.

Expected output:

3 + 4
7

Only a pair of quotation marks changed. The machine did something completely different.

That is the point.

Try being the machine

Read these instructions literally:

Stand up.
Turn right.
Walk three steps.
Turn left.
Touch the desk.

Now compare them with:

Move over there.
Turn when you get close.
Touch that thing.

The second set might make sense if you can see the room and infer what the writer meant. A program does not get to invent those missing definitions for us.

When you write instructions this week, keep asking one question:

What, exactly, would the machine have to know to perform this step?