A progression that works

Younger pupils start with direct instructions, pressing arrow buttons on a floor robot to store a sequence. This builds the habit of planning steps before acting. From around age seven or eight, block-based environments such as Scratch, MakeCode for micro:bit or the LEGO Education SPIKE app let pupils drag commands together without worrying about spelling or syntax.

Secondary pupils can then move to text, usually in the first or second year of secondary school once block programs become long and hard to read. MakeCode and SPIKE both offer Python, which lets pupils compare a familiar block program with its written equivalent. Arduino boards, programmed in a C-based language, suit older students interested in electronics.

There is no need to rush this move. Pupils who understand loops, conditions and sensor readings in blocks transfer that understanding to text quickly; pupils who move early without it tend to copy code they cannot explain.

Concepts to build in order

Robot programming covers the same core ideas as any computing course, but each one has a physical result pupils can watch.

• Sequence: steps run in order, so a wrong order gives a wrong route.

• Repetition: loops make patterns such as squares or zigzags.

• Selection: if statements let the robot react to a sensor reading.

• Variables: storing a speed or a count so it can be changed in one place.

• Calibration: measuring what the sensor actually reads before trusting it.

Sample lesson: stop before the wall

For pupils aged 10 to 12, allow 60 minutes. Each pair needs a robot with a distance or ultrasonic sensor, a laptop or tablet, a tape measure and a cardboard box as the wall. Pupils first display the sensor reading on screen and record values at 10, 20 and 30 centimetres. They then write a program that drives forward until the reading falls below a chosen value and stops. Finally, they test at a slow and a fast speed and note whether the robot stops at the same distance, then discuss why it may not.

Supporting pupils who get stuck

Encourage pupils to change one thing at a time and to test short sections of code before joining them. A printed debugging checklist on each table (batteries, cables, port numbers, sensor direction) saves a lot of teacher time. Pairing roles, with one pupil at the keyboard and one watching the robot, keeps both pupils involved.

Ask pupils to predict what the robot will do before each run and to write the prediction down. Comparing prediction with result is where much of the learning happens, and it gives the teacher a quick view of who understands the code.

Key points

• Move from buttons to blocks to text as confidence grows.

• Teach sensor calibration explicitly; readings are rarely perfect.

• Test small pieces of code before building long programs.

• Rotate keyboard and observer roles within each pair.

Photos: stem.T4L, Sahand Babali / Unsplash