Higher Computing Science

1. Predict before you run

The research. PRIMM stands for Predict, Run, Investigate, Modify, Make. Pupils first predict what a piece of code will do, then run it, then work with it. In a study across 13 schools with 493 pupils aged 11 to 14, classes taught with PRIMM did better on a programming test than classes taught as usual, and teachers said it helped every pupil in a mixed-ability class make progress.

What we do. The Python lessons ask for a prediction the first time an example is run, then compare it with what really happens. The SQL lessons ask how many records a query will show before it runs.

Sentance, S., Waite, J. and Kallia, M. (2019). Teaching computer programming with PRIMM: a sociocultural perspective. Computer Science Education, 29(2-3), 136-176. doi.org/10.1080/08993408.2019.1608781

2. Read and trace code before you write it

The research. A study of over 500 students in seven countries found that many beginners could not reliably say what a short piece of code would do. The authors argued that this weak grasp of reading code holds back problem solving. Reading and tracing come first.

What we do. Many quiz questions ask what a program will display or store, or what a query will output, which is also how the exam tests it. The Python lessons run the standard algorithms on real data, so you can see what each one does.

Lister, R. et al. (2004). A multi-national study of reading and tracing skills in novice programmers. ACM SIGCSE Bulletin, 36(4), 119-150. Open-access copy

3. Put code in order before writing it from scratch

The research. In a Parsons problem the learner puts mixed-up lines of code into the right order. Studies found that students solved Parsons problems much faster than fixing or writing the same code, with the same learning gains.

What we do. Quizzes include "put the lines in order" and "complete the code" questions for the longer algorithms, such as linear search and file handling. The coding lessons then ask pupils to write the code themselves.

Ericson, B., Margulieux, L. and Rick, J. (2017). Solving Parsons problems versus fixing and writing code. Proceedings of the 17th Koli Calling International Conference on Computing Education Research, 20-29. Find it

4. Spread your practice out

The research. A review of 317 experiments found that practice spread out over time is remembered far better than the same practice crammed together, and that the best gap grows with how long you need to remember it.

What we do. Your dashboard has a Keep it fresh list. A topic you have passed comes back a week later, then after two weeks, then every four weeks. Each retake has new questions, and your best score still counts.

Cepeda, N., Pashler, H., Vul, E., Wixted, J. and Rohrer, D. (2006). Distributed practice in verbal recall tasks: a review and quantitative synthesis. Psychological Bulletin, 132(3), 354-380. doi.org/10.1037/0033-2909.132.3.354

5. Test yourself, don't just re-read

The research. Taking a test is not only a way of measuring learning: recalling an answer makes the memory stronger. Students who practised by testing themselves remembered more a week later than students who spent the same time re-reading.

What we do. Practice quizzes for every topic, with questions picked at random so they are different each time, and mixed review quizzes for each unit.

Roediger, H. and Karpicke, J. (2006). Test-enhanced learning: taking memory tests improves long-term retention. Psychological Science, 17(3), 249-255. Find it

6. Learn most from the mistakes you were sure about

The research. When people get an answer wrong that they were confident about, and are then told the right answer, they are more likely to remember the correction than for answers they were unsure of. This is called the hypercorrection effect.

What we do. Under every quiz question you can say how sure you are. It never changes your marks. When you were certain but wrong, the feedback says so, and your dashboard lists those topics first, because they are where your understanding needs fixing.

Butterfield, B. and Metcalfe, J. (2001). Errors committed with high confidence are hypercorrected. Journal of Experimental Psychology: Learning, Memory, and Cognition, 27(6), 1491-1494. doi.org/10.1037/0278-7393.27.6.1491

7. Feedback that explains, and wrong answers that teach

The research. Getting things wrong is useful when you find out why. The confidence research above depends on that: the correction is what gets remembered.

What we do. Every wrong option in every question has its own feedback saying why it is wrong. The wrong options are built from the mistakes pupils really make, and the feedback says what would and would not gain the mark in the exam.

Where our approach comes from: Scottish computing education

The research. The reference language used for code in National 5 and Higher exams was developed by Quintin Cutts (University of Glasgow), Greg Michaelson (Heriot-Watt University) and Richard Connor (University of Strathclyde), after SQA asked for one in 2010. It gives exam questions code that is exact, so that a pupil's job is to read it and explain what it does. Cutts and colleagues explained why it matters: they argued that a loose mix of code and English is a poor basis for questions about understanding programs. Quintin Cutts also led PLAN C, a Scottish Government-funded programme in which computing teachers across Scotland learned together through local groups led by teachers. Its evaluation reported that teachers grew in confidence and changed how they thought about learning. One of its approaches is tracing: marking up code to show what the computer is doing as it runs.

What we owe them. This site inherits that thinking. Code is shown in the reference language for reading and tracing, while pupils write their own code in Python. We are not connected with, or endorsed by, these researchers or the PLAN C project. We are simply grateful for the foundations they laid in Scotland.

Cutts, Q., Connor, R., Michaelson, G. and Donaldson, P. (2014). Code or (not code): separating formal and natural language in CS education. Proceedings of the 9th Workshop in Primary and Secondary Computing Education, 20-28. doi.org/10.1145/2670757.2670780
Cutts, Q., Robertson, J., Donaldson, P. and O'Donnell, L. (2017). An evaluation of a professional learning network for computer science teachers. Computer Science Education, 27(1), 30-53. doi.org/10.1080/08993408.2017.1315958