When I shout “Sabotage!” in my classroom, it is not because a staffroom rival has been messing about with my interactive whiteboard. Instead, it is to begin a game I devised to teach my information communications technology students how to debug their own programming.
When I first switched from teaching Scratch (a visual programming language) to teaching Python (a text-based programming language), I found that students quickly became frustrated by the high number of syntax errors that prevented their scripts from working. This created negative associations with text-based programming, as there was a much higher failure rate than with Scratch.
Many children were derailed at the first hurdle, and resorted to either giving up completely or raising their hand and waiting for me to attend to them like a repair man. But helping them was counterproductive: others realised that if they got stuck, they could also put their hands up and wait for roadside assistance to arrive.
This behaviour spread around the classroom, and soon I was faced with a crop of raised hands. I knew that this situation was unsustainable, and it was down to me to change it.
First, I tried getting the students to fix the issues themselves. However, this did not encourage them to solve their problems independently and, in some cases, it made them all the more exasperated. Thankfully, at last I had a light-bulb moment: the game of Sabotage. It works like this:
Each student starts with a script for a game, and we test the game to make sure that it works.
I ask every child in the class to think of examples of syntax errors that might prevent the game from working properly. With a partner, they share as many of these as they can in one minute. Then they form groups of four to see if they can find any more examples.
I compile a list of generic examples by asking each group to suggest one typical error.
I explain to the class that they are going to deliberately sabotage their partner’s working code by hiding five errors in there - no more, no less. I suggest that one error should be pretty obvious and one should be very sneaky: using the character 0 instead of the letter O, for example.
Working in their pairs, one student sabotages the code. That student then has to give hints and clues to help their partner debug the errors that have been introduced. Then the students swap roles.
We end the game with discussion. Which students managed to debug all five errors? Who introduced the most sneaky errors? What were they? Who gets the prize for being the most helpful? Who gets the prize for being the most devious?
Not only does the game of Sabotage help students to spot errors in their own code but it also encourages them to turn to their peers for assistance more often. Their enjoyment and engagement is clear as they slyly hide errors in the code and rejoice as they discover the traps that their partner has planted.
