I do this activity pretty early in the course, and have been doing it for years. First, I make sure students have some exposure to binary numbers, then I bring out combination locks and make sure they know how to open them. Here’s how it was described one of the first times I tried it.
On Friday, we broke up into teams and did an exercise with combination locks. Each team got a piece of paper with their lock combination written on it. The goal was to be the first to open your lock. Well, our team got a lock with base ten numbers on it, so we finished pretty fast and got first place. After we finished, a lot of other people were still working, so our team was really confused on why it was so hard for everyone else. Well, turns out, not everyone has their numbers written in base ten: some had binary, some had Chinese numbers, and some had numbers that weren’t possible (i.e. 41). This was pretty meaningful because it showed that not everyone starts at the same level, so some people have harder times than others. In computer programming, this is very true, because by looking at a person, you don’t know if they have ever done programming before, and they might not be at the same place as you, so you should give everybody a chance. I can relate to this experience because I am almost completely new to programming, and I don’t really like it when other people brag about knowing so many things. (Middle School Female Student)
So, to prep, I rip off the combinations and I copy them down onto some folded piece of paper. I either (1) leave them as their original decimal numbers, (2) convert them to binary, or (3) use some foreign language like Chinese. The idea for this was inspired by teacher training I did when I first started grad school, where they were trying to show how people have certain disadvantages (and having us do a broken scavenger hunt).
It’s so open ended that even I learned from this activity.
One team, for example, peeked at their combination before everyone else, which was fine, because it’s worth knowing that sometimes people win when they cheat. The difficulty of the challenge was determined by the format of the combinations, without considering the accessibility of the combination locks themselves. Sometimes there’s no easy advantage to make up for an uneven playing field. It has only happened once that a person couldn’t finish the challenge, because they didn’t know how to use a lock or how to ask for help. This was a minority student that I made sure, to the best of my knowledge, would have the unfair advantage. To have an advantage and still underperform showed that there isn’t always straightforward solution for inequality.
I’ve taught students from all over the world, from the underrepresented, low-income, first generation to go to college, to the most privileged. So, what I want them to know is that everyone has a story to tell. and for those who have an easier time doing it, I teach them to consider the stories of those who don’t.
Otherwise, you could be the winner, and think that everyone else was in the same situation as you. You could be the loser, and think it’s your fault that you weren’t more like everyone else. When I learned how to program, I wasn’t just making sense of the world around me. I was making sense of myself and why I wasn’t like everyone else.
Other lessons for discussion from this activity:
- Game Design: Ludus, Paida, Narrative
- Binary to Decimal conversion
- Social inequality
- Being a good citizen in the classroom
- Knowing how to ask for help