KeyStage

Key Stage 2 computing · Algorithms and programming

KS2 coding: designing, writing and debugging programs

Across Key Stage 2, children are taught to design, write and debug programs that accomplish specific goals. That means starting with a clear aim, planning the steps, building the program, testing it and fixing what does not work. Along the way they solve problems by breaking them into smaller parts and use logical reasoning to work out why something went wrong. It is a way of thinking as much as a way of typing.

Designing, writing and debugging programs, explained

The programme of study asks pupils in Years 3 to 6 to design, write and debug programs that accomplish specific goals, including controlling or simulating physical systems, and to solve problems by decomposing them into smaller parts. The important phrase is “specific goals”. A child is not just playing with a coding tool; they are making something for a purpose, such as a quiz that keeps score, an animation that tells a short story, or a game with a clear way to win. Which programming language or tool a school uses is its own choice, and most primary schools use block-based tools that snap instructions together on the screen.

Most schools teach a loop of design, write, test and debug. First children state the goal in a sentence. Then they plan: a list of steps, a flowchart, a storyboard, or notes on what should happen when. Planning is where an algorithm is born, a precise set of instructions that someone or something could follow without guessing. Next they write the program and run it. Then they test it by trying it, and compare what it does with what they expected. Finally they debug, which means finding and fixing mistakes, usually called bugs.

Debugging is a big part of the objective, and it is taught as a calm, logical skill. Children are encouraged to read their instructions aloud, to trace through them one line at a time as the computer would, and to test small sections separately. They learn to change one thing at a time so they can see which change made the difference. A bug is an ordinary event, not a sign of failure. The computer follows instructions exactly, so when the result is wrong, the instructions are wrong somewhere, and the job is to find the line.

Over the key stage the goals become bigger and the tools richer. Younger pupils may build a short sequence of instructions to move a character, while older pupils combine sequence, selection (if/else) and repetition (loops), and use variables to keep track of things such as a score. They also begin to explain how simple algorithms work using logical reasoning, and to spot and correct errors in both algorithms and programs. Alongside these skills sits work on how programs can control or simulate physical systems, such as a model traffic light or a virtual pet.

You do not need to be able to code to help. Your best contributions are curious questions: “What is it meant to do?”, “What did you expect to happen?” and “Which part do you think is wrong?” These are the same questions teachers ask, and they keep the thinking with your child.

Words your child will hear

Algorithm
A precise set of steps for solving a problem or completing a task.
Program
An algorithm written in a language a computer can follow.
Debug
To find and fix mistakes in an algorithm or program.
Bug
A mistake in a program that makes it do something unintended.
Decompose
To break a big problem into smaller, easier parts.
Test
To run a program and check whether it does what it was designed to do.
Goal
What the program is meant to achieve.

What the National Curriculum says

The programme of study for Key Stage 2 says:

  • Pupils should be taught to design, write and debug programs that accomplish specific goals, including controlling or simulating physical systems; solve problems by decomposing them into smaller parts
  • Pupils should be taught to use logical reasoning to explain how some simple algorithms work and to detect and correct errors in algorithms and programs
  • Aim: pupils can analyse problems in computational terms, and have repeated practical experience of writing computer programs in order to solve such problems.

Objectives from the National Curriculum in England, © Crown copyright, used under the Open Government Licence v3.0.

Try it: getting a robot to the flag

On a four-by-four grid, a robot starts on the square marked S, facing up the page. It must reach the flag, F, without landing on a blocked square (X). Plan a program, test a first attempt (forward 3, turn right, forward 2) and debug it.

  1. State the goal and draw the problem. The robot starts at the bottom left and the flag is at the top right. Blocked squares are marked X.
    . . . F
    . X . .
    . X X .
    S . . .
  2. Plan an algorithm. Children often plan in words first: go up the left-hand edge, turn towards the flag, then go along the top row. Count the squares: the robot needs to move up 3 squares, then right 3 squares.
  3. Write the program. Suppose the first attempt, typed in quickly, is forward 3, turn right, forward 2. It looks close to the plan, so it needs testing before anyone assumes it works.
  4. Test the first attempt by tracing it, as the computer would. Forward 3 puts the robot in the top left corner. Turn right makes it face along the top row. Forward 2 moves it two squares, so it stops one square before the flag.
  5. Debug. The error is in the last instruction: the distance is one too short. Change forward 2 to forward 3, so the program becomes forward 3, turn right, forward 3. Run it again and check the robot lands on F. Also check it avoided every X, which it does because it only travelled along the left edge and top row.

The working program is forward 3, turn right, forward 3. The first attempt had a bug in its last instruction (forward 2 instead of forward 3), found by tracing the program step by step.

Common mistakes and how to help

Starting to code straight away without a plan

Dragging blocks around is fun and quick, so children skip the thinking. The result is often a tangle of instructions that is hard to fix.

What helps: Ask for a sentence describing the goal and a quick sketch or list of steps first. Even two minutes of planning makes testing and debugging easier.

Believing a program with no error message must be right

Some tools only complain about a few kinds of mistake. A program can run perfectly and still do the wrong thing.

What helps: Teach children to test against what they expected. Ask, “What should happen if you press that?” and then try it, including unusual cases.

Thinking a bug means the computer is wrong or you are bad at coding

Children expect computers to work out what was meant. When they do not, frustration sets in quickly.

What helps: Say that bugs happen to everyone, including professional programmers. The computer does exactly what it is told, so the answer is to read the instructions as it would. Celebrate every bug found.

Rebuilding the whole program when one part is wrong

It feels easier to start again than to work out where the problem is.

What helps: Show how to test one section at a time and change one thing per test. Tracing the program line by line usually finds the mistake faster than rebuilding.

How to help at home

  • Ask the three questions. When your child shows you a program, ask “What is it meant to do?”, “What did you expect?” and “What actually happened?” These questions lead children to find the bug themselves.
  • Play robot. Mark out a simple grid on the floor with paper or masking tape, and have your child give you instructions such as “forward 2, turn right, forward 1” to guide you to a chosen square. Let them watch you follow the instructions exactly, bugs and all.
  • Plan before you build. Before your child starts a new coding project, ask them to draw a quick plan or list the steps. It builds the habit of designing first, which is what the curriculum is looking for.
  • Debug everyday instructions. Follow a recipe card or a set of building steps that has a deliberate mistake in it and spot where it goes wrong. It is the same logical reasoning, with no screen needed.
  • Praise the fix. When your child finds and fixes a bug, make a point of noticing the persistence rather than the result. “You tried three things before you found it” teaches resilience that goes well beyond coding.

Leads on to

Everything in Key Stage 2 computing

Updated .