Notes on a failed lesson

At the very start of this session I used the idea of simple games to get to know my Higher Computing class and clearly define the importance of rules, structure and boundaries when problem solving. They had the option to play War, Shove Ha’penny or Penny Football and learn how to win (or at least how to avoid defeat). My class were well motivated by the opportunity to spend around 80 minutes exploring, in some cases, these >new< games! The intended outcome, relating to computer programming, seemed to be an easy step for them and I noted that the students, having spent the time playing those games, were able (in the main) to use them as a reference during the remainder of the unit. So far, so good.

In the next unit I returned to the games analogy when tackling the Fetch, Execute cycle (which relates to the internal workings of a computer processor). Instead of having the Higher Computing class play simple games which relate to the need for boundaries I gave the class the boundaries and rules involved and set them the task of coming up with their own paper-based game to reinforce the intricacies of the Fetch, Execute cycle. I asked the students to create rather than consume and hoped that the freedom I gave them to come up with their own ideas (in groups) would result in some interesting interpretations. It did, but not as I’d hoped.

I made a few big mistakes:

Firstly, the subject matter may have been a bad choice for this kind of task. Higher Computing exams tend to require regurgitation of the Fetch, Execute cycle steps – there is no scope for scenario-based problem solving here – so it’s all a bit too abstract really I suppose. In the past I’ve employed other kinaesthetic methods for teaching this – usually involving bouncy balls or whiteboard pens being passed around the class and ending up being aimed at a target (a clean metal bin is perfect for this and gives reassuring auditory feedback). Each student had a role to play in the transfer of data from one part of the room to another. A major drawback was (I felt) that they were consuming another game and perhaps not engaging with the subject matter as deeply as they could – hence the change this year.

Secondly, I hadn’t asked the class to create a paper-based game for me before. I hadn’t modelled it either. Really daft when you think about it actually and I’ve already identified a few opportunities to introduce paper-based game creation during the programming unit for next session.

The resulting game ideas (no group finished their game in the allotted 80 minutes, although they were all keen to continue creation for the rest of the week!) all had one thing in common. None of them related to the Fetch, Execute cycle at all! The students had concentrated on the game mechanisms before thinking about how they were going to reinforce the subject matter. After “letting go” and listening to (and attempting to guide them a little in)  their discussions I knew about 40 minutes in that they were going about it the wrong way however I held on to the hope that they would suddenly “get it” and produce the goods. You already know that this didn’t happen and I ended up looking at a deck of cards, monopoly board and snakes and ladders board. No group had any inkling how they were going to create a structure for their game.

The intended outcomes of the lesson were to be able to correctly sequence the Fetch, Execute read and write cycles and use the correct terminology when doing so. However by diverting the focus from the content to the means of delivery I undoubtedly failed the class that Monday morning.

So I spent the next two hours of non-contact time creating my own example game (which, in retrospect I should have done anyway!) that mimicked the process of the Fetch, Execute cycle and forced the players to use the terms and sequences to make progress. I tested the finished game out with some of the students later in the week and, although it had a few flaws, I feel they learned about the subject matter. This was what I really wanted from the class in the first place, but I also wanted them to engage more deeply by creating their own resources. I wanted them to create rather than consume. Next time I’ll remember that if I want students to change, they need help and mentoring to do so.