Computers & Coding for Kids

A computer the size of a room

In 1945, at a university in Philadelphia, engineers switched on a machine called ENIAC. It weighed about thirty tonnes. It filled a room bigger than most classrooms. Inside were more than seventeen thousand glass tubes that glowed like light bulbs, and when one burned out somebody had to find it and change it.

To give it a new job, six women who worked as its programmers had to walk round the machine unplugging thick cables and setting rows of switches by hand. Changing the program could take days.

A phone fits in a hand and calculates far faster than ENIAC. Its electronics and programs differ, but both machines can follow instructions to work with information.

Key idea: Computers have got smaller and faster. What they actually do has not changed.

The four jobs

For the digital computers in this course, we will use a four-job model.

1. Input. It takes something in.
2. Storing. It keeps things to use later.
3. Processing. It follows instructions and works things out.
4. Output. It puts something out.

Look at what happens when somebody types a message. The keyboard is input. The letters get stored. The processor works out what to draw on the screen. The screen is output. Four jobs, in a fraction of a second.

Most computers do not look like computers

Go and look at a microwave. It has buttons you press, which is input. It has a little screen, which is output. It counts down and turns the turntable, which is processing and more output. There is a computer in there.

Look for examples with a grown-up. Different homes have different machines; you do not need to reach a particular total.

• The washing machine, which follows a different program for cottons and for wool.
• The television and whatever is plugged into it.
• A digital watch or a fitness band.
• The car outside, which has dozens.
• The traffic lights at the end of the road.
• The till in a shop, and the card machine next to it.
• A modern fridge, a thermostat, a doorbell with a camera.

The point: A computer is not a shape. Look for a machine that can follow a program to work with information. Input and output alone are not enough: a simple light switch has both.

What a computer is not

This part matters more than any other part of the lesson, so read it slowly.

A program works with instructions and data. Some programs recognize patterns in pictures or respond to ordinary words. Do not rely on them to understand your plan or give a correct answer. Our paper programs use exact commands we agree on.

It cannot be bored, and it cannot get tired, and it will happily do the same wrong thing four million times without once wondering whether it should stop.

What it can do is follow instructions, extremely fast and exactly. That is the whole trick.

Remember: A computer does what you told it, not what you meant. When a paper program goes wrong, compare the written commands with your plan.

Fast, but only at tiny steps

Computers solve some difficult tasks, but speed alone does not make an answer correct. Let us look at the smaller operations behind a calculation.

A processor combines operations such as these.

• Add two numbers together.
• Compare two numbers and say which is bigger.
• Move a number from one place to another.
• Go and do a different instruction next.

These are examples, not a complete list. Modern processors can carry out huge numbers of operations each second. The speed depends on the processor and the job.

Here is a scale comparison: doing one billion steps at one step per second would take more than thirty years, even without breaks. This is arithmetic, not a speed rating for every computer.

Programs and programmers

A program is a list of instructions for a computer. That is all it is. A washing machine program says fill, heat, turn, drain, spin.

A programmer is a person who writes those instructions. Programmers do not push electricity around. They write down, in a very careful language, what the machine should do in what order.

In 1843 Ada Lovelace published notes about Babbage's planned Analytical Engine, including a method for calculating Bernoulli numbers. The complete engine was not built. Her notes explored uses beyond ordinary arithmetic.

The one skill this course teaches

In this course, you will practise one useful coding skill: describe a task in clear, small steps, then check what those steps actually do.

You will practise it on paper for most of this course. Nothing here needs a computer, a website or an account. That is not a limitation. The thinking is the difficult part, and the thinking works with a pencil.

When you do want to try it on a screen, two free things are worth knowing about: Scratch, originally developed at MIT, where you drag blocks together, and Code.org, which has short puzzles. Neither is needed for this course.

Why this matters: The hard part of coding is thinking clearly, and you can practise that at a kitchen table.

Try it: is there a computer in it?

Say yes or no for each, and give a reason using input and output.

1. A pencil.
2. A microwave.
3. A wooden chair.
4. A washing machine.
5. A calculator.
6. A book.

Answers. One: no, it takes no input and follows no instructions. Two: yes, buttons in, heat and beep out. Three: no. Four: yes, you choose a program and it follows a stored list of steps. Five: yes, keys in, numbers out, and it processes in between. Six: no, though a book is a kind of storage, it never processes anything.

Common misconceptions

• Mistake: computers are clever. They are fast and obedient. People design programs, and some programs learn patterns from data. Results still need checking.
• Mistake: the screen is the computer. The screen is only output. The processing happens in a chip you never see, which in a phone is smaller than a fingernail.
• Mistake: computers never make mistakes. Wrong instructions can produce wrong results. Bad input, damaged hardware and lost connections can cause trouble too.
• Mistake: a computer knows what you meant. Do not assume a program understands your intention. Test its result against your plan.

What you now know

• ENIAC in 1945 filled a room and was reprogrammed by moving cables by hand.
• Our four-job model is input, storing, processing and output.
• Computers can be hidden in appliances. Which ones contain a computer depends on their design.
• Processors combine small operations; their speed depends on the machine and task.
• A program is a list of instructions and a programmer is the person who writes it.
• A computer does what it is told, not what you meant.

Sources

1. Wikipedia contributors. (n.d.). ENIAC. Wikipedia. en.wikipedia.org
2. Wikipedia contributors. (n.d.). Computer. Wikipedia. en.wikipedia.org
3. Computer History Museum. (n.d.). Timeline of computer history. Computer History Museum. computerhistory.org
4. Wikipedia contributors. (n.d.). Ada Lovelace. Wikipedia. en.wikipedia.org
5. BBC. (n.d.). KS2 Computing. BBC Bitesize. bbc.co.uk
6. Computer History Museum. (n.d.). Ada Lovelace. Babbage Engine collection. Source

Eleven minutes too late to help

On 18 February 2021, a NASA rover called Perseverance landed on Mars. The landing took about seven minutes: hitting the atmosphere, a parachute, a rocket powered crane, and finally wheels on the ground.

Here is the problem the engineers had. A radio signal from Mars to Earth took roughly eleven minutes that day. So by the time anyone on Earth heard that the landing had started, the seven-minute landing would already have ended about four minutes earlier: eleven minus seven is four.

Nobody could steer it. Nobody could shout stop. Its software had to use sensor readings and make programmed decisions without waiting for commands from Earth.

Key idea: Instructions have to be right before they are run, because a computer will not ask you what you meant.

The sandwich test

Here is the classic way of proving this, and it needs one child, one grown-up, bread and a jar of something spreadable.

The child writes instructions for making a sandwich. The grown-up plays a robot and does exactly what is written, in the most literal way possible.

Watch what happens to ordinary sentences.

• Put the peanut butter on the bread. The robot puts the closed jar on top of the loaf. It is on the bread.
• Open the jar. With what? The robot has not been told to pick it up.
• Spread it. Spread what, with what, on what, how much?
• Cut the sandwich in half. In which direction? Stop and ask before any unclear or unsafe action.

Use paper bread and a paper jar. The point is to spot a missing detail, not to trick or embarrass the writer.

The three faults

Bad instructions fail in three ways, and naming them makes them easier to hunt.

1. Vague. It could mean more than one thing. Put it over there. Which it? Which there?
2. Missing a step. The order jumps. You cannot spread butter before you have opened the tub.
3. Assuming knowledge. It uses a word the follower does not know. Make a cup of tea hides about thirty separate steps.

Test any instruction against those three and most problems appear at once.

The point: Check for vague wording, missing steps and assumed knowledge. These are useful checks, not a complete list of possible faults.

Rewriting a bad one

Take this instruction: put the ball in the box.

A literal follower can fail in six ways. Which ball? Which box? What if the box has a lid? Do they need to walk anywhere? What if the ball is already in a different box? What counts as in?

Here is the same instruction rewritten so a robot could do it.

1. Walk forward until you are standing beside the red ball on the floor.
2. Bend down and close your hand around the ball.
3. Stand up, holding the ball.
4. Turn to face the blue box in the corner.
5. Walk forward until the box is directly in front of your feet.
6. Hold your hand over the open top of the box.
7. Open your hand.

Seven steps for something a person does without thinking. That is normal. Coding is mostly the job of saying obvious things carefully.

Agree the words first

Real programming languages have a fixed set of words. So should your instructions.

Before you write anything, agree on the list of moves the follower is allowed to do. For a person walking on a floor grid, this works well.

• FORWARD 1 means take one step forward.
• LEFT means turn a quarter turn to the left, without moving.
• RIGHT means turn a quarter turn to the right, without moving.
• PICK UP means pick up whatever is on the square you are standing on.

Now a whole route can be written as a short list: FORWARD 2, RIGHT, FORWARD 3, PICK UP.

Notice how much argument that prevents. Turn left no longer means anything vague, because everybody agreed what it means before the game started.

Remember: Decide what your words mean before you use them. Every programming language does this.

Being precise about numbers

Walk forward is vague. Walk forward four steps is a command.

Numbers do a lot of work in instructions, and leaving them out is the fastest way to make a mess.

Try it: find the fault

For each instruction, say which of the three faults it has: vague, missing a step, or assuming knowledge.

1. Draw a house.
2. Pour the milk into the bowl, then get the milk out of the fridge.
3. Put it next to the other one.
4. Log in and check it.

Answers. One: assuming knowledge, because house means a different picture to every person, and it is also vague about size and position. Two: missing a step in the wrong order, since you cannot pour milk you have not fetched. Three: vague, with two words that point at nothing, it and the other one. Four: assuming knowledge, since log in hides several steps and check it does not say what to look for.

Why this is the whole job

People sometimes imagine programmers spend their time typing furiously. Mostly they sit and think about what exactly should happen, in what order, in cases nobody mentioned.

What if the box is full? What if the ball is not there? What if somebody presses two buttons at once? A person handles those without noticing. A computer needs to be told.

Why this matters: Writing exact instructions is not a small skill you do before the real work. It is the real work.

Common misconceptions

• Mistake: the computer will work out what I meant. Our paper robot follows agreed commands. A real program may ask questions or make guesses, but that response comes from its design. Never act out an unsafe instruction.
• Mistake: more words make it clearer. A long, chatty instruction can be vaguer than a short one. Exact beats long every time.
• Mistake: if I understand it, it is clear. You may fill in a missing detail because you already know what you meant. That is why you test instructions on somebody else.
• Mistake: real programmers do not need to be this careful. The Mars landing worked because thousands of instructions were exact eleven minutes before anybody on Earth could react.

The short version

• Instructions must be complete before they run, because the machine cannot ask what you meant.
• Bad instructions are vague, missing a step, or assuming knowledge.
• Use enough steps for the follower and available commands. There is no fixed correct number.
• Agree what your words mean before you start using them.
• Put numbers in: four steps, ten seconds, a quarter turn.
• Test your instructions on somebody who does not already know what you meant.

Sources

1. NASA. (n.d.). Mars 2020: Perseverance Rover. NASA Science. science.nasa.gov
2. CS Unplugged. (n.d.). Kidbots. University of Canterbury Computer Science Education Research Group. csunplugged.org
3. Code.org. (n.d.). Computer science for ages 5 to 11. Code.org. code.org
4. Wikipedia contributors. (n.d.). Algorithm. Wikipedia. en.wikipedia.org
5. NASA/JPL-Caltech. (2021). Mars 2020 landing press kit. Quick facts: one-way light time. Source

