Flipped Again (Week 2)

Last week I was full of euphoria; this week not so much. I'll cut to the chase before diving into details. First, teaching this way takes at least three times as much preparation as teaching "the regular way." I still think it's worth it, but I can tell that it's going to take its toll. Second, in a programming course, preparing pre-class work and in-class work is a detail-oriented process, and if it goes wrong, it can go badly wrong. Third, I am hoping that full transparency, honesty, and a lot of humility will help to mitigate the disasters that can happen as a result of the previous item.

Part One: Time Intensity

Regardless of how I teach, I try to prepare thoroughly. When I lecture traditionally, I hand out notes, so students have the outline of what we're covering, but I leave a lot of blank space that I try to fill in collaboratively with the class. However, I always have the main points jotted down on my notes, so I make sure to cover the things I want to cover. After class, when I discover errors or things that didn't go well, I either fix the notes then and there or leave myself notes for next time. In either case, my notes and lectures are constantly evolving and changing.

So, how does that kind of preparation translate into my current situation? First, taking last year's notes, updating them, and then preparing the audio track requires at least a factor of two more time, perhaps even more now that I'm thinking deeply about it. Applying the same fixes I would have applied were I teaching conventionally takes about the same amount of time it would have. But then I start recording audio tracks. In my case, I'm using discrete audio files per slide, attaching them to the powerpoint, and then converting that powerpoint deck to a movie. The logistics of all this are tedious and take time, but that's not interesting (e.g., the PPTX->movie conversion really only works well using software that runs only on Windows; it produces enormous files, which I then translate using a different tool; these large files get moved around, etc).

The more interesting is what goes into preparing the audio bits. Since students will be listening to these on their own, they don't have the opportunity to interrupt and ask clarifying questions. We do have an interactive message board, and the students are taking good advantage of it, and the TFs and I are working hard to be responsive, but it's not the same as saying, "Excuse me, I didn't understand that." OK, few students ever actually say that in class, but when you can see them, you can frequently figure out that they are thinking that. In lieu of that, I think very carefully about what I want to say, how I want to say it, and then I record. I'd say right now about one in three times I am happy with my first take. One in three times I need a second take. One in three times I do many, many takes. So far, the videos have mostly come in around 30 minutes, so we're talking a couple of hours when you add in recording with incorporating the audio track, setting options, fixing things, etc.

But once I've completed the audio track, then I can really begin. Next I think about what I want them to take away from the video and I translate that into pre-class work. I think I am posing somewhat more challenging pre-class questions than one normally associates with this task, because I use those results to help me identify what issues are really confusing people. (I spend an hour or two in the morning before lecture reviewing answers, analyzing responses to the various questions, discussing them with my staff, and figuring out whether I want to a) simply post answers, b) go over problems in class, or c) do nothing.) In any case, I spend somewhere between 30 and 60 minutes thinking about and writing pre-class work.

Then I begin working on the in-class component. In our case, this involves writing code. Writing code always (always, always) takes longer than you expect. Testing is key. However, since my pedagogical thinking evolves as I am working through the assignment, sometimes I don't always use the practices. This brings me to item two on today's list.

When Disaster Happens

We had no fewer than four different types of disasters happen all in the span of a single 90 minute class (of which 30 minutes was consumed discussing pre-class work). There are many things to learn from this experience, so I'll walk you through what happened in potentially gory detail.

1. Pre-class work

It turns out that unless students were clairvoyant and could read my mind, there was much ambiguity in the questions as I wrote them. Both TF feedback and the analyzed data supported that claim. So I took the first 30 minutes of class to go through the questions and discuss the different interpretations and how those interpretations led to different answers. My assessment is that while it didn't feel good to be me, the end result was actually pedagogically constructive. We ended up talking about a number of important concepts and assumptions as a group, and I think we raised issues that, in past years, never surface, are never addressed, and manifest in difficult-to-debug code later in the semester. It will be difficult to do any kind of hard empirical analysis of this (although if people have ideas, I'm all ears), but my sense is that we had a deeper discussion about synchronization than typically happens.

