CS100 Class Design

So I haven’t had much opportunity to post about my classes at Duke, but it has been very cool. I’ve found students at Duke to be very conscientious and smart, and my office hours have been very busy which is always fun. Of course there’s still plenty of the usual student foibles to contend with – but if students were virtuous and self-motivated all the time, I’d probably be out of a job.

This semester I’m co-instructing CS100 – a data structures course that occurs as the second course in a CS major but also accommodates a good number of non-majors. One of the perks of this job has been the opportunity to observe my co-instructor Owen Astrachan’s lectures. Owen definitely has one of the most refined lecture styles of anyone I’ve worked with – he’s got a whole repertoire of jokes, dances, and asides to keep students engaged. Not only do these little diversions keep interest in what can be a fairly lengthy 80 minute lecture, but I think it sets the tone of the course as much more relaxed and fun than what you get just looking at the webpage alone. I definitely have some work to do in getting myself to Owen’s level, lecture-wise.

But in my own lectures, I’ve been very self-conscious about designing each class myself. I take my cue from Owen on the content covered, but I have my own ideas about how to convey them best. My experience suggests that you’re much better off designing your own class and making your own mistakes. Standing up in front of the room holding some other professors notes (no matter how brilliant) is gonna guarantee a medicore class at best. If you design the lecture with a modicum of care yourself, even if it goes completely off the rails you’re likely to do better.

Of course, once you get out of that “off the rails” class, you might take a few hints from the experts and change your style appropriately.

But, after a semester of this, I think I’ve got a structure I’m happy with for this large lecture style class. Here’s how I do it:

  1. Prep work. Because most of the lectures I teach are officially considered 160-person, lecture-style ‘recitations’ I’ve been able to get away with requiring students to do a 1-hour-ish prep for each class (which I always collect and check for participation). This is just as awesome as you’d expect. Sometimes I use this as a review of topics covered elsewhere I don’t have time to do in class, sometimes I use it give students an example of the kind of problem we’ll be doing more of in class, and sometimes it’s an introductory problem that I’ll build off in class.
  2. As you sit down. I always give students something to do as they sit down and get ready for class, which I put on the powerpoint as they arrive. Students are somewhat blase about actually doing it (bad)…but I still like it insofar as it sets the expectation that you are already in your chairs and working the minute class begins.
  3. Running slides that convey the learning objectives. I know a lot of older professors scoff at the idea of learning objects that you spec-out in class, but I love ’em. Mostly, it focuses me when I’m planning the lecture to decide exactly what I want to cover, keeping in mind that if students learn more than 2-3 things in class it’s a miracle. But I also like making it explicit to the students what my plan is: we’re not just having a chat, if you have finished class and you don’t know 1 2 3 then at least you know what you ought to be looking up. My slides always look like “After class today you will be able to … 1 provide the definition of words a b c 2 code programming problems of type d 3 explain why the efficiency of e is f. Then at the appropriate points in the lecture I have sides that are like “At this point in the lecture you should 1 know the definitions of a b c *next up is* coding programming problems”.
  4. Active learning regularly. Wherever there’s a concept that’s important and they won’t grasp it immediately, I have some on-slide multiple choice. If I feel like it would be better served in some other way, I’m also willing to have a worksheet students fill out in class. But usually multiple choice with hands works. Only trouble – not every student participates in the in-class multiple choice, and it’s often hard to know when we are done and we can begin discussion. I’m considering clickers for next semester.
  5. In-class coding. For a class like this which coding is a large part of the final goal, I like to have at least 1 in class programming exercise that the students submit (Duke has a great system that makes submission very easy). For one thing, it breaks up the 60-minute-doldrums…I feel like I pretty much have to move out of the lecture mode and force students to work on a problem that takes at least 10 minutes without my direct intervention. For another, it clarifies how what we just talked about will relate to the actually nitty-gritty of their assignments tests and projects. The key difficulty here is difficulty…students are very willing to stare blankly at the screen, not asking for help for 10 minutes. I’ve had some luck with providing a range problems…implement 1 function where you only have to write 1 line in my pre-written code, another where you basically copy the first and change a couple things, and a third that’s a new variation.

So yeah, nothing fancy but it has been working well for me. If you’re curious in practice, here’s a video of my class on trees:


  1. Prep work (195.8 KiB)

  2. Slides for class (860.1 KiB)

  3. Code exercise for class (3.8 KiB)

Leave a Reply