Shoes first

Picture putting a shoe on before a sock. Or place drawings of them in that order. What would have to change to get dressed in the usual way?

It works, in the sense that both items are on your foot. Both steps happened. Nothing was missed out. And the result is ridiculous.

You did not do anything wrong except the order, and the order was enough to ruin it.

Key idea: Having all the right steps is not enough. They have to be in the right order.

What a sequence is

A sequence is a set of steps in a fixed order, done one after another.

Our first paper programs are straight sequences: follow each step from the top. Loops and choices can change the next step. Real systems can also have several tasks in progress.

This is the first of the big ideas in this course, and it is the one everything else sits on. Loops, conditions and events all change which instruction comes next, but there is still an order at every moment.

Which pairs can swap?

Not every pair of steps matters. Here is the test: does the second step need something the first step made?

The point: Two steps must stay in order when the second one needs something the first one produced.

A program you can walk

Draw a grid on paper, five squares by five squares. Put a small toy on the bottom left square, facing up the page. Put a counter, or a coin, on a square three up and two right.

Here is a program, using the commands from the last lesson.

1. FORWARD 3
2. RIGHT
3. FORWARD 2
4. PICK UP

Move the toy one instruction at a time, and keep your finger on the line you are doing. It ends on the coin and picks it up.

Now swap lines 2 and 3, so it says FORWARD 3, FORWARD 2, RIGHT, PICK UP.

Run it again with your finger. The toy goes five squares up, falls off the top of the grid, turns right, and picks up nothing. Same four instructions. Completely different outcome.

Tracing: being the computer

What you just did has a name. Tracing means pretending to be the computer and following the program by hand, one line at a time, writing down what changes.

It is the single most useful habit in this whole course, and here is how to do it properly.

1. Keep one finger on the instruction you are doing.
2. Keep a written note of anything that changes: where you are, what you are holding, what number you have.
3. Do exactly what the line says, not what you think it should say.
4. Move your finger down one line and repeat.

Point three is the hard one. When you trace your own program, you keep quietly correcting it in your head, which is precisely how bugs survive.

Remember: When tracing, do what the line actually says. Your head will try to be helpful and it must not be allowed to.

A trace table

For anything with numbers, write the changes in a small table. Take this program.

1. SET score TO 0
2. ADD 5 TO score
3. ADD 3 TO score
4. TAKE 2 FROM score

The answer is 6. Without line 1, our paper program does not say what score starts at. Starting at 10 gives 16; starting at 0 gives 6. Real languages differ: some provide defaults and some report errors. Set the starting value you intend.

When the order does not matter

Sometimes steps are genuinely independent, and knowing that is useful too.

If a program has to send three emails, feed three animals or draw three separate shapes in different corners, the order between them makes no difference. Big computers take advantage of this by doing independent jobs at the same time on different parts of the chip.

So the question is never simply what order. It is: which steps depend on which other steps?

Try it: unscramble these

Put each set in the right order, then check.

Set A, a paper drawing: colour the roof; draw the roof outline; close the pencil box; take out a red pencil.

Set B, a jam sandwich: spread the jam; put the second slice on top; open the jar; take two slices of bread.

For A: take out the pencil, close the box, draw the roof outline, colour the roof. Closing the box can move later. For B: take two slices, open the jar, spread the jam, add the second slice. Opening the jar and taking the bread can swap. Both must happen before spreading.

Common misconceptions

• Mistake: if all the steps are there, the program is right. Sock and shoe are both on your foot in the wrong order too.
• Mistake: the computer will notice the order is silly. It will not. It has no idea what a sock is or what a foot is for.
• Mistake: every step depends on the one before. Some are completely independent, and spotting those is how big programs get made faster.
• Mistake: sequence is only for beginners. Sequences appear inside larger programs too, even when other parts run alongside them.

Putting it together

• A sequence is steps in a fixed order, carried out one at a time from the top.
• Two steps must stay in order when the second needs something the first produced.
• Swapping two lines can change the whole result even when nothing is missing.
• Tracing means following a program by hand, doing exactly what each line says.
• A trace table records what changes after every line, which is how you find where it went wrong.
• An unclear starting value can change an answer or cause an error; it need not vary on every run.

Sources

1. BBC. (n.d.). Computer science, KS2 Computing. BBC Bitesize. bbc.co.uk
2. CS Unplugged. (n.d.). Kidbots. University of Canterbury Computer Science Education Research Group. csunplugged.org
3. Wikipedia contributors. (n.d.). Control flow. Wikipedia. en.wikipedia.org
4. Code.org. (n.d.). Computer science for ages 5 to 11. Code.org. code.org
5. MDN contributors. (2025). ReferenceError: x is not defined. What went wrong and examples. Source

A square, and then a fifty sided shape

Here is a program that draws a square. The turtle draws a line, turns a quarter turn, and does it four times.

1. FORWARD 10
2. RIGHT
3. FORWARD 10
4. RIGHT
5. FORWARD 10
6. RIGHT
7. FORWARD 10
8. RIGHT

Eight lines for four sides. Now imagine a shape with fifty sides. That is a hundred lines, and every one of them has to be typed correctly, and if you later want a different length you have to change fifty of them without missing one.

Nobody does that. There is a better way, and it is one word long.

Key idea: When you find yourself writing the same thing again, that is the signal for a loop.

The counted loop

A loop is an instruction that tells the computer to do something again.

The square becomes this.

1. REPEAT 4
2. FORWARD 10
3. RIGHT
4. END REPEAT

Four lines instead of eight, and it does exactly the same thing. The two instructions between REPEAT and END REPEAT are called the body of the loop, and they run four times.

For a triangle, make two changes: repeat 3 times and turn one third of a full turn after each side. For a regular 50-sided shape, repeat 50 times and turn one fiftieth of a turn, or 7.2 degrees. Changing only the count keeps the old angle.

The point: A loop is not just shorter. It is easier to change, because the thing you want to change is written down once.

Loops are everywhere already

You use loops all day without a computer in sight.

• Brushing teeth: repeat for every tooth.
• Dealing cards: repeat until everybody has seven.
• Setting the table: repeat for every person sitting down.
• A song: verse, chorus, verse, chorus.
• Stirring: keep stirring until there are no lumps.

Notice that those last two are different from the first ones. Sometimes you know the number in advance. Sometimes you do not, and you stop when something becomes true.

Three kinds of loop

The forever loop sounds like a mistake and it is not. A game runs a forever loop: check the buttons, move everything, draw the screen, and do it all again, at an update rate chosen for that game, until you quit. A central heating thermostat runs one for years.

The loop that will not stop

Now the famous bug. Here is a conditional loop.

1. REPEAT UNTIL you reach the wall
2. FORWARD 1
3. END REPEAT

That works, as long as you are facing the wall. On paper, point away from that particular wall. Moving straight ahead will not reach it. Stop the trace at the grid edge, not after walking into a real obstacle.

An infinite loop has no reachable stopping point. In our paper example, the condition cannot change, so the loop keeps repeating. An unintended infinite loop can make a program stop responding; other faults can do that too.

Remember: Check what can make a loop stop: perhaps a value inside it, a timer or input from outside.

A loop inside a loop

You can put a loop inside another one. This is called nesting, and it is how rows and columns get made.

1. REPEAT 3
2. REPEAT 5
3. DRAW STAR
4. END REPEAT
5. NEW LINE
6. END REPEAT

How many stars? The inside loop draws five, and the outside loop makes the whole inside part happen three times. So three rows of five, which is fifteen stars.

The rule is that the inner loop finishes completely every time the outer loop goes round once. Trace it slowly with your finger the first time.

A digital clock counts 60 seconds per minute and 60 minutes per hour. On a 12-hour clock face, the minute hand makes 12 full turns during one turn of the hour hand, not 60.

Tracing a loop

Take this program and work out the total.

1. SET total TO 0
2. REPEAT 4
3. ADD 3 TO total
4. END REPEAT

The answer is 12, which is four threes. A loop that adds the same number over and over is multiplication, done the slow way, and that is genuinely how some machines do it.

Try it: spot the loop

Rewrite each of these using a loop, then check.

1. Clap, clap, clap, clap, clap, clap.
2. Jump, spin, jump, spin, jump, spin.
3. Keep pouring water into the glass. Stop when it is full.
4. Draw 4 rows with 6 dots in each row.

Answers. One: REPEAT 6, clap. Two: REPEAT 3, with both jump and spin inside the loop, because the pattern that repeats is the pair. Three: REPEAT UNTIL the glass is full, pour a little. Four: a nested loop, REPEAT 4 containing REPEAT 6 draw a dot, followed by a new line, which gives 24 dots.

Common misconceptions

• Mistake: a loop makes the program run faster. The computer does exactly the same amount of work. What gets shorter is what you had to write, and the number of places a mistake can hide.
• Mistake: loops go on forever. Only a forever loop does. A counted loop stops after its number, and a conditional loop stops when its condition becomes true.
• Mistake: a frozen program has stopped. An infinite loop is one possible cause. The program could also be waiting for a slow reply. A frozen screen alone does not identify the cause.
• Mistake: in a nested loop the two loops take turns. The inner loop finishes completely each time the outer one goes round once, which is why three and five give fifteen and not eight.

What to carry forward

• Writing the same thing twice is the signal that a loop is needed.
• A counted loop repeats a fixed number of times.
• A conditional loop repeats until something becomes true, and needs a way for that to happen.
• A forever loop is normal in games, thermostats and traffic lights.
• A nested loop runs the inner one completely for each turn of the outer one.
• Loops make programs shorter and much easier to change, not faster.

Sources

1. Wikipedia contributors. (n.d.). Loop (statement). Wikipedia. en.wikipedia.org
2. BBC. (n.d.). Computer science, KS2 Computing. BBC Bitesize. bbc.co.uk
3. Scratch Team, MIT Media Lab. (n.d.). Scratch: imagine, program, share. Massachusetts Institute of Technology. scratch.mit.edu
4. Code.org. (n.d.). Computer science for ages 5 to 11. Code.org. code.org
5. MDN contributors. (n.d.). Loops and iteration. Conditional loops and stopping rules. Source

The doors that know you are there

Walk up to a supermarket and the doors open. Stand still ten steps away and they stay shut.

There is no person watching. Above the door is a sensor, and the program behind it is about as simple as a program gets. It asks one question, several times a second, forever.

Is somebody standing in front of the door? If yes, open. If no, close.

That is a condition, and it is the third big idea in this course. Sequence says what order. Loops say do it again. Conditions let a program make a choice.

Key idea: A condition is a question a computer can answer yes or no, and it decides which instructions run next.

Questions with only two answers

A condition has to be answerable with yes or no. Programmers usually say true or false, which means the same thing.

Look at the difference.

Anything you want to ask can be turned into a yes or no question. It sometimes takes several of them, and that is fine.

IF and THEN

The basic shape is this.

1. IF it is raining
2. THEN take a coat

If the answer is yes, the THEN part happens. If the answer is no, it is skipped completely and the program carries on below.

Notice what a condition is not. It is not a loop. The question is asked once, at that moment, and then the program moves on.

ELSE: the other road

Often you want something to happen either way.

1. IF it is raining
2. THEN take a coat
3. ELSE take sunglasses
4. Leave the house