2. Preparing for in-class work

After that, we turned to the class work. I had prepared the exercises as a separate branch, with the intention that they could play with it in class, and it would not in any way interfere with their own work, and afterwards they could either keep it or toss it without any effect. Great idea in theory. In practice, due to a combination of miscommunication, my own experience with the particular source code control system we're using (there were good reasons to change, but it's not one I've used extensively), and pretesting the process on a tree that was not identical to what the student's had, we ended up having them execute a command that, well, um, kind of messed up their tree.

3. Dealing with the in-class disaster, or "Another Disaster in the Making"

When then insued was sheer insanity. Over the course of the next 15 minutes, we frantically proposed multiple different ways of fixing people's trees. The TFs, students, everyone had an opinion, and we kept posting them. This was just dumb. We should have stayed calm, figured it out, and then dealt with it. But no, we freaked out -- all of us!

Finally, I went around the room and checked on every person to make sure that they had a working tree. That seemed like a good idea. Hoewver, then the fun really began.

4. The Crowning Touch

As they started working on the problems, they discovered truly, horrifically idiotic bugs in the code. How did that happen? I really tested things. I really did. Honest.

Ah yes, I'd done a couple of those last minute, "Hey -- this will make things easier to debug!" fixes and of course did not rerun the tests. That will teach me. Class ended with me feeling like I'd wasted a lot of truly valuable time and the students probably wondering what on earth they'd signed up for.

Transparency

So what do you do after a class like that? Well, I tried really hard to do better on Thursday. Although I did forget to have people put their names on the pre-class work, I didn't make any monumental errors. I did however, address the situation head one. This is what appeared at the beginning of Thursday's work:

First, let me start out with an apology -- we did not use your time efficiently on Tuesday, and that's a violation of the "contract" I made. I hope you all believe it certainly wasn't my intention, but that doesn't excuse it. I must, and will, do better. There are a number of ways in which things went badly, and rather than focusing on what they all were, I'd like to focus on how to avoid them. Thanks to Carl, we have a nice simple mechanism in place to help us prevent git shenanigans. Please refer to the Piazza posting. All that said, one takeaway is that at some point in the semester, if you find yourself in the midst of a git disaster (e.g., you and your partner cannot figure out how to resolve conflicts, get each other's changes in exactly the place and way you want them, etc), don't panic. There are ways out. Stay calm, learn to read git commit logs so you can figure out where things have gone astray and patiently try to fix them (we did not demonstrate the "patiently" part yesterday -- we frantically tried N fixes in a course of N-1 minutes trying to muscle through it; not a good strategy). So, as promised, today's exercise is simply to finish what we started Tuesday, ideally with significantly less drama!

I also tried to use the experience as a teaching moment, even if it was at my expense, so I also wrote:

There was another bone-headed error that got in here -- I will explain how this happened, just as a warning about "last minute changes." I had completed the problem, implemented a solution, tested it, and was happy. I then removed the synchronization to commit. "But wait!", I thought, "It's too difficult to debug, because there was no way to determine which TF is handling which student's question. The printout simply isn't helpful enough. I'll add a tf array so I can print out a TF number and that will be easier to debug." So I tossed it in the TF array at the last minute, and (here's the boneheaded part) did not rerun all my tests. So, take this as, "Don't do that!" No matter how minor the change you think you're making is, you have to rerun your tests. Especially if you're tired, that "simple" fix is undoubtedly wrong in at least three ways. Mea culpa. This was the second patch (semprob2.patch ) sent via email. Apply that patch too.

The Conclusion

So after all that, how did Thursday go? Remarkably well. The students seemed to accept my direct apology and commitment to do better. Perhaps some of them will chime in on their perspective (perhaps not; the one who are really upset will wait until the semester is over, and I understand that). And, by the end of class, all the students were animatedly and happily chatting about whale-mating. It was good to hear!

Next: Not Flipping Out (February 16, 2013)