Teaching Computing Inclusively

Programming asks a lot of pupils at once. They have to hold an idea in their head, translate it into precise instructions, type those instructions without errors, and then work out why the computer did something different. For a pupil with dyslexia, ADHD, a language need or low confidence, any one of those steps can become the point where they stop.

Computing teachers have built up a useful set of approaches that lower those barriers without lowering the challenge. None of them is specific to SEND. They help most pupils, and they help some pupils a great deal.

Start away from the screen

Unplugged activities teach computing concepts without a computer. CS Unplugged, a free collection from the Computer Science Education Research Group at the University of Canterbury in New Zealand, uses cards, string, crayons and movement to teach ideas such as binary, sorting and searching.

Unplugged work suits inclusive teaching for several reasons. It removes typing and syntax from the first encounter with an idea. It gets pupils moving and talking. It gives everyone a shared, concrete reference point to come back to later.

A few classroom examples:

• Pupils write step-by-step instructions for a partner to draw a simple shape, then compare the result with the original. This makes the need for precise algorithms obvious, often with a lot of laughter.
• A line of pupils holding numbered cards acts out a sorting algorithm, swapping places according to the rules.
• A “human robot” follows only the commands forward, turn left and turn right, while classmates try to guide it around desks.

When you move onto the computer, refer back to the activity: “Remember when Sam walked into the wall? That was a bug in our algorithm.”

Read before you write: PRIMM

PRIMM stands for Predict, Run, Investigate, Modify, Make. It was developed by Sue Sentance and colleagues and described in a 2019 paper in Computer Science Education. The approach draws on research suggesting that reading and tracing code supports learning to write it.

The stages work like this:

1. Predict. Pupils look at a short working program and discuss, in pairs, what they think it will do.
2. Run. They run it and compare the result with their prediction.
3. Investigate. They explore how the code works through tracing, annotating, answering questions or finding deliberate bugs.
4. Modify. They make small changes, which grow in difficulty, to change what the program does.
5. Make. They write a new program that uses the same ideas for a different purpose.

Sentance and colleagues report a study with around 500 learners aged 11 to 14 in which PRIMM lessons were linked to improved learning outcomes.

PRIMM helps inclusion because pupils begin with code that works. Nobody faces a blank screen in the first ten minutes. The Predict stage is low stakes (a wrong prediction is just interesting), and the talk in pairs gives pupils with weaker reading or writing a way in. The Modify stage lets you pitch tasks at different levels within the same lesson: one pupil changes a colour, another adds a condition.

Parsons problems

A Parsons problem gives pupils all the lines of a working program, jumbled up, and asks them to put them in the right order. Parsons and Haden described these “programming puzzles” in a 2006 paper as a way to practise syntax and logic with more engagement than conventional drill exercises.

Because every line is already written, pupils can focus on the logic and structure of the program. Typing errors and half-remembered keywords stop being an obstacle. For pupils with dyslexia, dyspraxia or slow processing speed, this can be the difference between taking part and giving up.

You can make Parsons problems easier or harder:

• Easier: fewer lines, indentation already done, the first line fixed in place.
• Harder: extra “distractor” lines that are not needed, or indentation left for pupils to work out.

They work on paper as cut-up strips, which brings them close to unplugged work, and there are free online tools for creating them.

Pair programming

In pair programming, two pupils share one computer. The driver controls the keyboard and mouse. The navigator reviews the code, spots errors and thinks about the bigger task. They swap roles regularly.

The National Centre for Computing Education’s quick read on pair programming suggests swapping every five to ten minutes and planning pairs in advance. It summarises research suggesting that pairing can reduce individual cognitive load, and that in introductory courses, women who worked in pairs reported higher confidence than those who worked alone.

To make pairing inclusive:

• Plan pairs deliberately rather than leaving pupils to choose.
• Teach the roles explicitly, with sentence starters for navigators (“Can we check line 4?”, “What if we tried…”).
• Use a timer for swaps so one pupil does not dominate.
• Watch for pairs where one partner does everything, and step in.
• Assess individual understanding as well as the joint product.

Some pupils find pairing hard, perhaps because of anxiety or social communication differences. A clear structure helps. So does pairing them with a patient partner, or letting them start as navigator with a written checklist.

Make the tools accessible

Small adjustments to the software environment can matter a lot:

• Increase zoom in block-based and text editors. Some pupils struggle with small text but will not say so.
• Check colour contrast in themes, and avoid relying on colour alone to show meaning.
• Show pupils the text-to-speech and dictation tools available on school devices.
• Provide printed or digital reference sheets of key commands and syntax, so memory is not the barrier.
• Turn on line numbers so you can say “look at line 12” instead of “the bit near the bottom”.
• For pupils who find mouse control difficult, teach keyboard shortcuts.

Talk to your SENCO and the pupil about what helps. A pupil’s support plan may already list adjustments, such as extra time or a reader, that also apply in computing lessons.

Supporting SEND pupils in programming

Some approaches that help across a range of needs:

• Break tasks into small, visible steps on a checklist pupils can tick.
• Give worked examples, then partially completed examples, before independent work.
• Keep the lesson routine predictable: same start, same layout, same place to find files.
• Teach a debugging routine (read the error, check the line, compare with the example, ask a partner, then ask an adult).
• Celebrate bugs found and fixed. Errors are a normal part of programming, and pupils who fear getting things wrong need to hear that.

If you have a TA in the room, share the program and the likely sticking points beforehand, so they can prompt rather than type the code for the pupil.

Further reading

• Bell, T., Witten, I. H. and Fellows, M. (1998). Computer Science Unplugged: off-line activities and games for all ages. Now maintained as CS Unplugged by the Computer Science Education Research Group, University of Canterbury (csunplugged.org).
• National Centre for Computing Education. Pedagogy Quick Read: Pair programming.
• National Centre for Computing Education. Pedagogy Quick Read: PRIMM.
• Parsons, D. and Haden, P. (2006). Parson’s Programming Puzzles: A Fun and Effective Learning Tool for First Programming Courses. Proceedings of the Eighth Australasian Computing Education Conference (ACE2006).
• Sentance, S., Waite, J. and Kallia, M. (2019). Teaching computer programming with PRIMM: a sociocultural perspective. Computer Science Education, 29(2-3), 136-176.