Exactly one of those two middle lines happens. Never both, and never neither. Then everybody, rained on or not, leaves the house.

Drawing it as a fork in a road helps: the road splits, you take one branch, and the two branches join up again afterwards.

The point: With IF and ELSE, one branch runs and the other does not. Then the program comes back together.

A chain of tests, and the bug hiding in it

Say you are giving out medals for a game score.

1. IF score is 10 or more, THEN gold
2. ELSE IF score is 5 or more, THEN silver
3. ELSE bronze

Trace it with a score of 12. Line 1 is true, so gold, and the rest is skipped. Score of 7: line 1 is false, line 2 is true, so silver. Score of 2: both false, so bronze. It works.

Now swap the first two lines round, so it tests 5 or more first.

Score of 12. Is 12 five or more? Yes. So it gives silver, and stops. Nobody in the game can ever win gold, and the program has no idea anything is wrong.

Remember: In a chain of tests, put the fussiest test first. The loosest test grabs everybody if you let it go first.

Two conditions at once: AND and OR

Sometimes one question is not enough.

• AND needs both to be true. Take an umbrella if it is raining AND you are going outside. If you are staying in, no umbrella, even in a storm.
• OR needs at least one to be true. Wear a coat if it is cold OR it is raining. Either one is enough, and both is fine too.
• NOT flips the answer. IF NOT hungry, do not make lunch.

Here is a table for two conditions, which is worth working through slowly because everyday English is much sloppier than this.

The row that catches people is the last column, second row. In a computer, OR is happy with just one. In everyday speech, would you like tea or coffee usually means pick exactly one, which is not what OR means here.

Conditions inside conditions

You can put an IF inside another IF, which is called nesting, just as with loops.

1. IF it is a school day
2. IF your school bag is packed
3. THEN put the bag by the door
4. ELSE pack the bag
5. ELSE leave the bag on its hook

The inner question is only asked at all when the outer one was true. On a Saturday, the program never even wonders whether the bag is packed.

Nesting more than two or three deep gets very hard to follow, and at that point most programmers rewrite it using AND instead.

Conditions in real things

• A pretend microwave on paper: IF the door is open, THEN do not start heating. Real ovens also have hardware safety interlocks. Never test or alter an appliance to try a coding rule.
• A game: IF the player touches the spikes, THEN lose a life.
• A washing machine: IF the water is not hot enough, THEN keep heating.
• A phone: IF the battery is under 20 percent, THEN show the warning.
• A traffic light: IF a car is waiting AND the other road has had its turn, THEN change.

Try it: what happens?

Use this program. IF score is more than 20, THEN say win, ELSE say try again.

1. Score is 25. What does it say?
2. Score is 20. What does it say?
3. Score is 0. What does it say?
4. How many of the two messages can ever appear at once?

Answers. One: win. Two: try again, because 20 is not more than 20, and this off by one trap is one of the commonest bugs in all of programming. Three: try again. Four: exactly one, never both and never neither.

Common misconceptions

• Mistake: the ELSE part runs as well. Exactly one branch runs. If the condition was true, the ELSE is skipped entirely.
• Mistake: IF keeps checking. An IF asks once, at that moment. A loop is what keeps checking, which is why the supermarket door has both.
• Mistake: more than 20 includes 20. It does not. If you mean 20 as well, you have to write 20 or more, and mixing these up is a genuine bug in real software.
• Mistake: OR means one or the other but not both. In programming, OR is true when either is true and also when both are.

Pulling it together

• A condition is a question with only two possible answers: true or false.
• IF runs the THEN part when the answer is yes, and skips it when the answer is no.
• With ELSE, exactly one of the two branches runs, and then the program rejoins.
• In a chain of tests, the fussiest test must come first or the loosest one takes everything.
• AND needs both true; OR needs at least one; NOT flips the answer.
• More than 20 does not include 20, and this catches everybody at least once.

Sources

1. Wikipedia contributors. (n.d.). Conditional (computer programming). Wikipedia. en.wikipedia.org
2. BBC. (n.d.). Computer science, KS2 Computing. BBC Bitesize. bbc.co.uk
3. CS Unplugged. (n.d.). Topics. University of Canterbury Computer Science Education Research Group. csunplugged.org
4. Code.org. (n.d.). Computer science for ages 5 to 11. Code.org. code.org
5. MDN contributors. (n.d.). Control flow and error handling. Conditional statements. Source

A button by the front door

Somebody presses a doorbell. A moment later a chime sounds in the kitchen.

Nobody in the kitchen was watching the button. The press triggers a response. We can describe that behaviour without knowing whether this doorbell uses software or a simple circuit.

That is an event: a signal that something happened, which code can respond to. It can come from a person, a sensor or another part of the program.

Key idea: An event turns a program from a list you run into a machine that reacts.

When this, do that

Event rules are written in a fixed shape.

• WHEN the doorbell is pressed, THEN play the chime
• WHEN the space key is pressed, THEN make the cat jump
• WHEN the green flag is clicked, THEN start the game
• WHEN two sprites touch, THEN lose a life
• WHEN 30 seconds have passed, THEN show the time is up message

The piece of code attached to an event has a name: an event handler. It sits there doing nothing, possibly for hours, and runs when the system handles that event, perhaps after other work finishes.

How an event differs from a condition

These two get muddled constantly, and the difference is worth pinning down.

Underneath, a computer often does check for events over and over, thousands of times a second, in a loop you never see. But from the point of view of the person writing the code, the program waits and the event arrives.

The point: An IF asks a question. A WHEN waits for news.

Not all events involve a person

People are the obvious source of events, but plenty of events have nothing to do with anybody.

• Time. When a timer reaches zero. An alarm clock is this and nothing else.
• Sensors. When the temperature drops below 18 degrees, turn the heating on.
• Messages. When a message arrives from another computer, show a notification.
• The program itself. When the download finishes, open the file.
• Other parts of the same program. A sprite in a game can broadcast a message that other sprites are all waiting for.

That last one is how anything complicated gets organised. One part shouts level complete, and six other parts, which know nothing about each other, all react.

The thing that surprises everybody

Up to now, programs in this course have run from the top to the bottom in order.

A program built out of events does not work like that. Ten different handlers sit waiting at once, and which one runs next depends on what the person outside does. Press a key and one runs. Click the mouse and a different one runs. Do nothing at all and none of them run, possibly forever.

So the order the handlers are written on the page tells you nothing about the order they will run in. This feels wrong the first few times and then becomes obvious, because it is exactly how a shop counter works: the shopkeeper has rules for what to do when somebody buys something, when the phone rings, and when a delivery arrives, and the day decides which happens first.

Remember: With events, the order things are written in is not the order they happen in.

Designing a game on paper

You can design a whole game without a computer by listing its events. Here is a simple catching game.

This table is a starting plan. We still need rules for falling apples and restarting them. These WHEN rules are paper instructions, not exact Scratch blocks. In Scratch, touching is a condition you can check in a loop; key presses and broadcasts have event blocks.

Two events at nearly the same time

What if somebody presses two keys at once?

For our paper game, put event cards in a queue and handle the front card first. Real systems have different scheduling rules, not one universal queue. If handlers change the same value, test both orders.

This matters in games. If your character can jump and duck, and both handlers change the same thing, the second one wins, which is a real source of odd behaviour.

Try it: name the event

For each, write the rule as WHEN something, THEN something.

1. A microwave beeps when the time runs out.
2. A phone screen lights up when a message arrives.
3. A car dings when a seatbelt is not fastened.
4. A shop door opens as you walk up.

Answers. One: WHEN the timer reaches zero, THEN beep. Two: WHEN a message arrives, THEN light the screen. Three: WHEN the engine starts AND the belt is unfastened, THEN ding, which is an event and a condition working together. Four: WHEN the sensor detects a person, THEN open the doors.

Common misconceptions

• Mistake: events happen in the order they were written. They happen in the order they occur in the world. The page order tells you nothing.
• Mistake: an event is the same as an IF. An IF is a question the program asks itself. An event is a signal, including one from another part of the program.
• Mistake: events need a person. Timers, sensors, finished downloads and messages from other parts of the program are all events.
• Mistake: a waiting program is doing nothing wrong. A program that never responds may simply have no handler for what you did, which is why a button that does nothing when clicked is such a common bug.

Where this leaves us

• An event is something that happens which a piece of code has been waiting for.
• Event rules take the shape WHEN this happens, THEN do that.
• The waiting code is called an event handler.
• An IF asks a question at a moment; a WHEN rule responds to a signal.
• Time, sensors, messages and other parts of the program all create events.
• The order handlers are written in has nothing to do with the order they run in.

Sources

1. Wikipedia contributors. (n.d.). Event (computing). Wikipedia. en.wikipedia.org
2. Scratch Team, MIT Media Lab. (n.d.). Scratch: imagine, program, share. Massachusetts Institute of Technology. scratch.mit.edu
3. Wikipedia contributors. (n.d.). Scratch (programming language). Wikipedia. en.wikipedia.org
4. BBC. (n.d.). Computer science, KS2 Computing. BBC Bitesize. bbc.co.uk
5. MDN contributors. (n.d.). Introduction to events. Event handlers and signals. Source

The moth in the machine

On 9 September 1947, a team working on the Harvard Mark II computer reported a moth caught between a relay's contacts. A relay is an electrically operated switch.

The team recorded the physical fault in the computer's logbook. This was a problem inside the machine, not a misspelled command in a program.

They taped the moth into the logbook and wrote beside it that this was the first actual case of a bug being found. That page, moth still attached, is now in a museum.

The word bug already meant a technical fault. You can check that in T. O'Conor Sloane's 1892 Standard Electrical Dictionary, page 92, under Bug. The later logbook entry plays on the word's two meanings: a fault and an actual insect.

Key idea: A software bug is a fault in a program. Hardware can fail too: the moth story is a physical fault. Our exercises focus on instructions.

A first version is something to test

A program can look right on paper and still do something you did not intend. Experience does not remove the need to check. A first version may work, or it may reveal a problem.

Debugging means investigating and fixing a fault. It is part of developing software, alongside planning, writing and testing. Finding a fault tells you something about this version, not what you are capable of learning.

Start with a concrete difference: you wanted a square, but the toy drew a straight line. Now you have a result to investigate.

Remember: An unexpected result is a clue. It does not always tell you where the fault is, so trace the steps and check your assumptions.

Five kinds of bug

A rejected command may come with a helpful error message. A wrong comparison can be harder to notice because the program runs without complaining. Neither type has a fixed difficulty: compare the result with the intended behavior, then investigate the evidence.

The five step method

Use these five steps to investigate the paper programs below. If one step does not reveal the fault, record what you learned and try another small case.

1. Say what it does and what it should do. Out loud, in one sentence each. It draws a triangle. It should draw a square.
2. Find a small example that still goes wrong. If it fails on a list of twenty names, try three. Fewer steps can make a trace easier to inspect. Keep the original failing case too.
3. Trace it by hand. Go line by line, doing exactly what each line says, and find the first line where what happens differs from what you expected. Start there, but the cause may be an earlier value or missing step.
4. Change one thing. One. Then run it again.
5. Retest the changed example and related cases, including ones that already worked. A change can fix one result and disrupt another.

