Telling a machine
exactly what to do.
thinking like a programmer.
An algorithm is a recipe.
When you make a cup of tea, you follow a set of steps. Fill the kettle. Switch it on. Put a teabag in the mug. Wait for the water to boil. Pour it in. Wait again. Lift the bag out. Add milk. You don't think of this as anything special — it is merely what you do. But you have, without noticing, followed an algorithm: a precise, ordered set of steps that takes you from a problem (no tea) to a result (tea).
The word looks technical, but the idea is old and ordinary. An algorithm is nothing more than a list of instructions, in the right order, that solves a problem. A recipe is an algorithm. The directions a friend gives you to their house are an algorithm. The steps for tying a shoelace are an algorithm. The only thing that makes a computing algorithm different is who reads it at the end — a machine, not a person.
The word itself comes from a person. A Persian scholar named al-Khwārizmī, working in Baghdad around the year 820, wrote a book of step-by-step methods for solving problems with numbers. When his name was later translated into Latin, it became Algoritmi — and the methods he described became known as algorithms. So every time you use the word, you are quietly naming a mathematician who has been dead for twelve centuries.
The steps of an algorithm have to come in the right order. Pour the water before the kettle boils and you get a cold cup of leaf-water. Add the milk before the teabag and the tea barely brews. Same steps, wrong order, wrong result. Order is not a detail — it is part of the algorithm itself.
The first person to write what we'd now call a computer program was Ada Lovelace, in 1843 — a full century before any computer existed to run it. She wrote a step-by-step method for a machine that was never finished, the Analytical Engine, and saw further than its inventor: she guessed a machine like it might one day handle music and pictures, not only sums.
A computer has no common sense.
Here is the part that trips everyone up at first. When you give a person an instruction, they fill in the gaps. Tell a friend "make me a jam sandwich" and they know what you mean — they fetch the bread, the knife, the jam, and quietly do all the obvious bits you never said. A computer does none of that. It has no idea what is obvious. It does exactly, only, and precisely what you tell it — and nothing more.
Imagine writing the algorithm for "make a jam sandwich" and handing it to a machine that takes every word literally. Watch how it goes when you leave the gaps a human would fill:
You write: "Put jam on the bread."
The machine puts the unopened jar of jam on top of the unopened bag of bread. You never said open them. You never said use a knife. You never said which side.
You write: "Spread the jam."
The machine has no jam out of the jar to spread, so it stops, confused. Or it smears the closed jar across the table. Both are faithful to what you actually said.
This is the heart of the lesson. The machine is not being difficult — it is being precise. The fault is in the instructions, not the follower. A programmer's real skill is imagining a follower with no common sense at all, and writing steps so complete and so clear that even that follower cannot go astray. Precision is everything.
When you write any algorithm, read each step back and ask: could someone who knows nothing follow this without guessing? If a step relies on the reader "just knowing" something, that step is not finished. Break it down further until nothing is left to chance.
"Make a jam sandwich" is a real exercise used in workshops and at Google alike, where someone acts out the part of the literal-minded machine. Everyone laughs as they squash a closed jar onto a bagged loaf — and then no one ever forgets why a computer needs every single step spelled out.
Every program is built from three things.
This is one of the quietly astonishing facts of computing. No matter how vast a program is — a game, a banking system, the software flying a plane — it is built from only three ways of arranging instructions. Learn these three and you have the grammar of every program ever written.
Steps that run in order, one after another, top to bottom. Boil kettle, then pour, then stir. The plainest block — and most of any program is only this.
A decision. If something is true, do one thing; otherwise do another. If the kettle has boiled, pour; if not, wait. This is how a program chooses.
A loop — repeating steps until a condition is met. Keep stirring while the sugar hasn't dissolved. Saves you writing the same step out a hundred times.
Look back at the tea-making algorithm and you can spot all three. Most of it is sequence — fill, switch on, pour. "Wait for the water to boil" hides an iteration: keep checking while it has not yet boiled. And "add milk if you take milk" is a selection: a decision based on a condition. Three blocks, endlessly combined.
Selection is written with if and otherwise (programmers say else). Iteration is written with while or repeat. Sequence needs no special word at all — it is one line after the next. You'll see all three in the pseudocode further down.
Tap each card — which building block is it?
The endless loop has a name programmers dread: the infinite loop. If a loop's stopping condition can never be true — "keep stirring while the water is wet" — the program runs forever and freezes. Many of the bugs that make a computer "hang" are nothing more than a loop that forgot how to stop.
Two moves for big problems.
A whole program can feel too big to write. The way through is two habits of mind that programmers lean on constantly — together they're called computational thinking, and they work as well on packing for a trip or planning a party as they do on code.
Decomposition
- Break a big problem into small parts you can solve one at a time.
- "Tidy my room" becomes: clear the floor, make the bed, sort the desk, empty the bin.
- Each small part is far less frightening than the whole — and you can finish them in any order that suits you.
Abstraction
- Ignore the detail that doesn't matter for the problem in front of you.
- A map of the Underground shows the order of stations, not the real twisting tunnels — the rest is left out on purpose.
- Keeping only what matters is what makes a hard problem small enough to hold in your head.
Decomposition and abstraction work together. You decompose a problem to make it smaller; you use abstraction to throw away the bits that don't matter inside each piece. The London Underground map is the classic example of abstraction — Harry Beck drew it in 1931 like an electrical circuit, straight lines and tidy angles, deliberately wrong about real distances and directions. It is far easier to use precisely because it leaves out the truth you don't need.
To abstract something, in its oldest sense, is to "draw away" from it — to step back until the clutter blurs and only the shape remains. A good abstraction is not a lie; it is a careful choice about what to leave out.
Harry Beck was paid only five guineas — about five pounds and twenty-five pence — for designing the Underground map, in his spare time, as an out-of-work draughtsman. It is now one of the most copied pieces of design on Earth, and its style has been borrowed for transit maps in cities all over the world.
Drawing an algorithm before you build it.
Programmers rarely write code straight away. First they plan, in a form a human can read and check. Two tools do this job. A flowchart draws the algorithm as boxes joined by arrows. A piece of pseudocode writes it as plain, code-like English that doesn't fussy about the exact rules of any one language. Both let you find your mistakes before a machine does.
A flowchart uses a small set of agreed shapes. An oval marks the start and the end. A rectangle is a process — a step you carry out. A diamond is a decision — a question with a yes branch and a no branch. Here is the "is it raining?" decision a person makes before leaving the house, drawn properly:
The same algorithm written as pseudocode reads almost like English, but lines up the three building blocks so a programmer can see them at a glance:
# decide whether to take a coat get ready to go out IF it is raining THEN take a coat ELSE leave the coat END IF leave the house
Finding the largest number in a list.
Here is a real problem a computer is asked all the time: given a list of numbers, find the biggest one. You do it by eye in a flash, but watch how you'd write it for a follower with no common sense. The trick is to keep a "best so far", look at each number in turn, and update the best whenever you meet a bigger one. That uses all three building blocks at once.
# find the largest number in a list best ← first number in the list FOR EACH number IN the list IF number > best THEN best ← number END IF END FOR output best
Read it slowly. The best starts as the very first number — a sensible guess. Then the loop (iteration) walks through every number in turn. Inside the loop, a decision (selection) asks: is this one bigger than my current best? If it is, the best is replaced. When the loop runs out of numbers, whatever is left in best is the answer.
Let's trace it by hand on the list [4, 9, 2, 7], the way a programmer checks their own work. Reveal each step and predict what best holds before you move on:
Walking through an algorithm by hand, one step at a time, keeping track of what each value holds — programmers call this a trace or a "dry run". It is the surest way to catch a mistake before the machine ever runs the code, because you are being the precise, literal follower yourself.
What is an algorithm?
The jam sandwich.
Name the building block.
Fresh one. "If the light is red, stop; otherwise, go." Which building block is this?
Which shape is the decision?
Reading the worked example.
Decomposition.
The Underground map.
Trace it yourself.
Fresh one. Trace the same algorithm on [6, 2, 9, 4]. What does it output?
Write the steps for a machine with no common sense.
Pick one everyday task — brushing your teeth, making toast, crossing a road safely, feeding a pet. Write the algorithm for it as numbered steps, as if for a follower who takes every word literally and knows nothing. Try to slip in at least one decision (an if) and, if you can, one loop (a repeat or while). Six to ten steps is plenty.
Number each step. Imagine handing it to the jam-sandwich machine — where would it trip up? That's the gap to close.
On your algorithm, Florence
strong Your steps are in a clear order and each one does a single thing — that's exactly the shape a machine can follow. Putting "if the toast is pale, put it down again" in as a decision shows you've spotted where a choice belongs, rather than assuming it.
try this One step still leans on the follower "just knowing" — "get the toast ready" hides three or four smaller actions. Pick the step that hides the most and break it into the little moves it really contains. That's decomposition doing its quiet work.
to add A loop would lift this further. Anywhere you'd naturally say "keep doing it until…" — keep checking the toast until it's golden — is an iteration waiting to be written. One repeat is plenty, and the next task you plan will come easier for it.
The first programmer.
Long before there was a machine to run a program, someone wrote one. Ada Lovelace was an English mathematician, born in 1815, the daughter of the poet Lord Byron — though she never knew him. Her mother, fearing she'd inherit her father's wildness, had her schooled hard in mathematics, which was unusual for a girl of her time.
In the 1840s she worked with the inventor Charles Babbage on his design for the Analytical Engine — a vast mechanical computer of brass cogs and punched cards that was never built. In her notes on it, she wrote out a step-by-step method for the machine to calculate a sequence of numbers. That method is widely held to be the first computer program ever written.
She also saw something Babbage didn't. He thought of his engine as a calculator for numbers. Ada realised that if a thing could be turned into symbols, the machine could work on it — so one day a machine might compose music or make pictures, not only add up. She was imagining software, and what it could become, a hundred years early. The computing world now keeps an Ada Lovelace Day each October in her name.
What is an algorithm?.
Notice how an algorithm is a set of steps — and why the order of those steps matters so much.
The words from today.
- Algorithm
- A precise, ordered set of steps that solves a problem or completes a task.
- Sequence
- Instructions carried out in order, one after another, top to bottom.
- Selection
- Choosing between paths based on whether a condition is true — an if/then/otherwise decision.
- Iteration
- Repeating one or more steps until a condition is met — also called a loop.
- Decomposition
- Breaking a large problem into smaller parts that can be solved one at a time.
- Abstraction
- Ignoring the detail that doesn't matter for the problem, so you can focus on what does.
- Pseudocode
- Plain, code-like English for planning an algorithm, without the strict rules of a real language.
You can think in steps now.
You learned what an algorithm is, and why a machine needs every step spelled out. You met the three building blocks every program is made from — sequence, selection, iteration. You drew a flowchart, read pseudocode, and traced an algorithm by hand to find the largest number in a list. Next time you make a cup of tea, notice the algorithm you're following. Florence, this is computing.
Note — a main teaching video for this lesson is to be added centrally; the sandbox could not verify an institutional source at build time.