Key Stage 3 computing · Programming

KS3 text-based programming: a guide for parents

In Years 7 to 9, children are expected to write programs in at least two programming languages, and at least one of them must be a text-based language where code is typed rather than dragged into place. The aim is to move from copying examples to analysing a problem, planning a solution and building it through lots of practical programming, including finding and fixing their own mistakes.

Text-based programming, explained

In primary school most children program with block-based tools, snapping instructions together on screen. The ideas behind those blocks are already familiar: putting instructions in sequence, making choices with “if”, repeating with loops and storing values in variables. At Key Stage 3 the national curriculum asks schools to teach at least two programming languages, and at least one has to be textual. The school chooses which. Many schools choose Python, because its code reads fairly close to plain English, and the examples on this page use it, but your child’s school may use another. The second language might be another text language, a block-based one, or one used to control a small physical device.

The biggest change is that a text language is strict about spelling and punctuation, which is called syntax. A missing bracket, a capital letter in the wrong place or a line that is indented differently can stop a whole program from running. Children often find this frustrating at first, because the computer will not guess what they meant. The error messages that appear look intimidating, but they usually name the line where the language got confused, and learning to read them is one of the most useful skills in the whole topic.

The curriculum also says pupils should analyse problems in computational terms. In practice this means that before typing anything, your child breaks a problem into smaller parts (decomposition), decides what information matters and what can be ignored (abstraction), and writes the steps of a solution (an algorithm), perhaps as a flowchart or in pseudocode, which is plain-English steps laid out like code. A useful habit is to list the inputs, the processing and the outputs of a program before writing a line.

Programs at this stage solve a variety of problems: simple games, calculators, quizzes, programs that turn data into a summary, or programs that draw patterns. Pupils use selection, loops, variables and different data types, and many schools add data structures and pupils’ own functions as they go through Years 8 and 9. Those have their own guides. The programme of study asks for repeated practical experience, so expect many short programs rather than a single large project, with plenty of testing along the way.

Schools assess this in different ways, but much of the evidence comes from the programs your child writes and how well they can explain, test and improve them, not just from learning definitions. If your child chooses GCSE computer science, it builds directly on these programming skills, so the confidence gained in Years 7 to 9 pays off. For now, the goal is for the keyboard to stop feeling like a barrier and for your child to see an error as a clue, not a failure.

Words your child will hear

Syntax: The spelling, punctuation and layout rules of a programming language. Break them and the program will not run.
Variable: A named place that stores a value, such as score or total, which can change as the program runs.
Data type: The kind of value stored, such as whole number (integer), decimal (float), text (string) or true/false (Boolean).
Selection: Choosing what happens next using a condition, usually with “if” and “else”.
Iteration: Repeating instructions with a loop, either a set number of times or until a condition changes.
Debugging: Finding and fixing mistakes (bugs) in a program.
Test data: Values chosen on purpose to check a program, including ones at the edge of what it should accept.

What the National Curriculum says

The programme of study for Key Stage 3 says:

Pupils should be taught to use 2 or more programming languages, at least one of which is textual, to solve a variety of computational problems; make appropriate use of data structures [for example, lists, tables or arrays]; design and develop modular programs that use procedures or functions
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: turning a problem into a program

Write a program that asks how many people are in a group and prints the total ticket cost. Tickets cost £8 each, and groups of 5 or more get £10 off the total.

Analyse the problem before typing. Input: the number of people. Processing: multiply by 8, then take off 10 if the group has 5 or more. Output: the total cost.
Turn the plan into code. The input() command always gives back text, so int() changes it into a whole number we can multiply. The colon after the if line, and the indented line below it, are part of the syntax.
```
people = int(input('How many? '))
total = people * 8
if people >= 5:
    total = total - 10
print('Total cost: £' + str(total))
```
Test with chosen data, tracing by hand first. For 3 people: 3 × 8 = 24, and 3 is not 5 or more, so the output should be £24. For 6 people: 6 × 8 = 48, then 48 − 10 = 38.
Test the edge of the rule. For 4 people the total is £32, and for 5 people it is 5 × 8 = 40, minus 10, which is £30. A group of 5 pays less than a group of 4. The program is doing what the rule says, which tells us the rule itself is odd and worth raising with whoever set it.
Debug a typical slip. If int() is left out, input returns the text “3”, and in Python “3” * 8 makes “33333333” instead of 24. Reading the output closely and comparing it with the trace shows where the problem is.

The program prints £24 for 3 people, £32 for 4, £30 for 5 and £38 for 6. Planning, tracing by hand and testing at the boundary of the rule are what turn typing into programming.

Common mistakes and how to help

Thinking a syntax error means the idea is wrong or that they are bad at coding

The computer is completely literal, so a missing bracket or a capital letter stops everything. Children who are used to being understood by a person take the red message personally.

What helps: Read the last line of the error message together and find the line number it points to. Treat each error as the computer telling you where to look. Even experienced programmers meet errors all the time.

Reading total = total - 10 as an impossible equation

In maths the equals sign means both sides are the same. In most programming languages, one equals sign means “store the answer on the right in the name on the left”, which is called assignment.

What helps: Say it aloud as “make total become total minus 10”. Tracing a short program on paper with a column for each variable shows the value changing line by line.

Treating numbers typed by the user as numbers

A keyboard produces text, and the digit 5 looks the same as the text “5”. Children are often puzzled when an answer joins numbers together instead of adding them, as in “5” + “3” giving “53”.

What helps: Ask what data type each value has. Print the type, or convert with int() and float(), and notice how results change.

Copying a working program without understanding it, then being stuck when it needs changing

Copying feels quick and the program runs. But if your child cannot say what each line does, the first change goes wrong with nothing to hold on to.

What helps: Ask them to predict the output before running a program, then change one value or line and predict again. Being able to explain a line in their own words is a better sign of progress than a program that runs.

How to help at home

Ask for a guided tour. Ask your child to explain, line by line, a program they have written at school. You do not need to know how to code. Questions like “what happens if the user types 0?” or “what does this line do?” push them to reason it through.
Predict, then run. Before your child runs a program, ask what it will print. Wrong guesses are useful because they show exactly which idea needs work. Tracing a few lines on paper builds the same skill.
Solve a small family problem. A pocket-money tracker, a quiz about family birthdays or a tip calculator are small, real problems with clear inputs and outputs. Ask your child to plan on paper first: what goes in, what is worked out, what comes out.
Let them stay stuck for a bit. When there is an error, resist fixing it. Ask “what does the message say, and which line does it mention?” Ten minutes of searching on their own usually teaches more than being shown the answer.
Compare blocks and text. If your child used block-based coding in primary school, ask how they would write the same project now in typed code. Seeing that loops, choices and variables are the same ideas in a different form builds confidence about the second language.

Builds on

Key Stage 2: Designing, writing and debugging programs
Key Stage 2: Controlling and simulating physical systems
Key Stage 2: Decomposition: breaking problems down
Key Stage 2: Sequence in programs
Key Stage 2: Selection: if and else
Key Stage 2: Repetition and loops
Key Stage 2: Variables, input and output
Key Stage 2: Explaining how algorithms work
Key Stage 2: Debugging algorithms and programs