CS161: One Woman's Adventure with a Flipped Classroom

For many years I have wanted to make my operating systems course, CS161, more interactive. I try very hard to engage students in the classroom, but let's be honest -- when they have been up all night trying to get their operating system to spawn processes, they just aren't really up to talking much in class. And when they do, it's the same set of characters and it's difficult to figure out if the rest of the class is really following along or is totally lost. At the same time, we know some typical student behavior that makes the course more difficult than it needs to be. Shockingly, even though we give students three weeks to complete assignments, they leave 99% of the work until the last week (day). That makes for a rather painful semester. Similarly, we ask them to write design documents, but many sit down to write them the night before without fully understanding what they are trying to do. And when we ask them to read the code and answer questions, they tend to gloss over most of the code and whip off quick answers.

I've always been tempted to try some newer classroom techniques, such as Peer Instruction and Flipped Classroom. I've just always been a bit afraid of balancing the potential for deriving greater benefit from class time versus dumping too much work on them.

So this year I took the plunge. I decided that I would flip the classroom for the first two to three weeks, return to a more conventional classroom while the students are deep in the most challenging programming assignments, but flip at key times, when I believe that there is real value to doing so.

I decided that I wanted to blog about this to record my observations, but also to invite students to chime in if they are so inclined. I also welcome comments from alums of the course or other others with concrete experience with related activities.

I am now one week into the semester, so we've done this for two classes. So far, I am wildly enthusiastic. It's scary, but it seems that we've already observed some tangible benefit (unfortunately, I do not have a good way to quantify/evaluate this).

Day 1

Historically I try to do a class-wide exercise where I draw the POSIX API or the programmer view at the top of a page and the reality of the hardware at the bottom and together we fill in what has to happen in between. My goal is to help students understand what the operating system must do and what they will be building over the course of the rest of the semester. As per many class exercises, a few students dominate such discussions.

So, this year I presented about 20 minutes of overview -- what the course was about, what I expected of them, what I promised in return, and then I turned them loose on three instances of the design problem (corresponding to the three main programming assignments). The TFs and I then wandered about the room, checking in, asking them questions, and helping out when necessary.

I quickly identified group(s) that were confused and were having difficult getting started. As other groups were happily making progress, and there were TFs talking with other groups, I was able to devote a significant and focused amount of time working with the groups that needed or wanted my attention. Instead of spreading attention around a class, dominated by the most confident and extroverted, I could provide focused attention where it could do the most good. Different groups addressed questions at different levels of detail, and that was OK. When I heard groups say things like, "You need page tables here," I stopped them and asked, "But what is a page table?" I wanted to force them to think through words they may have heard and make sure they really understood what had to happen.

After they worked for 30-40 minutes, I brought the class back together again and had groups present what they'd done, building upon each other, with my translating to some extent. I also assured them that we didn't expect them to complete this exercise perfectly -- after all, if they already knew how to do it, they'd have little use for the rest of the semester.

To me, it felt pretty good. The only tangible data I have is that a few students, who started off saying that they weren't really planning on taking the course because there were three other CS courses meeting at the same time, signed up. Pre-term planning number pegged the course at 37; we had about 60 students the first day; 47 registered. This is larger than the course has been in 15 years! And, it's important to realize that 15 years ago, there were no other undergraduate systems courses to speak of, so choices were significantly more limited.

Day 2

I took the material that I usually cover the first week and turned it into two videos (all the materials I'm talking about are linked from our syllabus here). For pre-class work, I had them do part of what we ask them to do for the first assignment -- get their work environment set up. Then, we spent class time letting them configure and build kernels for the first time. A few people ran into difficulty, and this was the beauty of doing it in class -- we could help them right then and there, making sure that they weren't stuck. So, within 10-15 minutes, every single student had configured and built a kernel. How great is that?

Next, we let them start answering code-reading questions (typically included as part of the first assignment as well), encouraging them to discuss the trickier ones amongst those at their table. Here is the thinking: most student spend little time actually reading the code, and when they do read it, if they are confused, there isn't much they can do except post a question (always a bit scary), email a TF, call a friend, beat their heads against the wall. However, by having them start in class, they had friends right there to work through the code with them. Some groups worked pretty independently, other groups worked completely together (two people in front of one terminal), others did a combination. Once again, the TFs and I circulated, answering questions, asking questions, encouraging discussion, etc.

They are each supposed to write up the answers to the questions to turn in, but they should have made significant progress on the assignment already.

On to week two!

Next: Flipped Again (February 7, 2013)