Weeks 4 & 5: Joy

You can tell that I'm struggling more keeping up with this class than with CS161, when I flipped that -- I have not been able to blog regularly, because I spend pretty much every waking moment working on the course (or frantically doing the other administrivia required of faculty and every once in awhile I get to talk to my students and pretend to do research and file NSF reports). You might be tempted to assume that it's the scale of the course that is making this more difficult, but it turns out that that is not the case. This course is taking so much more time, because it's a course I've never taught before When I flipped CS161, I'd taught the course many, many times over the past 20 years; I knew the material; I knew what was difficult; I had lecture notes. In that case, my efforts in flipping turned into recording audio tracks for slides that already existed and designing in-class exercises. In contrast, this year, I'm developing the notes from which to record the pre-class videos and the in-class exercises and the pre- and post-class surveys. Thankfully, I am not preparing new problem sets, because I have inherited a terrific collection of problem sets from previous years. (We're designing one new assignment.) Also, I am extraordinarily grateful to the folks who've taught the course before me -- from one I have an amazing collection of slides -- while I don't copy them, they provide an excellent source of inspiration and data from which to design my own. From the other, I have inherited a huge array of programs that can be turned into the right in-class exercises. Without these two sources, I do not think I could do this in real time -- that is, I could not keep up with the pace of the class. I think this is a HUGE point, so I want to summarize the different ways one might be tempted to flip a class:

• Flip a class that you've already been teaching: This is definitely doable and rewarding. You probably already know the patter that you have with every slide in your slide deck and recording will take time, but it won't panic you. You will learn just how sloppy you can become while lecturing and will spend time trying to become more precise in your patter. You may also spend time breaking long lectures down into smaller, bite-sized topics. And you will also spend a lot of time developing in-class exercises. For programming courses, this requires both intellectual investment as well as programming, debugging, clarifying, etc.
• Flip a class that you've not taught but for which you can inherit a lot of material: This is also doable and rewarding, but requires an enormous amount of effort. I suppose that if you are comfortable lecturing off someone else's slides (or in this case preparing videos off of someone else's slides), then you can reduce the work. But, it takes a lot of time to figure out exactly what exercises in class connect the videos to the problem sets.
• Designing a new class from scratch: I personally could not do this in real time. That is, I would need at least half the course completely done before the semester started. Your mileage may vary, but I find it intellectually challenging (albeit rewarding) to coherently design videos, pre-class surveys, in-class activities, and problem sets. Coherence is really the key. If the in-class exercises do not connect (especially to the problem sets), students quickly become frustrated and lose interest.

Lest you think this experience has turned me off flipping, that's definitely not the case. I still love it and remain convinced that it's the more effective way to teach certain subjects (programming and systems for sure). I've gone into numerous reasons before, but perhaps the most compelling one is the one I just noticed last week: the joy that I see in my students when they are working in class. They are actually happy! They are having fun. When one lectures (at least when I lecture), there may be a few students who look at least mildly interested, but there aren't a lot who look genuinely happy. As I and the staff wander about the room, talking with students, answering questions, pushing them to dig in, everyone, both students and staff, look genuinely happy!

I come away from class both invigorated and exhausted -- it's hard work. You want every student to have a positive experience, and you have a real way of observing very directly if they are. When things go wrong, it's rough. We had one unfortunate incident this week where I didn't fully think through the ramifications of exactly how I had asked students to do an exercise. The end result was that their Makefiles were spitting out errors that confused them. The fact that the Makefile errors were irrelevant; they were distracting to the learning we wanted to happen. Little things matter, and making everything that is not directly relevant to the learning, is a detraction (except candy). It's important to remember that and make every experience as seamless as possible. The only silver lining is that since the college students finish several hours before the extension students have their web conferences, we can fix things for extension. That's critical as the technology and distance pose a sufficient hurdle that technical difficulties with something as mundane as a Makefile would be a real demoralizer. So, what' coming up next? Assignment 3 (adding a cache to a simple, unbuffered standard IO library) is due and then we have a midterm! That's always stress inducing on the students -- but it's also a good indicator for us about whether we are successfully teaching the students what we think they should be learning! Until next time.