Why I teach cryptography

I teach a unit in cryptography in my 6th grade computer science course. It’s not an obvious addition to my curriculum, and it’s not one I’ve seen listed in many other CS classes at this level. Here’s why I think it’s important.

Cryptography requires students to practice complex problem solving. Students try different approaches until they find one that works. What works with one problem might not work for another. This is the opposite from problems students usually receive, in which they apply the same methods they’ve learned. It also requires students to research, and to stay with a problem even when it’s frustrating. These are skills that are necessary for higher math and for computer science, but they are very difficult to get to in a classroom. Cryptography presents a way to practice these skills in a game-like format.

Cryptography also encourages students to think about privacy and security in very practical ways. It can lead to really great discussions, particularly since issues around cryptography are very much in the news.

Cryptography allows me to sneak in some other topics the kids may not have been exposed to. Prime numbers, probability, and frequency analysis are easy to talk about in this context. There are also numerous examples of failed cryptography that allow me to delve into history and technology.

The big reason for teaching cryptography, though, is that I really enjoy the topic myself. This gives me the energy to make a lot of practical challenges for class. The kids pick up on my enthusiasm, and really focus on the class. And they love the challenges.

Here’s my latest challenge:

Breakout Winter 2018


Open-ended Programming

Inspired by a conference I attended this summer, I decided to try something different with coding for my 6th graders this year. Rather than teach a traditional lesson with exercises, I gave the students an open-ended challenge. Each student or team had to create an original game in Scratch. I gave no further guidance, although I was available to help with specific coding questions. The games would be presented to the class at the end of the unit, and students were encouraged to comment (constructively) on others’ efforts.

I was more than a little nervous about this approach. I had much less time with this unit – only 30 minutes once a week, over the course of about eight weeks. The students had already been introduced to Scratch and seen some demos, but only a few had actually programmed anything themselves. This had the potential to be a colossal waste of time!

Last week was the presentation. Not everyone in the class had produced a game ready to show, and of those games that were ready, only a handful were finished. That said, there were a couple really good games. More importantly, everyone in the class had produced some good code, and had struggled and learned along the way.

I had the students complete a reflection at the end, to see what they thought of the experience and what they had learned. The comments were much more positive than I expected (in fact, I’d hoped for some more criticisms, to help shape changes in the future). Here are some of the more insightful comments:

I got a lot more experience learning how to program. I think it would be fun to make something more in the future and this practice will be very helpful for that. I also learned that there are a lot of challenges making a game- you cant just make it in one day with no problems.
Troubleshooting! When I tried to add things to my scratch game or change some coding, I could make the entire this spiral out of control. this was pretty tricky, and it was sometimes hard to get the sprites or the backdrops to do what I wanted them to do.
I learned about troubleshooting when a code wasn’t working and about how to think out what you wanted your sprite to do.
 I will definitely make some changes with this approach in the future. First, the time I had to work with this year was not terribly conducive to success. The students could have used a longer block of time, without the Winter break right in the middle. I’d also like more collaboration and feedback early in the process. Some of the students really knew what they were doing, and could have helped the others along. A couple more demos of some basic mechanics (like motion using the keyboard or mouse) might help many of the students progress faster to other aspects of the game. And I would like to structure the reflection questions to get more useful feedback. I got a lot of very short answers with the current questions.
Overall I think the open-ended approach produced a much better result than lecture and practice. The students really seemed to enjoy the freedom, and I saw a lot of creative thinking and troubleshooting. While I’ll certainly do some tweaking, this approach is going to become my standard for a while.