If you change four things at once and the result improves, it may be difficult to tell which change helped. A focused change makes that comparison clearer. Keep a note of what you changed and what you tested.

Explaining it to a duck

There is a technique with a silly name that professionals genuinely use. It is called rubber duck debugging.

You take a rubber duck, or a teddy, or a photograph of your cat, and you explain your program to it out loud, one line at a time, saying what each line does and why it is there.

You may notice a difference between what a line does and what you expected. If not, use a trace table or ask someone to check a small example.

As you explain, say what each line actually does, then compare it with what you meant. You can speak, write notes, or point through a trace with someone. This is a way to inspect the reasoning, not a guarantee that a fault will appear.

The point: Explaining a program step by step gives you another way to check it. Follow up any suspected mistake with a test.

A worked example

Trace this pretend toast program on paper only. Do not use a toaster or knife. Treat the instructions as cards and find three missing or misplaced steps.

1. Put the bread in the toaster
2. Wait 2 minutes
3. Spread the butter
4. Take the toast out of the toaster
5. Eat it

Bug one is a missing step: nothing ever switches the toaster on, so it waits two minutes beside cold bread. Bug two is wrong order: line 3 spreads butter on toast that is still inside the toaster. Bug three is a missing step again, since nobody ever got the butter or a knife.

Here is the fixed version.

1. Put the bread in the toaster
2. Push the lever down to switch it on
3. Get a plate, a knife and the butter
4. Wait until the toast pops up
5. Take the toast out and put it on the plate
6. Spread the butter with the knife
7. Eat it

Notice that line 4 changed from a counted wait to a conditional one. Two minutes might be wrong for a different toaster. In our pretend pop-up toaster, popping is the signal to continue. Real appliances differ and can malfunction; this is not appliance-use guidance.

Bugs that only happen sometimes

Some faults appear only with particular inputs or event orders.

A program that works with three names but fails with one. A game that is fine unless you press two keys at once. A quiz that breaks only when the answer is zero.

Compare the cases that worked with those that failed. What input or event order changed? Useful cases to try include the first item, the last item, an empty list, and a number exactly on a comparison boundary. These are places to investigate, not the only places faults can occur.

Try it: find the bug

This program should make the toy walk round a square and end up where it started. Trace it and find the mistake.

1. REPEAT 4
2. FORWARD 3
3. END REPEAT

Answer. There is no turn inside the loop, so the toy walks twelve squares in a straight line and never comes back. It is a missing step, and the fix is to add RIGHT after FORWARD 3, inside the loop. If you put the turn after END REPEAT instead, you get a straight line followed by one useless turn, which is a wrong order bug on top of the first one.

Common misconceptions

• Mistake: a bug means you are bad at this. Experienced programmers also investigate faults. Check this program's behavior rather than treating one result as a judgment of your ability.
• Mistake: the computer must have ignored my command. First trace the written instructions and input. If those do not explain the result, hardware or other parts of the system may need checking too.
• Mistake: change lots of things and one will fix it. Several changes make the cause harder to isolate. Try one focused change, then compare the result.
• Mistake: it worked once, so it works. One successful test checks one case. Try an empty input, a single item, a boundary value, and another ordinary input when those cases make sense for your program.

Summing up

• Engineers used bug to mean a fault before the famous moth of 1947. A software bug is a fault in instructions.
• Debugging is a normal part of programming, including for experienced programmers.
• Our examples use five categories: wrong word, wrong order, missing step, wrong number, and wrong idea. Other kinds of fault exist.
• Compare actual and intended results, try a small example, trace it, make a focused change, then retest relevant cases.
• Explaining each step can help you examine it, but suspected fixes still need tests.
• First, last, empty and boundary cases are useful checks, not an exhaustive test plan.

Sources

1. Wikipedia contributors. (n.d.). Software bug. Wikipedia. en.wikipedia.org
2. Wikipedia contributors. (n.d.). Grace Hopper. Wikipedia. en.wikipedia.org
3. Wikipedia contributors. (n.d.). Debugging. Wikipedia. en.wikipedia.org
4. Computer History Museum. (n.d.). Timeline of computer history. Computer History Museum. computerhistory.org
5. Smithsonian National Museum of American History. (n.d.). Log book with computer bug. Object nmah_334663. Source
6. Sloane, T. O'Conor. (1892). The Standard Electrical Dictionary, p. 92, Bug and Bug Trap. Primary historical definitions, reproduced by Project Gutenberg. Project Gutenberg
7. Computer History Museum. (n.d.). September 9: First Instance of Actual Computer Bug Being Found. Historical account accompanying the logbook reproduction. Computer History Museum

Forty seven things on the bedroom floor

Somebody says tidy your room.

You stand in the doorway. There are books on the floor, a jumper on the chair, three socks that do not match, a plate, some Lego, a wet towel and a school bag with everything falling out of it.

Nothing happens. It is not that you are refusing. It is that tidy your room is not an instruction you can start, because there is no first step in it.

Key idea: A job you cannot start is usually not too hard. It is too big.

Decomposition

Programmers have a long word for cutting a big job into small ones: decomposition. It means exactly what tidy your room needs.

Watch what happens when you split it.

1. Put all the books on the shelf.
2. Put all the dirty clothes in the basket.
3. Put all the toys in the box.
4. Take the plate and the cup to the kitchen.
5. Put the rubbish in the bin.
6. Make the bed.

Every single one of those can be started immediately and finished in a few minutes, and when it is finished you can see that it is finished. That is the difference.

Four reasons programmers do this constantly

• You can start. A small piece has an obvious first move.
• You can tell when it is done. The books are on the shelf or they are not.
• You can test it on its own. If the books end up in the wrong place, you know which piece to look at.
• Somebody else can do a piece. This is how teams of hundreds build one program without every person understanding all of it.

The point: Small pieces can be started, finished, checked and shared. Big ones cannot.

Splitting a game

Say you want to make a catching game. That is far too big a sentence to code.

The pieces still connect. Test the score by pretending a catch happened: it should increase by one. If that works but a real catch adds nothing, check the connection between catching and scoring.

Three ways to cut

There is more than one way to split something, and picking a good one matters.

• By part. A bicycle: wheels, frame, brakes, chain, seat. A game: characters, background, score.
• By step in time. Making a cake: weigh, mix, pour, bake, cool, ice. Each step finishes before the next starts.
• By kind of thing. Tidying: books, clothes, toys, rubbish. All the same job done to different objects.

For a jigsaw puzzle, most people split by kind: all the edge pieces first, then the sky, then the grass. That is decomposition being used by someone who has never heard the word.

The test for a good split

Ask two questions about each piece.

1. Could I explain this piece to somebody else in one sentence? If it takes a paragraph, it is still too big.
2. Would I know when it is finished? If not, it is too vague, which is the same problem as in the exact instructions lesson.

Compare make the game fun, which fails both tests, with make the basket move when the arrow keys are pressed, which passes both easily.

Remember: If you cannot say when a piece is finished, it is not a piece yet.

Splitting a piece again

Sometimes a piece is still too big, and you split it again.

Take make the bed from the tidying list. For a small child that is one job. For a very small child it is three.

1. Pull the duvet up to the pillow.
2. Straighten it so the edges hang evenly.
3. Put the pillow at the top and the teddy on top of that.

You do not need to plan every level in advance. Split it once, start on a piece, and if that piece turns out to be a monster, split that one too. Programmers do this all day.

Why this matters beyond code

A school project or party plan can also be split into tasks. That helps you see the next step; it does not remove the need for time, materials, practice or help.

A big car factory has teams for the engine, the doors, the wiring and the seats. Nobody in that building knows how to build an entire car alone, and the car gets built anyway.

Try it: split these

Write three to six pieces for each, then compare.

1. Make a birthday card.
2. Plan a picnic.

Sample answers. Card: fold the paper; draw the picture on the front; write the message inside; write the name on the envelope; decorate the edges. Picnic: decide who is coming; make a list of food; make the sandwiches; pack the bag with a blanket and drinks; choose the place; check the weather.

Your lists will not match these exactly and that is fine. Two people can split the same job differently and both be right. What matters is that every piece can be started and finished.

Common misconceptions

• Mistake: splitting is extra work before the real work. It is the fastest part of the work, and it is why the rest of the work becomes possible.
• Mistake: the pieces must all be the same size. They almost never are. Pack the bag might take four minutes and make the sandwiches twenty.
• Mistake: you have to plan every level before starting. Split once, start, and split again if a piece turns out to be a monster.
• Mistake: there is one correct way to split a job. By part, by step, or by kind of thing are all valid, and different splits suit different jobs.

What you now know

• Decomposition means breaking a big job into small ones.
• A job you cannot start is usually too big rather than too hard.
• Small pieces can be started, finished, tested and handed to somebody else.
• You can split by part, by step in time, or by kind of thing.
• A good piece can be described in one sentence and has a clear finish.
• If a piece is still too big, split that piece again.

Sources

1. Wikipedia contributors. (n.d.). Decomposition (computer science). Wikipedia. en.wikipedia.org
2. BBC. (n.d.). Computer science, KS2 Computing. BBC Bitesize. bbc.co.uk
3. CS Unplugged. (n.d.). Topics. University of Canterbury Computer Science Education Research Group. csunplugged.org
4. Code.org. (n.d.). Computer science for ages 5 to 11. Code.org. code.org

You already solved half of this

Earlier you saw a program that draws a square: REPEAT 4, FORWARD 10, RIGHT.

Now you want to draw a house, which is a square with a triangle on top. And after that a street of five houses.

The question is whether you write the square out again. Then again. Then five more times.

You do not, and the reason is the most powerful habit in programming: when you have solved something once, give the solution a name and use the name.

Key idea: Solve it once. Name it. Use the name from then on.

Naming a set of steps

You can teach a computer a new word. It looks like this.

1. TO DRAW SQUARE
2. REPEAT 4
3. FORWARD 10
4. RIGHT
5. END REPEAT
6. END

Nothing is drawn yet. That block is a recipe, not a meal. It sits there until somebody writes DRAW SQUARE, and at that moment all four sides get drawn.

A named set of steps like this has several names depending on the language: a procedure, a function, a subroutine, or in Scratch, a custom block. They share the idea of reusable work, but details differ. A function may return a value; a Scratch custom block runs its attached steps.

Now a street of five houses is short.

1. REPEAT 5
2. DRAW HOUSE
3. MOVE RIGHT 15
4. END REPEAT

Three reasons this is worth doing

• Write it once. Five houses use one recipe.
• Fix it once. If the roof is wrong, you change the recipe and all five houses are fixed at the same moment. This is the big one.
• The name explains it. A program that says DRAW HOUSE, MOVE RIGHT, DRAW HOUSE can be understood at a glance. The same program written out in full is forty lines of FORWARD and RIGHT that nobody can read.

The point: The main gain is not typing less. It is having one place to fix and a name that says what is happening.

Copying is not reusing

There is a tempting shortcut: write the square once, then copy those four lines five times.

It works, at first. Then you notice the squares are too small and you have to find and change five separate copies. If you miss one copy, that house stays the old size. Check each copy against the intended change.

That is not a made up danger. It is one of the commonest sources of bugs in real software.

Remember: Copied code has to be fixed in every copy. Named code is fixed in one place.

One recipe, different sizes

What if you want a big square and a small square?

You do not need two recipes. You leave a gap in the recipe for a number to be handed in.

