Today was my third day with students and I wanted to do some pair programming as a way to introduce and norm this process early in the year (apparently I wasn’t alone in this thinking). I’ve also been starting the days with different improv games as a way to break the ice (more on that at the bottom of this post). Today I decided to start with a game involving group counting – I’m not sure of its official name, but I’ll call it “First to 21” for now. The game begins with everyone sitting/standing in a circle and goes around counting up from 1 to 21. Eventually, rules are introduced – the first rule, as I’ve always played it, is that 7 & 14 are switched. This means the next time we count, it goes “1 2 3 4 5 6 14 8 9 10 11 12 13 7 15 16 …” etc.
Whenever the count finishes successfully, I made everyone yell “Boom goes the Dynamite” (this is one thing I settled on for my little thought experiment on Call and Response). Whoever was the last person to say a number then gets to make up another rule, which adds on to the previous rules. Some good ones from today were: swap 21 and 1; count down from 21 to 1; on every multiple of 5, say your name instead of the number; after every multiple of 4, the entire class says “Boom goes the dynamite”, etc. We played until the class had successfully completed a round with 5 rules – which, since they build on each other and can overlap, become very complicated. It’s a lot of fun.
This game is intense. Everyone (especially me) is on the edge of their seat watching each person and making sure they say the correct thing. And everyone individually is concentrating super hard to make sure they don’t mess up the rule. By the end of the final round, the chant of Boom Goes the Dynamite feels earned rather than just something I force everyone to say.
I didn’t realize it when I planned it, but this game was actually an amazing introduction to Pair Programming. Here’s why:
When playing this game, everyone either succeeds or fails together. There’s no way to win the game through pure individual effort – you need everyone else on your team to be involved and bought-in to be successful. I made this explicit with my class when I introduced pair programming: you either both succeed together or you both fail together as a team. Make sure you’re working together effectively.
Another really stellar aspect to this game is it’s really easy to track how mistakes are helpful and important in making sure you are eventually successful. When a student messes up – maybe they forgot to swap the 7 and 14 and said the wrong number – everyone groans, but now everyone is much more aware of that mistake and way less likely to repeat it again. Making the mistake literally makes the group better by raising the collective awareness of this particular troublesome spot. This is especially important in the later rounds, when there are multiple rules to keep track of (and knowing when they overlap); sometimes the group will get stuck at a particular point but, after failing two or three times, the group overcomes that particular spot and moves forward. I made a big deal about these moments in class, and I also stood firm on the commitment that would keep going until we succeeded with the 5 rules in play.
When I introduced the programming challenges for today (which were just some of the Hour of Code activities), I made this point explicitly: you will make mistakes, and that’s okay, because every mistake just means you’re getting closer and closer to getting it right. I told them there would be particularly tough spots that you weren’t sure how to get through, just like in the counting game, but trust that every mistake that’s made is always helping you move closer to success.
Lastly, I pointed out just how often people made mistakes in this game, and how easy it was to move on. Whenever someone messed up, we just started over and kept going – no over-analysis, no blaming, no lingering. We just helped clarify the rule and explained what should have happened, then moved on.
I also made this explicit when programming: you will make a mistake – they happen, it’s never perfect the first time – and that’s fine. Don’t linger; don’t blame; don’t over-analyze – figure out how to fix it for next time and move on.
So anyway – I made all these points after we had played the game with 5 rules and as I was introducing the concept of pair programming. As students set off to work on their Hour of Code challenges (which were really just there as an excuse to start pair programming), I kept coming back to the experiences in this game as a way to validate and build on the experiences students had while pair programming. It was easier to redirect students away from negative self-talk (“We’ll never get this one”, “It’s too hard”) and I got a lot less of the “Why can’t I just do this by myself?” questions. So yah – overall, an excellent third day of school activity.
As a sidenote, I’ve been using a few different improv games in my class thanks entirely to working with a group over the summer called Upperline – they run computer science summer camps out of New York and, unlike other summer gigs I’ve done, they have a pretty serious focus on professional development and pedagogy that goes along with their program. One of their focuses is on using Improv Games in the classroom and how these games connect to both the emotional and cultural aspects of the classroom. By design, these games lower tension between groups of strangers, help create a community of belonging, and normalize mistakes – all of which are pretty explicit goals at the start of the year in my Computer Science classroom. I’m only on day 3 and I already see these strategies paying big dividends.