Why the lessons are structured this way

The lesson design is informed by computing-education research and teaching guidance, with a student pilot still needed to evaluate this particular course.

We start with code students can read and change before asking them to write a program from scratch. Sentance, Waite, and Kallia’s PRIMM study (2019) used prediction, execution, investigation, modification, and creation in secondary classrooms. Its students performed better on the post-test than the comparison group. That gives us a reason to use this sequence, although the study did not test an independent FRC course. PRIMM study.

Worked examples also need to explain what each step is trying to accomplish. Margulieux, Morrison, and Decker (2020) studied examples with named subgoals and found improvements on early assessments and failure/withdrawal outcomes, though not on average exam scores. In our lessons, this means explaining steps such as reading an input and choosing an output before combining them in a larger program. Subgoal study.

The repeated intake example lets us return to earlier ideas while adding new ones. The IES practice guide recommends returning to material over time, alternating examples with problems, and asking students to explain their reasoning; the strength of evidence varies across its recommendations. Our end-of-lesson checks ask students to recall an idea and use it with a different input. IES teaching guide.

The Raspberry Pi Foundation’s guidance also emphasizes reading code, familiar contexts, and discussion. Students working together can compare predictions and trace a surprising result, while the written lessons provide enough explanation and expected results to work through independently. Computing pedagogy.

We’ll need to see how new students use these pages to find out where the explanations fall short. Record what they could do with a new problem, as well as which steps they could follow in the example.