1. TO DRAW SQUARE size
2. REPEAT 4
3. FORWARD size
4. RIGHT
5. END REPEAT
6. END

Now DRAW SQUARE 10 gives a small one and DRAW SQUARE 40 gives a big one, from the same six lines. The named gap, size, is a parameter. The value you pass, such as 10, is an argument. One recipe can take different inputs.

You already use this idea. A recipe for pancakes works for four people or eight; the recipe is the same and the number changes. Sing happy birthday to works for anybody, because the name is a gap you fill in.

Spotting the pattern in the first place

The hard part is not writing the recipe. It is noticing that two things are the same.

Look at this program and find what repeats.

1. FORWARD 5, RIGHT, FORWARD 5, RIGHT, FORWARD 5, RIGHT, FORWARD 5, RIGHT
2. MOVE TO the next spot
3. FORWARD 8, RIGHT, FORWARD 8, RIGHT, FORWARD 8, RIGHT, FORWARD 8, RIGHT

Two squares of different sizes. One recipe with a parameter handles both, and the whole thing becomes DRAW SQUARE 5, MOVE TO the next spot, DRAW SQUARE 8.

Three lines instead of eighteen, and now anybody reading it can see immediately what it does.

Problems that are secretly the same problem

Patterns also turn up between problems that look completely different.

• Sharing twelve sweets between four children.
• Sharing twelve small cakes equally between four people.
• Putting twelve chairs into four equal rows.

Three different scenes and one piece of maths: twelve divided by four. If you can see that, you only have to learn the answer once.

Programmers hunt for this constantly. A shopping basket, a music playlist and a queue at a shop are all lists of things with things being added and removed, so the same solution works for all three.

Using work other people have already done

Nobody writes everything themselves. When a programmer needs to draw a circle, or sort a list, or work out what day of the week a date falls on, they use a set of ready made recipes that somebody else wrote and shared. Collections like this are called libraries.

This is not cheating and it is not lazy. It is the same reason you do not grind your own flour before making a sandwich. The interesting part of your program is the part nobody has written yet.

Try it: name the recipe

For each, decide what you would name and what would go inside the name.

1. A program that draws four identical flowers in four corners.
2. A program that says hello to Sam, then to Ali, then to Jo.
3. A dance where you clap twice, spin, clap twice, spin, clap twice, spin.

Answers. One: a recipe called DRAW FLOWER, called four times, with the moving between corners left outside it. Two: a recipe called SAY HELLO with the name as a parameter, called three times with a different name each time. Three: a recipe called CLAP AND SPIN containing clap, clap, spin, then REPEAT 3 around it.

Common misconceptions

• Mistake: copying and pasting is the same as reusing. A copy has to be fixed in every place it was copied to. A name is fixed once.
• Mistake: a recipe has to be long to be worth naming. Two lines with a good name are often clearer than two lines without one, because the name says why they are there.
• Mistake: using other people's code is cheating. Every professional does it. The interesting part is the part nobody has written yet.
• Mistake: a recipe with a gap in it is complicated. A birthday song with a name in it is exactly this idea, and every four year old can handle it.

The takeaway

• When you have solved something, give the solution a name and use the name.
• A named set of steps is called a procedure, a function or a custom block.
• The biggest gain is that there is only one place to fix when it is wrong.
• A parameter is a gap in the recipe for a number or a word to be handed in.
• Problems that look different can be the same problem underneath.
• Using recipes other people wrote is normal, expected and sensible.

Sources

1. Wikipedia contributors. (n.d.). Function (computer programming). Wikipedia. en.wikipedia.org
2. Scratch Team, MIT Media Lab. (n.d.). Scratch: imagine, program, share. Massachusetts Institute of Technology. scratch.mit.edu
3. BBC. (n.d.). Computer science, KS2 Computing. BBC Bitesize. bbc.co.uk
4. Code.org. (n.d.). Computer science for ages 5 to 11. Code.org. code.org
5. MDN contributors. (n.d.). Functions. Parameters and arguments. Source

Seven guesses

Think of a number between 1 and 100. Do not say it.

Somebody who knows what they are doing will find your number in at most seven guesses, every single time, even though there are a hundred numbers to choose from. Not by luck. By method.

Here is the method. Guess 50. You say higher or lower. Guess halfway into whichever half is left. Say higher or lower again. Keep halving.

Allow higher, lower or correct. Check the middle remaining number and remove it if wrong. The largest possible remaining counts go 100, 50, 25, 12, 6, 3, 1. The last candidate needs at most a seventh guess.

Key idea: A good method beats a fast guesser. This lesson is about methods that always work.

What an algorithm is

An algorithm is a precise method for a task. Our search and sort methods finish after a limited number of steps on a finite list.

Those three parts all matter. Check the inputs a method accepts, its promised result and how it stops. Other algorithms may use chance or seek approximate answers; they are still algorithms.

Most algorithms have nothing to do with computers.

• A recipe for pancakes.
• The written method for adding two three digit numbers in columns.
• The instructions for tying a shoelace.
• How to look a word up in a dictionary.

Long division is an algorithm somebody had to invent, and you can do it because you learned their steps.

Looking for one thing among many

Say you have a hundred cards face down with numbers on them, and you want the card that says 73.

The obvious method is to turn them over one at a time, from the beginning, until you find it. This is called linear search, and it works on anything, in any order.

The cost is that it can be very slow. If 73 is the last card, you turn over all hundred. On average you turn over about fifty.

The faster way, and what it costs

Now suppose the cards are in order, smallest to largest.

Turn over the middle one. It says 40. Since 73 is bigger, every card before the middle can be thrown out, all fifty of them, in one move. Turn over the middle of what is left, and again, and again.

This is binary search, the same halving as the guessing game. Here is what it buys you.

Look at the last row for a moment. A million things, and twenty questions is enough. Every time you double the number of things, binary search needs exactly one more check.

But there is a price, and it is not optional: the things have to be in order first. Halving an unsorted pile tells you nothing, because there is no reason for the smaller ones to be on the left.

Remember: Binary search is enormously faster, and it only works on a sorted list.

You already use this

Look a word up in a dictionary and watch yourself. You do not start at aardvark. You open it near the middle, see you are too far on, and jump back. Three or four jumps and you are on the right page.

Phone books, indexes, library shelves and the contents page of a book all exist so that people can do binary search instead of linear search. Putting things in order is work that is done once so that finding them is quick forever afterwards.

Putting things in order

So how do you sort a shuffled pile in the first place? Here is a method you can write down.

Selection sort.

1. Look through the whole pile and find the smallest card.
2. Put it at the start of a new row.
3. Look through what is left and find the smallest of those.
4. Put it next in the row.
5. Repeat until the pile is empty.

It always works, it always finishes, and you could hand it to somebody who had never sorted anything. That makes it an algorithm rather than a knack.

It is also slow, because finding the smallest means looking at everything left in the pile, every single time. There are cleverer sorting methods, some of which split the pile in half and sort each half, and for a thousand cards the difference is enormous. For ten cards on a kitchen table nobody cares.

Why the method matters more than the machine

People assume a slow program just needs a faster computer. Sometimes that is true. Often it is not, and the numbers explain why.

Searching a million sorted names with binary search takes about twenty checks. Searching them one at a time takes up to a million. A computer doing each check twice as fast still makes up to a million checks; it takes half the time. If the list is already sorted and checks cost similar time, binary search can be much quicker even on the old machine.

Why this matters: Choosing a better algorithm often beats buying a faster computer, and it costs nothing.

Try it: count the questions

Work each one out before you check.

1. You are guessing a number from 1 to 100 and you have been told higher than 50. What should you guess next?
2. Why can you not use halving on a shuffled pile of cards?
3. Roughly how many halvings does it take for a thousand things?
4. You are looking for one particular sock in an unsorted drawer. Which method are you using?

Answers. One: 75, the middle of what is left, since guessing 51 would only rule out one number if you are wrong. Two: because there is no reason the smaller ones are on one side, so an answer of higher tells you nothing about where to look. Three: ten, since doubling adds one check each time and a thousand doubles from one about ten times. Four: linear search, and it is the right choice, because sorting the drawer first would take far longer than looking through it.

Common misconceptions

• Mistake: an algorithm is a computer thing. Long division, shoelaces and pancakes are all algorithms. Computers just follow them very fast.
• Mistake: binary search works on any list. Only on a sorted one. This is the single most common mistake people make with it.
• Mistake: a faster computer fixes a slow method. Doubling speed can halve time, not the check count. Binary search can reduce a million possible checks to about twenty on an already sorted list.
• Mistake: sorting is always worth it. If you are looking for one thing once, just look. Sorting pays off when you will search the same collection many times.

Looking back

• An algorithm is a precise method. Our methods have stated inputs, results and stopping rules.
• Linear search checks everything in turn and works on any pile.
• Binary search halves the pile each time and needs the pile to be in order.
• A million sorted items can be searched in about twenty checks.
• Selection sort finds the smallest, puts it first, and repeats.
• A better method usually beats a faster machine, and costs nothing.

Sources

1. Wikipedia contributors. (n.d.). Binary search. Wikipedia. en.wikipedia.org
2. CS Unplugged. (n.d.). Searching algorithms. University of Canterbury Computer Science Education Research Group. csunplugged.org
3. CS Unplugged. (n.d.). Sorting networks. University of Canterbury Computer Science Education Research Group. csunplugged.org
4. Wikipedia contributors. (n.d.). Algorithm. Wikipedia. en.wikipedia.org
5. Wikipedia contributors. (n.d.). Sorting algorithm. Wikipedia. en.wikipedia.org

The first message was two letters long

On 29 October 1969, student programmer Charley Kline at the University of California, Los Angeles, tried to log in to a computer at Stanford Research Institute. The computers were connected through a new network called ARPANET.

The intended command was LOGIN. The letters L and O arrived before the system crashed: it stopped working. After the problem was fixed, the login succeeded.

This was ARPANET's first host-to-host message. A host is a computer using a network. It was not the first time any two computers had communicated. ARPANET was one important part of the work that led to today's internet.

Key idea: People built the internet by finding ways for separate networks to exchange data. That work took many steps and involved many people.

What it is made of

A network is a group of connected devices that can exchange data. The internet joins many networks together. To picture how this works, look for three things.

1. Machines. Phones, laptops, servers, and the boxes in between.
2. Connections. Links that carry data, including cables and wireless links.
3. Agreed rules. Instructions for exchanging data. These rules are called protocols.

A phone and a laptop can use different parts and still exchange data when they use suitable shared rules. They also need a working route between them. Rules alone cannot repair a broken link or make a switched-off computer answer.

Wi-Fi uses radio to connect devices on a local network, such as one in a home. A mobile network or satellite link also uses radio, over different distances. A wireless first step does not tell you what the rest of the route uses.

The cables under the sea

Most internet data that crosses oceans travels through submarine cables. Submarine means under the sea. Modern cables contain optical fibres that carry data. Satellites can carry internet data too, but cables carry most traffic between continents.

Keep the ocean part of that statement. A message to a nearby friend might never go near the sea. Cables on land and wireless links also connect networks. You cannot work out the exact route of one message just from the countries where its users live.

Where a cloud file lives

When you save a drawing to cloud storage, a service keeps its data on storage computers that you reach over a network. The drawing is not floating above your device. Real equipment stores it.

