Key Stage 4 computing · Computational thinking

GCSE computational thinking and programming: a guide for parents

Computational thinking is a way of tackling problems so that a computer can help solve them: breaking a big task into steps, spotting patterns, ignoring unnecessary detail and writing precise instructions. At Key Stage 4 pupils analyse problems in computational terms and get repeated practical experience of writing programs to solve them. It is the heart of GCSE computer science, and it builds a habit of careful, logical thinking that is useful far beyond computing.

Computational thinking and programming, explained

The statutory curriculum says pupils should develop and apply their analytic, problem-solving, design and computational thinking skills, and that they should be able to analyse problems in computational terms and have repeated practical experience of writing computer programs to solve them. The word “repeated” is important: nobody learns to program by reading about it. Expect your child to write many small programs, make mistakes, find them and fix them. Every pupil must also have the chance to study computer science in enough depth to progress to further study or a career. Schools choose how to provide this, and pupils who take GCSE computer science do their programming in a text-based language chosen by the school.

The thinking has some well-known parts. Decomposition means splitting a problem into smaller ones that can be solved separately. Abstraction means keeping the details that matter and leaving out the ones that do not, for example a map of a rail network shows stations and connections but not the real distances. Pattern recognition means noticing that a new problem resembles an old one. Algorithmic thinking means writing a precise, ordered set of steps. Teachers often ask pupils to plan in pseudocode or a flowchart before they type anything.

Programs are built from a few ideas that appear in every language: variables that store values, selection (if something is true, do this, otherwise do that), iteration (repeating steps in a loop), and subroutines (named blocks of code that can be reused). Pupils work with different kinds of data, including whole numbers, decimals, text and true or false values, and with lists of items. They also learn standard techniques, such as searching a list for an item and sorting a list into order.

Just as important is checking that code works. Pupils trace a program by hand with a table that records each variable as the steps run, and they test it with carefully chosen data: normal values, values at the edges of what is allowed, and values that should be rejected. When a program fails they learn to separate errors in the rules of the language (syntax errors) from errors in the logic, where the program runs but gives the wrong answer. Debugging patiently, and explaining what went wrong, is a skill in itself.

Words your child will hear

Algorithm: A precise, ordered set of steps for solving a problem.
Decomposition: Breaking a problem into smaller, more manageable parts.
Abstraction: Removing unnecessary detail so that only what matters is left.
Variable: A named place in a program that stores a value, which can change as the program runs.
Iteration: Repeating a set of instructions, usually with a loop.
Trace table: A table used to follow a program by hand, recording each variable at each step.
Boundary data: Test values at the very edge of what is allowed, such as 0 and 100 for a mark out of 100.

What the National Curriculum says

The programme of study for Key Stage 4 says:

All pupils should be taught to develop and apply their analytic, problem-solving, design, and computational thinking skills
Aim: pupils can analyse problems in computational terms, and have repeated practical experience of writing computer programs in order to solve such problems.
All pupils must have the opportunity to study aspects of information technology and computer science at sufficient depth to allow them to progress to higher levels of study or to a professional career.

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

Try it: planning and tracing a marks program

Write a program that asks for five test marks, each between 0 and 100. If a mark is outside that range it must be rejected and asked for again. At the end it prints the mean and the highest mark. Plan it and check it with the marks 72, 105, 64, 88, 91, 55.

Analyse the problem. Input: marks typed in. Process: check each one, add the valid ones to a total, track the highest, and count them. Output: the mean (total divided by 5) and the highest mark.
Decompose it into small parts: get one valid mark, update the total, update the highest, repeat five times, then calculate and print.

Write the plan in pseudocode. The loop counts valid marks, so a rejected mark does not use up one of the five.

total = 0
highest = 0
count = 0
WHILE count < 5
  INPUT mark
  IF mark < 0 OR mark > 100 THEN
    PRINT "Enter 0 to 100"
  ELSE
    total = total + mark
    IF mark > highest THEN
      highest = mark
    ENDIF
    count = count + 1
  ENDIF
ENDWHILE
mean = total / 5
PRINT mean, highest

Trace the program with the data. The 105 is rejected, so the count and total do not change on that step.

mark  total  highest  count
72      72     72       1
105     72     72       1
64     136     72       2
88     224     88       3
91     315     91       4
55     370     91       5

Work out the result by hand to confirm it: 370 ÷ 5 = 74, and the largest valid mark is 91.
Choose test data. Normal: 50. Boundary: 0 and 100, which must be accepted, and −1 and 101, which must be rejected. Erroneous: typing the word “ten”. This plan would crash on that input, so a robust version needs an extra check that the input is a whole number before comparing it.

The program prints a mean of 74 and a highest mark of 91, because 105 is rejected and asked for again. The trace table matches the hand calculation, so the logic is correct for this data. Boundary and erroneous tests come next, and the erroneous test shows the program needs a type check added.

Common mistakes and how to help

Starting to type code before understanding the problem

Typing feels like progress, and the first run of a program is rewarding even when it is wrong.

What helps: Ask your child to explain, in plain English, what goes in, what happens and what comes out, before they write a line. A few minutes of planning usually saves much longer in debugging.

Thinking the computer will understand what you meant

People fill in gaps automatically when talking. A computer follows exactly what is written, so a missing step or a wrong symbol gives a wrong result.

What helps: Try giving instructions for a simple task, such as making toast, and follow them literally. It shows how much detail an algorithm needs.

Confusing = in programming with “equals” in maths

In many languages one equals sign means “store this value in this variable”, as in count = count + 1, which looks impossible in algebra. A different symbol is usually used to compare values.

What helps: Read count = count + 1 aloud as “take the old value of count, add 1, and store it back”. A trace table shows the value changing.

Testing only with data that is likely to work

Children naturally try values they expect to pass, so errors at the edges, such as entering exactly 100, stay hidden.

What helps: Ask what the most unusual input would be. Choosing normal, boundary and erroneous data on purpose is a core skill that teachers look for.

How to help at home

Ask them to explain a program like a story. Ask your child to talk you through something they have written: what it needs, what it does, where it could go wrong. You do not need to understand the code to ask good questions.
Give instructions literally. Take turns writing exact steps for an everyday job, such as drawing a house or making a drink, and follow them to the letter. The gaps and ambiguities that appear are the same ones that cause bugs.
Trace by hand. Pick a short loop from their work and fill in a table with a pencil, one line per step, before running it. Predicting the output and then checking is excellent practice.
Break down a real task. Planning a trip or a family meal is a decomposition exercise. Ask for the main parts, what depends on what, and what could be reused next time.
Celebrate finding the bug. Everyone writes faulty code. Praise the detective work of narrowing down the problem rather than getting it right the first time, and encourage short breaks when they are stuck.

Builds on

Key Stage 3: Abstraction and modelling