The Python What Programming Actually Is 📜
Programming is writing instructions for something that cannot infer, assume, or use common sense. It is less like maths and more like writing very careful stage directions for an actor who takes everything literally.
The peanut butter sandwich problem
There is a classic classroom exercise. Children write instructions for making a peanut butter sandwich, and the teacher follows them exactly. "Put the peanut butter on the bread" gets the teacher pressing an unopened jar onto an unopened loaf. The room dissolves. A lesson is learned.
That teacher is the computer. Programming is the skill of writing instructions so complete and so unambiguous that a determined literalist cannot get them wrong. It is not about being clever. It is about being precise, which is a different and much more learnable skill.
Ah, but the machine is not merely literal, is it? It is hostile in its literalism. It will find the one interpretation you did not intend and commit to it entirely, the way a bad actor finds the one reading of a line that ruins the scene.
An algorithm is just a plan
The word sounds like a magic spell. It means "a list of steps that finishes". You use them constantly:
- A recipe is an algorithm.
- Looking up "Threepwood" in a phone book by opening the middle and halving your way down is an algorithm. Computer scientists call it binary search and are very proud of it.
- Your morning routine is an algorithm, complete with a conditional ("if it is raining, take the coat").
Programming is: work out the steps (the hard part, done in your head or on paper), then write them in a language the machine accepts (the easy part, which is what this course teaches).
If you have ever set up a crafting queue in a game, written a macro, built a redstone contraption, or configured a spreadsheet formula, you have programmed. You just did not have to fight anyone about semicolons.
The three moves
Nearly every program ever written is built from three moves, and Level 1 of this course is basically a tour of them:
| Move | What it means | In English |
|---|---|---|
| Sequence | Do this, then this, then this | "Open the door, walk in, close the door" |
| Selection | Choose between paths | "If it is locked, use the key" |
| Repetition | Do it again | "Keep knocking until someone answers" |
That is the entire toolkit. Add a way to store values (variables) and a way to bundle steps under a name (functions) and you can, in principle, write anything: a game, a browser, a bank, a chatbot. Everything else is convenience, speed and taste.
Why languages exist
The CPU wants numbers. Humans want words. A programming language is the negotiated settlement. Here is the same idea at three altitudes:
| Level | Looks like | Who writes this |
|---|---|---|
| Machine code | 10110000 01100001 | Nobody, on purpose, since about 1955 |
| Assembly | mov al, 0x61 | Compiler authors, chip people, demoscene heroes |
| Python | letter = "a" | You, in about ten minutes |
Two ways exist to get from the top row to the bottom row:
- Compiled languages (C, Rust, Go) translate your whole program into machine code ahead of time. You get a standalone file that runs blisteringly fast. You pay by waiting for the compile and by having to satisfy the compiler first.
- Interpreted languages (Python, JavaScript, Ruby) keep a translator running alongside your program, working through it line by line. You get instant feedback and enormous flexibility. You pay in speed.
Python is interpreted, which is why you will be running real code inside a web page thirty seconds from now, with nothing installed. It is also why our sister school's language, Rust, will run circles around it in a benchmark. Both facts are fine. They are the same trade seen from two sides.
Note the honest framing: not 'Python is slow' but 'Python trades machine time for your time'. Your time costs more than the computer's, right up until the moment it does not, and knowing where that line sits is most of what senior engineers are paid for.
What programmers actually do all day
Not typing. Typing is maybe fifteen minutes of it. The real job:
- Reading. Understanding code you did not write, including your own from three months ago, who was a stranger.
- Naming. Deciding what to call things so the next person understands. Famously one of the two hard problems in computer science.
- Debugging. Finding out why the thing you were certain about is false. This is the actual craft, and Lesson 10 starts teaching it properly.
- Deleting. The best code is the code you did not have to write.
Be the computer
Here are instructions for brushing your teeth. Follow them with maximum literal-mindedness and find at least three ways they go wrong:
- Pick up the toothbrush.
- Put toothpaste on it.
- Brush your teeth for two minutes.
- Rinse.
Reveal solution
A few of the many: the toothpaste tube is closed, and nothing said to open it. 'Put toothpaste on it' does not say how much, so you use the whole tube. 'Brush your teeth' does not say to put the brush in your mouth. 'Rinse' does not say rinse what, so you rinse the cat.
Every one of those is a bug you will genuinely write this year. The mistake is never stupidity. It is assuming shared context with something that has none.
Spot the three moves
Describe how a vending machine works in five or six steps. Then label each step as sequence, selection or repetition.
Reveal solution
One reasonable answer:
- Wait for a coin. (repetition: keep waiting)
- Add the coin's value to the total. (sequence)
- If the total is less than the price, go back to step 1. (selection, then repetition)
- Wait for a button press. (repetition)
- If that slot is empty, refund and stop. Otherwise drop the item. (selection)
- Return the change. (sequence)
You have just designed a program. The rest of this course is notation.