A cloud service draws on a shared pool of tools, such as storage space and programs. The tools may run in several places. A cloud can serve one group or many customers. It need not be one company's warehouse.

Remember: Cloud storage still uses physical computers. The word describes how storage is provided and accessed, not a place in the sky.

Everything needs an address

An envelope's address helps the post reach the right place. Internet packets also carry addresses. An IP address marks a place on a network so that equipment can decide where to send data. That place is the packet's destination.

One kind of IP address is written as four numbers with dots between them. For example, 192.168.0.14 belongs to a range used inside private networks. Different homes can reuse it. It is not a unique address for one computer in the whole world. Other IP addresses use a different written form.

People often use a domain name, such as the name in a website address. The Domain Name System, or DNS, can look up IP addresses for that name. Looking up addresses is one of its jobs. A name can have more than one address.

Think of a shared directory: ask for a name and receive information about it. DNS is spread across many computers. A device or DNS service may already have a recent answer saved. This saved information is called a cache, and it can avoid repeating a lookup right away.

Why your message is cut into pieces

A photo contains far more data than the letters LO. How can it share a connection with other people's data?

A long message can be divided into small units called packets. A packet includes some of the data. It also includes addressing information, which says where it is going. Some communication rules add sequence information too. That is a packet's place in the order, so a receiver can rebuild the stream of data.

Packets can follow the same route or different routes. They can arrive out of order or fail to arrive. TCP is a protocol that provides ordered data and sends missing data again. Other protocols handle loss differently. A live internet call may skip late sound data instead of waiting for it.

Imagine posting a jigsaw in numbered envelopes. The numbers let your friend arrange pieces that arrive out of order. If an envelope is missing, the numbers help reveal the gap, but cannot fill it. You need a rule for requesting and sending another copy.

This is a model of ordering and recovery, not a picture of every packet system. Real TCP numbers positions in a stream of data. Our paper game will number whole pieces so that you can follow them by hand.

Why bother chopping it up?

Packets help different messages use the same link. Extra rules handle what happens when a piece goes missing.

• Messages can share a link. Packets from different messages can be sent between one another. One whole file need not finish before another starts.
• A different route may help. If a link fails and another usable route exists, routers may send traffic around the failure. If there is no usable route, delivery cannot continue.
• Missing data can be sent again. A protocol such as TCP can retry missing data without starting the whole file again. Retrying still needs a working connection.

Picture a pretend link that sends one packet on each turn. Jo has four packets and Kim has two. The link could send Jo 1, Kim 1, Jo 2, Kim 2, Jo 3, Jo 4. Kim's message finishes before Jo's, even though Jo started first. Real equipment decides which packet to send next using its own rules.

The point: Sharing does not mean no waiting. Packets may queue while a link is busy. If too much arrives for the equipment to hold, packets can be dropped.

Routers, and the little that each one knows

A router sends packets on from one network to another. This is called forwarding. It uses the packet's address and a stored set of routes to choose a next hop. A hop is one step to the next device along the route.

Imagine a paper map with a sender, routers A and B, and a receiver. The rule at A says to send packets for the receiver to B. The rule at B says to send them to the receiver. Each router follows its next-step rule. Neither needs to assemble the whole message.

Now cross out the link from A to B. A can use a different route only if one is available and its routing information allows it. Drawing a new arrow on paper is simple; a real network must have real working links. A hop is a network step, not a promise to move closer on a map.

Forwarding a packet does not by itself keep the data secret. Keeping data private needs extra protection. Knowing where a packet should go does not mean it can get there.

Asking and answering

When a browser requests a web page, it acts as a client. A server program receives the request and sends a response. For example, it may return the page or report that the page was not found.

Client and server describe roles in this exchange. People also call the computers running these programs clients or servers. A laptop can run a server program. The role does not require a particular building or mean that the computer can never do another job.

Follow the separate jobs in a page request. DNS can help find an address. Routers forward packets along a route. A web server handles the request. The browser uses the response to display the page. These jobs work together, but each answers a different question.

The internet and the web are not the same thing

People use these words as if they mean the same. They do not.

The internet is a network of networks. The web is one service that uses it, with linked pages and other resources that browsers can request.

Roads and traffic make a useful comparison. The internet is like the road system; the web is one kind of traffic. Email and internet calls can use the network too. Some services also have web versions, such as email read in a browser. The categories can overlap.

ARPANET began in 1969. Tim Berners-Lee proposed the web at CERN in 1989. The internet developed through work before and between those dates, so the two dates do not give a single birthday for all networking.

Try it: work these out

1. A photo is too large for one packet. How can its data travel?
2. A cable under the Atlantic is damaged. What would let traffic use another route?
3. Your device already has a usable DNS answer saved. Must it look up the name again right now?
4. Does a Wi-Fi connection prove that a whole trip across the ocean is wireless?

Cover the next paragraph and explain your answers before checking.

Check: One: divide the data among packets; suitable rules are needed to put it together reliably. Two: another working route must exist, and routers must be able to use it. A cable cut can still cause an outage. Three: no, a usable cached answer can be reused. Four: no, Wi-Fi describes a local link. Most ocean-crossing internet data travels through submarine cables.

Common misconceptions

• Mistake: the internet is wireless. Wi-Fi is a local radio connection. Beyond it, a route may use fibre, other cables, mobile networks or satellite links. Not every connection follows the same route.
• Mistake: the cloud is in the sky. Cloud services use physical computing resources accessed over a network.
• Mistake: the internet and the web are the same thing. The web is one service using the internet. Other services use it too.
• Mistake: packets always arrive in order. Packets can be delayed, reordered or lost. A protocol such as TCP supplies rules for ordering and retries.

Putting it together

• The first ARPANET host-to-host login attempt in 1969 delivered LO before a crash.
• The internet joins networks using machines, connections and shared rules.
• Most internet traffic crossing oceans runs through cables on the seabed.
• Network destinations use IP addresses. DNS helps find the addresses for domain names.
• Data travels in packets. Systems such as TCP can put data in order and send missing parts again.
• Routers select next hops using routing information. Clients ask, and servers answer.

Sources

1. UCLA. (2019). Pioneers and visionaries to celebrate internet's 50th anniversary at UCLA, Oct. 29. Account of the LOGIN attempt. UCLA.
2. Leiner, B. M., et al. (1997). A brief history of the internet. Origins; The Initial Internetting Concepts. Internet Society.
3. Rysman, M. (2024, October 31). Mapping investment and usage of the subsea internet cable networks. Opening paragraph, intercontinental traffic. Internet Society Pulse.
4. International Telecommunication Union. (2026, April update). Submarine cable resilience. Overview, optical fibres. ITU.
5. Mell, P., & Grance, T. (2011). The NIST definition of cloud computing. SP 800-145, pp. 2-3. NIST.
6. Eddy, W. (Ed.). (2022). Transmission Control Protocol. RFC 9293, sections 2.2, 3.4 and 7. RFC Editor.
7. Mockapetris, P. (1987). Domain names: Concepts and facilities. RFC 1034, sections 3.6, 5.1 and 5.3.3. Updated standard, used for basic lookup and caching. RFC Editor.
8. Rekhter, Y., et al. (1996). Address allocation for private internets. RFC 1918, section 3. RFC Editor.
9. Baker, F. (Ed.). (1995). Requirements for IP version 4 routers. RFC 1812, sections 5.2.4.3, 5.3.6 and 5.3.12.3. Updated standard, used for forwarding, queues and link failure. RFC Editor.
10. Fielding, R., Nottingham, M., & Reschke, J. (Eds.). (2022). HTTP semantics. RFC 9110, section 3.3, client and server roles. RFC Editor.
11. CERN. (n.d.). The birth of the Web. Opening account of Berners-Lee's 1989 work. CERN.

Vague but exciting

In March 1989 a scientist called Tim Berners-Lee, working at a physics laboratory in Switzerland, handed his manager a document proposing a way to link documents on different computers together.

His manager wrote a comment at the top of it: vague but exciting. He did not say no, and that document became the World Wide Web. The first website was running at CERN by the end of 1990; Berners-Lee announced the web to a wider internet audience in 1991.

The web connects documents and other resources through links. Browsers can also display local files and other kinds of content.

Key idea: A web page is a file. It is not a picture of a page, it is a set of instructions for building one.

A page is text with labels

For our simple page, the browser receives HTML text with labels around the parts. Real sites may also send images, media and data, or build parts of a page while it runs.

The labels are called tags, and they go in angle brackets. Here is a whole tiny page.

• <h4>My Dog</h4>
• <p>My dog is called Biscuit. He is very fast.</p>
• <ul>
• <li>He is brown.</li>
• <li>He hates the postman.</li>
• </ul>

Read it out and you can see what appears: a heading saying My Dog, a paragraph underneath it, and a bulleted list of two things.

Notice the pattern. Most tags come in pairs. One opens, and the closing one has a slash in it. Whatever is between them is the thing being labelled.

This language is called HTML, and it does one job: it says what each piece of content is. A heading. A paragraph. A list. A link. A picture goes here.

Three languages, three jobs

A simple page with only HTML can show headings, paragraphs and links using the browser's default style. A link works only if its address and destination are available.

Add CSS and it becomes blue, or spaced out, or arranged in columns. Nothing new is said, it is just dressed.

Add JavaScript and it starts reacting: a menu opens when you click it, a number counts up, a form tells you that you missed a box. That is the events lesson, running inside a page.

The point: Separating content, appearance and behaviour can make changes easier to manage. They still interact, so test after changing any layer.

What the browser does

Type an address and press enter. Here is a simplified successful page request; its speed depends on the network, device and site.

1. If it needs an address for the name, the browser uses DNS; a recent answer may already be saved.
2. It sends a request to that machine, saying which page it wants.
3. The server sends back the HTML file, in packets.
4. The browser reads the HTML and notices it needs other things too: a stylesheet, some pictures, maybe some JavaScript.
5. It asks for each of those as well, often from several different machines.
6. It works out where everything goes and draws the page.

The browser is doing the assembling. The server sent parts, not a picture. That is why the same page can look different on a phone and on a laptop: the parts are the same and the browser lays them out to fit.

Reading an address

An address has parts, and each one means something.

• https is the rule being used, and the s means the connection is encrypted, so somebody in the middle cannot read it.
• The domain name names a site or service, like example.org. It may lead to more than one machine.
• The path is which page on that machine, like the part after the slash.

HTTPS protects data on the connection, but it does not prove a site's claims are true or its owner is honest. A scam site can use HTTPS. Ask a trusted adult before entering private information.

Links: the thing that made it a web

A link is one HTML tag with an address in it. Click it and the browser goes and asks for that page instead.

That single idea is why it is called a web rather than a library. Any page can point at any other page on any machine in the world, and nobody has to ask permission first. The whole thing is held together by pointing.

You do not need special software

Here is something worth knowing. A web page is just text. On a device with a suitable plain text editor, browser and permission to save files, you can write a simple page, save it with a name ending in .html, and open it locally. Devices differ; ask an adult for help. Our paper activity needs no software.

That is unusual and it is deliberate. Berners-Lee and the group that followed him gave the whole thing away, with no charge and no permission needed, which is a large part of why it spread.

Try it: read the HTML

What appears on screen for each of these?

