Anatomy of a successful class

On Monday, I had what I would specify as one of my best teaching moments ever.  I’ve certainly had my share of good moments and horrendous moments, but this class was truly special.  I didn’t do anything particularly revolutionary or ground-breaking—rather, it was just a “perfect storm”, in a sense—so I wanted to outline not just what I did, but why I think it worked so well.

The inspiration for the class actually came from my boredom with lecturing.  I try to mix up my classes—some lecture, some group work, some discovery-type work—in all my classes, but particularly with this class, because the material is very practical and hands-on.  I’d hit a patch, though, where I found myself lecturing more than I liked.  So I already knew that I wanted to present the material in a non-lecture format.  The trick was finding a good way to do this and to still get the important conceptual points across.

Which led to inspiration #2:  I’d just gotten back from Grace Hopper, and one of the sessions I attended there talked a bit about successfully using team-based learning/problem solving in the intro-level CS courses.  So I’d already been thinking about identifying “good” in-class problems in a more general sense.  It was just a matter of tuning my thoughts to this particular class and this particular topic (the design of peer-to-peer networks).

I came up with the framework for the class first:  divide into groups of 4-5 (which ended up being 5-6), hand out the problem, have them work through the problem, and present their results at the end of class.  I now needed a good problem:  something that was non-trivial but accessible within a single 70-minute period; something that would be relevant and interesting to the students, but still compact enough so that it would showcase the conceptual points I wanted to highlight.

Problem inspiration comes in strange places sometimes, and mine came the next morning, when I was wrestling with Moodle.  Ding!  We were going to pretend that Moodle went down and that I was instead going to distribute the rest of the course documents via a peer-to-peer network that the class would design.  The students have more of a love-hate relationship (mostly hate) with Moodle than I do, so this was both an easy sell and a plausible problem.

I wrote up the scenario, and then came up with some directed questions to help narrow down the problem into something manageable.  Essentially, the students were responsible for figuring out how to distribute content throughout the network and how peers would search for content.  The handout also indicated that they would have to present their design to the rest of the class.

Classtime came, and the students dug right in.  Right away, I could see that the problem was almost perfect, because the students started discussing the issues right away and never deviated from the task—which is highly unusual in my classes, which seem to attract the group-work skeptics.  My plan, as I wandered around the room, was to listen in on the discussions, clarify points, and ask key questions to keep them on track.  That was the plan.  But I only ended up doing the wandering, because the discussions were completely self-supporting and driven.  They were clarifying their own points, asking each other key questions, coming up with and discarding design ideas.  They were also digging much deeper into the problem, considering key but unstated issues such as “what happens when someone new joins?  what happens when someone leaves?  should we have a central point of control?  should the content be digitally signed?  should membership be restricted?”  In other words, basically all the important design issues and problems were coming out in the discussion, and the students were engaging with them in thoughtful ways.

I had been purposefully vague in terms of how they were to present their designs, so halfway through the class I revealed the format of the presentations:  they were to act out an example scenario (which I scripted out on the board), using the members of their group as nodes of the network.  I fully expected the eye rolls to come out at this point, but instead, the students dug right back into the discussion in earnest.

I had heard snippets of the design decisions, but had no idea what each group had come up with finally, until I said “Time’s up!” and started the presentations.  After each of the three groups presented, I asked them to summarize their 3 main design criteria, and wrote these on the board.  The result was truly amazing:  There are essentially three different models for peer-to-peer networks (centralized, completely decentralized, and hybrid)—and each group came up with one of these designs, independently.  Better still, the combination of the presentations and the identification of key design principles covered everything that I would have covered in a lecture.  And, the students asked just the right clarifying points of each other—I didn’t ask a single question other that “what were your 3 key design principles?”  I was floored—never has one of my activities been this much of a complete success.  And I made sure to mention this to the class—and judging from the students’ expressions, I think they also understood what fabulous work they had done as a class that day, and just what a great class it had been.

So what worked?  I think it was the combination of willing class + properly-targeted scenario + properly-targeted discussion questions + appropriate scope.  That, and I think the personalities in the class were distributed evenly among the groups (which I did completely randomly, by shirt color), such that everyone felt comfortable contributing to the group discussions.  In a sense, it was the perfect storm—but unlike the perfect storm, I feel pretty confident that this experience is something I can re-create in the future.