1. <p>Hello</p>
2. <h4>Shopping</h4> followed by <ul><li>Milk</li><li>Eggs</li></ul>
3. <p>Hello with no closing tag

One: Hello appears as a paragraph. Two: Shopping is a heading, followed by a list containing Milk and Eggs. Three: at the end of this tiny example, HTML permits the paragraph's closing tag to be omitted. Browsers also have defined error-recovery rules; they do not guess like a person. Explicit closing tags make our paper exercises easier to check.

Common misconceptions

• Mistake: a web page is a picture that gets sent to you. Text and instructions get sent, and your browser builds the page. That is why it can rearrange itself to fit a phone.
• Mistake: HTML does the same job as JavaScript. HTML is a markup language for content and structure. In our model, JavaScript handles a changing score. A browser can also provide built-in behaviour for HTML controls.
• Mistake: you need to buy software to make a website. Free editors and browsers can support simple pages, but availability and permissions differ by device. Paper is enough for this lesson.
• Mistake: everything on a page comes from one place. A single page often pulls parts from several different machines, which is why some bits appear later than others.

What to remember

• The web was proposed in 1989 by Tim Berners-Lee, with the first site running at CERN by the end of 1990.
• Our simple HTML page is text with tags that label its content.
• HTML is the content, CSS is the appearance, JavaScript is the behaviour.
• The browser fetches the parts and assembles the page itself.
• An address includes a scheme such as https, a domain name and a path. HTTPS protects the connection, not the truth of the page.
• Links let any page point at any other page, which is what makes it a web.

Sources

1. Wikipedia contributors. (n.d.). World Wide Web. Wikipedia. en.wikipedia.org
2. Wikipedia contributors. (n.d.). Tim Berners-Lee. Wikipedia. en.wikipedia.org
3. Mozilla. (n.d.). Getting started modules. MDN Web Docs, Learn web development. developer.mozilla.org
4. Wikipedia contributors. (n.d.). HTML. Wikipedia. en.wikipedia.org
5. Wikipedia contributors. (n.d.). Web page. Wikipedia. en.wikipedia.org
6. WHATWG. (Living Standard). HTML syntax, Optional tags: paragraph end tags. Source
7. MDN contributors. (2026). Transport Layer Security. Protection in transit. Source
8. CERN. (n.d.). A short history of the Web. First server and browser in 1990. Source

A message that wants you to hurry

A message arrives. It says your account will be closed in twenty four hours unless you click a link and type your password.

Everything about that message is designed to do one thing: stop you thinking. It gives you a deadline. It threatens you with losing something. It puts the button right there, ready.

Treat an unexpected demand for a password as suspicious. It may be phishing: a message impersonating someone to steal information. Do not use its link. Ask a trusted adult to check through an app or address they already know.

Key idea: Pressure to hurry is a warning sign, not proof. Pause and check before acting. Slow down, and go and tell somebody.

What counts as personal information

Some things about you should not be handed out to people you do not know.

• Your full name.
• Where you live, including your street.
• Which school you go to.
• Your phone number and your family's phone numbers.
• Your date of birth.
• Where you will be, and when.
• Passwords, obviously, and anybody else's too.

Pictures count as well, and this catches people out. A uniform may reveal a school. A house photo may reveal a number or street. A cake photo may reveal a name or age. Check what is visible before sharing.

The rule is simple: information about you can identify you or reveal something private, even when it does not give your location. Ask an adult before sharing.

Passwords: long beats complicated

Most people think a good password looks like a mess of symbols. Length matters more.

A short password with a couple of odd characters can be worked out by a computer trying millions of guesses. A long one made of several unrelated words takes very much longer, because there are so many more possibilities to get through.

Several randomly chosen, unrelated words can make a useful passphrase. It must be long, hard to predict and different for each account. Password managers can create and keep other strong passwords. A trusted adult should help choose an approach; never use a password printed in a lesson.

Three more rules go with it.

• Never share it. Not with a friend, not with somebody who says they work for the game, not with anybody who asks in a message. Do not send a password in a message. A trusted adult may help manage a child's account through the service's real sign-in process.
• Do not use the same one everywhere. If one place is broken into, everything else with the same password is open too.
• Do not use things about you. Your name, your pet, your birthday and your football team are the first things anybody guesses.

Remember: Use long, unique and unpredictable passwords, with a trusted adult's help. Length alone does not rescue a familiar phrase.

People online are not always who they say

Here is the hardest thing on this page, and it needs saying plainly.

Online, a person can type anything about themselves. Somebody who says they are ten, and likes the same game as you, and has the same favourite colour, might be. They might not be.

Most people are fine. But you cannot tell from a message, and neither can any adult, which is exactly why the rules are what they are.

1. Never agree to meet somebody you only know online.
2. Never send photographs of yourself to somebody you only know online.
3. If anybody asks you to keep something secret from your parents, tell your parents that day. This is the biggest warning sign there is.
4. If somebody is being strange, uncomfortable or too friendly too fast, stop replying and tell a grown-up.

You deserve help, even if you clicked something or shared a detail. Tell a trusted adult. If the first person does not help or feels unsafe to tell, try another, such as a teacher or caregiver.

Anyone can put anything on the internet

Nothing checks the internet for truth before it goes up. A page can be made by an expert, a company selling something, somebody having a joke, or a person who is simply wrong.

Three questions sort out most of it.

1. Who made this, and why? A museum, a government health site or a university is a different thing from an advert or a video with no name on it.
2. Does anywhere else say the same thing? One place saying something is a claim. Look for independent, trustworthy sources that show their evidence. Three pages repeating the same unsupported story do not make it true.
3. Is it trying to make me feel something strongly? Strong feelings can make you want to share before checking. Pause and look for the original evidence rather than relying on how a post makes you feel.

Pictures need the same treatment. Photographs have been edited for a hundred years, and computers can now produce pictures of things that never happened. A picture is a claim too.

The point: On the internet, believing something needs a reason. Who made it, does anyone else agree, and what does it want from me.

Being the kind one

Messages may be written by people or generated by software. When you write about someone, remember that a real person may read it and be hurt.

Two rules cover almost everything.

• Do not type what you would not say to somebody's face, in front of your family.
• Assume everything you send is permanent and public. Deletion works differently across services. Someone may already have copied or saved a message, so deleting your copy cannot guarantee all copies disappear.

Online harm can spread beyond the first conversation and remain available later. You may not see how another person reacts. That is a reason to be considerate, not a reason to assume everyone is affected in the same way.

If it happens to you

If somebody sends you something unkind, threatening, or that makes you feel horrible, here is the order.

1. Do not reply. Do not retaliate or forward the message; get help rather than arguing.
2. Keep the evidence. Ask an adult to help record ordinary bullying messages. If content is sexual, frightening or unsafe to view, close it and tell an adult; do not download or forward it.
3. Tell a grown-up you trust. A parent, a teacher, anyone. Today, not next week.
4. Block and report. Many services have reporting and blocking tools. An adult can help find them or another safe way to get support.

And one more, which matters just as much: if you see it happening to somebody else, say something kind to them privately, and tell an adult. You do not have to investigate or confront the sender to support someone.

Try it: what would you do?

1. Somebody in a game asks which school you go to.
2. A message says you have won a prize and just need to type your address to claim it.
3. A friend asks for your password so they can play on your account.
4. Somebody sends a nasty message about a classmate and asks you to pass it on.

Answers. One: do not tell them, and mention it to a grown-up, because there is no good reason for that question. Two: treat it as suspicious. Do not use the link or enter your address; ask an adult to verify it independently. Three: no, even for a friend, because the rule has to be simple to be any use. Four: do not pass it on, do not reply to it, keep it, and tell an adult. Passing it on makes you part of it.

Common misconceptions

• Mistake: deleting a message makes it gone. Deletion cannot guarantee removal of copies another person has saved.
• Mistake: if it is on a website, it is true. Nothing checks the internet before publication. Ask who made it and whether anyone else agrees.
• Mistake: a good password is short and complicated. Length, unpredictability and uniqueness all matter. A published example is not a safe password.
• Mistake: telling a grown-up will get me into trouble or get the tablet taken away. You deserve support. If the first adult does not help, tell another trusted adult. The sender is responsible for their harmful behaviour.

Where this leaves us

• Pressure to hurry is a reason to pause and verify.
• Personal information can identify you or reveal private details. Photographs can contain it.
• Use long, unpredictable passwords unique to each account; ask a trusted adult for account help.
• If an online contact asks you to meet, send private pictures or keep a worrying secret, stop and ask a trusted adult for help.
• Believing something online needs a reason: who made it, who else says it, what does it want.
• Do not reply, keep the evidence, tell an adult, block and report.

Sources

1. StopBullying.gov. (n.d.). What is cyberbullying. U.S. Department of Health and Human Services. stopbullying.gov
2. StopBullying.gov. (n.d.). Prevent cyberbullying. U.S. Department of Health and Human Services. stopbullying.gov
3. Federal Trade Commission. (n.d.). How to recognize and avoid phishing scams. FTC Consumer Advice. consumer.ftc.gov
4. Federal Trade Commission. (n.d.). How websites and apps collect and use your information. FTC Consumer Advice. consumer.ftc.gov
5. Common Sense Media. (n.d.). Age based media reviews for families. Common Sense Media. commonsensemedia.org
6. National Cyber Security Centre. (2021). Three random words. Family password guidance, version 2.0. Source
7. StopBullying.gov. (n.d.). Report cyberbullying. Steps to take immediately. Source

Billions of switches, and none of them can say maybe

Digital circuits use electrical states to represent 0 and 1. An on-or-off switch is a useful model for this lesson, not a claim that real electronics have no intermediate voltages.

Which raises an obvious question. If all a computer has is switches that can only be on or off, how does it hold a photograph of your grandmother, a song, and the whole of a book?

The answer is the subject of this lesson, and it is one of the most satisfying things in computing, because you can do it on paper with five bits of card.

Key idea: A digital computer represents stored information with bit patterns. Our on/off cards are a model of those patterns.

A bit is one switch

A bit is one binary digit, 0 or 1. A switch is one way to model it. We write on as 1 and off as 0.

One bit can hold two things. Yes or no. On or off. Left or right.

Two bits can hold four, because there are four patterns: 00, 01, 10, 11. Three bits give eight patterns. Each new bit doubles it.

Eight bits together are called a byte, and a byte can hold 256 different patterns. Remember that number, because it turns up constantly.

Counting with cards

Cut five squares of card. On the first draw 1 dot, then 2 dots, then 4, then 8, then 16. Lay them in a row with 16 on the left and 1 on the right.

Now the rule. A card is either face up, showing its dots, or turned over, showing nothing. To make a number, turn cards over until the dots you can see add up to it. Face up is 1, face down is 0.

Make 13. Start from the left. Is 16 too big? Yes, turn it down. Is 8 needed? Yes, leave it up, and 13 take away 8 leaves 5. Is 4 needed? Yes, and 5 take away 4 leaves 1. Is 2 needed? No. Is 1 needed? Yes.

So 13 is 8 plus 4 plus 1, and the cards read up, up, down, up if you write them from 8, or as a full five card row: 0 1 1 0 1.

Try 21. It is 16 plus 4 plus 1, so 1 0 1 0 1. Try 31. Every card is up: 1 1 1 1 1. Try 0. Every card is down.

The point: Binary is ordinary counting where each place is worth double the one to its right, instead of ten times.

Why the doubling

Look at our normal numbers. In 305, the places are worth 100, 10 and 1, each ten times the one on its right, and each place holds a digit from 0 to 9.

In binary the places are worth 16, 8, 4, 2 and 1, each double the one on its right, and each place holds a digit that can only be 0 or 1.

That is the whole difference. Binary is not a strange kind of maths. It is the same counting with two symbols instead of ten, and computers use it because a switch has two positions.

Letters, from numbers

So numbers are patterns of bits. But a computer holds words too.

The answer is that everybody agreed on a list. Each letter was given a number, and the list is called ASCII.

• Capital A is 65, B is 66, C is 67, and so on up to Z at 90.
• Small a is 97, b is 98, and so on.
• A space is 32.

So the word CAB is stored as three numbers: 67, 65, 66. And each of those is a pattern of bits, since 65 is 64 plus 1, which as eight bits is 0 1 0 0 0 0 0 1.

There is nothing letter shaped anywhere in the machine. There is a number, and an agreement about what that number means. Change the agreement and the same bits mean something else entirely, which is why a file opened with the wrong program comes out as nonsense.

Pictures, from numbers

Look very closely at a screen, or at a photo zoomed right in, and it breaks into little coloured squares. Each square is a pixel.

In one common uncompressed RGB format, each pixel uses three numbers from 0 to 255: red, green and blue. That is one byte per colour channel. Other formats use different amounts of data or add transparency.

• 255 red, 0 green, 0 blue is bright red.
• 255, 255, 255 is white, because all three are full.
• 0, 0, 0 is black.
• 255, 255, 0 is yellow, because red and green light together look yellow.

A picture 1,000 pixels wide and 1,000 high has one million pixels. At three bytes per pixel, its raw RGB data needs three million bytes. File headers, other channels and compression can change the saved file size.

Sounds, from numbers

Sound is air wobbling. A microphone turns changes in air pressure into an electrical signal. Recording equipment samples that signal and stores numbers.

Then it does it again, thousands of times per second. A recording is a very long list of measurements, and a speaker reads the list back and pushes the air the same way.

Digital songs, photos and books can be encoded as bit patterns. The encoding tells a program how to interpret those patterns; real storage does not have to be a row of mechanical switches.

Remember: Words, pictures and sounds are all turned into numbers first. That is the only thing a computer can actually keep.

Try it: convert these

Use the cards 16, 8, 4, 2 and 1, and always start from the biggest.

1. Write 6 in binary.
2. Write 19 in binary.
3. What number is 1 1 0 0 0?
4. What number is 0 0 1 1 1?
5. How many different patterns can 8 bits make?

Answers. One: 6 is 4 plus 2, so 0 0 1 1 0. Two: 19 is 16 plus 2 plus 1, so 1 0 0 1 1. Three: 16 plus 8, which is 24. Four: 4 plus 2 plus 1, which is 7. Five: 256, because each bit doubles it and eight doublings from one gives 256.

Common misconceptions

• Mistake: binary is a different kind of maths. It is the same counting with two symbols. Each place is worth double the one to its right instead of ten times.
• Mistake: a computer stores letters as letters. It stores a number and everybody agrees what that number means. There is nothing letter shaped inside.
• Mistake: 0 means nothing is stored. A 0 is a real value, exactly as meaningful as a 1. The switch being off is part of the pattern.
• Mistake: one bit can hold a letter. One bit holds two possibilities. A single bit cannot distinguish all the letters of an alphabet. ASCII has 128 codes and fits into seven bits, often stored in a byte. Unicode encodings can use more than one byte for a character.

The short version

• A bit is a binary digit, 0 or 1; on/off switches are our model.
• Each extra bit doubles the number of patterns, so eight bits, one byte, give 256.
• Binary place values are 1, 2, 4, 8, 16 and so on, and you build a number from the biggest downwards.
• Letters are numbers by agreement, with capital A at 65 in ASCII.
• In our RGB example, each pixel uses three colour values from 0 to 255.
• Sound is a long list of measurements taken thousands of times a second.

Sources

1. CS Unplugged. (n.d.). Binary numbers. University of Canterbury Computer Science Education Research Group. csunplugged.org
2. Wikipedia contributors. (n.d.). Binary number. Wikipedia. en.wikipedia.org
3. Wikipedia contributors. (n.d.). ASCII. Wikipedia. en.wikipedia.org
4. Wikipedia contributors. (n.d.). Bit. Wikipedia. en.wikipedia.org
5. Wikipedia contributors. (n.d.). Pixel. Wikipedia. en.wikipedia.org
6. Unicode Consortium. (n.d.). UTF-8, UTF-16, UTF-32 and BOM. Encoding forms and bytes per character. Source
7. MDN contributors. (n.d.). ImageData: data property. Pixel formats and channels. Source

Twelve hundred and one

On 20 July 1969, Apollo 11 was on its way down to the Moon. The guidance computer, the computer that steered the landing, reported 1202 and 1201 alarms. Mission control had little time to decide whether the landing could continue.

The alarms meant the computer had been given more work than it could do at once. It did not crash, because the software had been written to handle exactly that. It threw away the least important jobs. It kept the ones needed to land.

A team at MIT built that software. Margaret Hamilton led the team. She is often photographed beside the printed pages of its code, a stack of paper as tall as she is. She is also one of the people who pushed for the phrase software engineering to be taken seriously. That was at a time when writing programs was not considered real engineering.

The landing worked because somebody had thought about this years earlier. They had thought about what should happen when everything went wrong at the worst possible moment.

Key idea: Code matters most in the moments nobody planned for. That is why people think about those moments beforehand.

Where the code actually is

Most people think of games and apps. Those exist, and they are a small part of it.

Every single one of those is built from what you have learned in this course. A route finder is an algorithm. A scan viewer is decomposition and reuse. A screen reader is events. All of them contain loops and conditions and all of them were debugged for months.

The route finder, in one paragraph

Take the map app that finds a route. There might be millions of possible ways to get across a city. So checking them all one at a time would take longer than walking.

One route-finding method works step by step. Again and again, it picks the nearest place that is not settled yet. A place is settled when the best way to reach it is final. All the while, it keeps track of the best distance found so far. When every travel cost, such as time or distance, is zero or more, this method can find a shortest route. Real map apps use many different methods, and they use information such as traffic. This is one example. It is not a description of every app.

Like binary search, route-finding shows why a method matters. The two methods are different. How much of a map must be checked depends on the problem.

Who gets left out

Here is a part of the job that does not get talked about enough.

If a website has small pale grey writing, some people cannot read it. If a video has no subtitles, deaf people cannot follow it. If a form insists on a two part name, people whose names do not work that way cannot sign up. If a game needs fast, precise finger movements, some players are shut out.

These barriers can happen even when nobody meant to leave anyone out. They happen when the person building something imagines a user exactly like themselves.

Remember: The question every builder should ask is who this does not work for. It has to be asked early, because it is expensive to fix late.

It is not one job

People imagine one person in a dark room typing. Real projects involve many people, and most of them are not writing code all day.

• Somebody works out what the thing should do at all, by talking to the people who will use it.
• Designers decide how it looks and how it feels to use.
• Programmers build it.
• Testers try very hard to break it, which is a real job and a satisfying one.
• Writers explain it.
• Somebody keeps it working after it is finished, which is usually the longest part.

And a huge number of people use a little code inside another job. They are biologists, historians counting words in old books, farmers, accountants and musicians. Code is a tool, like writing. You do not have to be a novelist to find writing useful.

What you already have

This course built up five ideas. They are useful starting points for many kinds of programming.

1. Sequence. One thing after another, in order.
2. Loops. Doing something again without writing it again.
3. Conditions. Choosing between two roads.
4. Events. Waiting, and reacting when something happens.
5. Debugging. Finding out why it did something else, calmly, one change at a time.

On top of those sit the habits. Break it into pieces. Name what you have solved. Pick a better method. Check what happens at the edges.

A new language brings new rules and ideas too. These foundations help you ask useful questions. What changes? What repeats? How can I test it?

If you want to carry on

The paper route needs no account. Scratch and Code.org offer free learning tools. Before you use an online service, a trusted adult should check its current privacy settings, its account requirements, and whether it suits you. Do not upload personal details for this course.

• Scratch, originally developed at MIT, lets you drag blocks together to make games and animations. The blocks are named after exactly the ideas in this course.
• Code.org has short puzzle courses for this age group, including the Hour of Code.
• Paper still works. Design a game as an event table. Write an algorithm for a card trick. Trace a friend's instructions and find the bug.

Three pieces of advice from people who do this for a living. Make something small. Finish it, even if it is worse than you hoped. Show it to somebody. A program nobody has ever used is a program whose bugs are all still in it.

Try it: plan something

Pick anything: a quiz about your family, a maze game, a program that tells you what to pack for a trip.

1. Write one sentence saying what it does.
2. Split it into four to six pieces.
3. List the events it has to wait for.
4. Find one thing that repeats, and describe it as a loop.
5. Find one choice it has to make, and write it as IF and ELSE.
6. Write down two things that could go wrong, and what should happen when they do.

That page is a design. Professionals produce almost exactly the same thing before they write anything. Step six is the one that separates a program that works in a demonstration from one that works in a house.

Common misconceptions

• Mistake: you have to be brilliant at maths. Some fields need heavy maths and most do not. Being careful, patient and clear matters far more.
• Mistake: programmers work alone. Almost all real software is built by teams, and explaining your work to other people is a large part of the job.
• Mistake: you need an expensive computer to start. Everything in this course was done with paper. Scratch and Code.org run in a browser and cost nothing.
• Mistake: code is mostly for games. Games are a small corner. Hospitals, weather, farms, films, telescopes and buses all run on code.

What you now know

• The Apollo landing software survived an overload in 1969 because somebody had planned for it.
• Code runs scanners, forecasts, routes, films, screen readers, telescopes and buses, not only games.
• Route finding and binary search show how a suitable method can reduce the work. They solve different problems with different rules.
• Builders have to ask early who their thing does not work for.
• Real projects need designers, testers, writers and maintainers, not only programmers.
• Sequence, loops, conditions, events and debugging give you a starting toolkit. More ideas remain to learn.

Sources

1. Wikipedia contributors. (n.d.). Margaret Hamilton (software engineer). Wikipedia. en.wikipedia.org
2. Wikipedia contributors. (n.d.). Apollo Guidance Computer. Wikipedia. en.wikipedia.org
3. NASA. (n.d.). Mars 2020: Perseverance Rover. NASA Science. science.nasa.gov
4. Code.org. (n.d.). Computer science for ages 5 to 11. Code.org. code.org
5. Scratch Team, MIT Media Lab. (n.d.). Scratch: imagine, program, share. Massachusetts Institute of Technology. scratch.mit.edu
6. NASA. (n.d.). Apollo 11 Lunar Surface Journal: The first lunar landing. Computer alarm transcript. Source
7. W3C Web Accessibility Initiative. (n.d.). Introduction to web accessibility. Barriers and examples. Source
8. Scratch Foundation. (2026). Scratch. Free block-based programming; current organisation. Source
9. Sedgewick, R., and Wayne, K. (n.d.). Shortest paths, section 4.4: Dijkstra algorithm. Princeton Algorithms textbook companion. Source