In many organizations that are leaders in their field, new inductees often report being awed when they start to comprehend how sophisticated the system is compared to what they’d assumed. Engineers joining Google, for example, seem to express that feeling about the company’s internal technical architecture. Princeton’s system for teaching large undergraduate CS classes has had precisely that effect on me.
I’m “teaching” COS 226 (Data Structures and Algorithms) together with Josh Hug this semester. I put that word in quotes because lecturing turns out to be a rather small, albeit highly visible part of the elaborate instructional system for these classes that’s been put in place and refined over many years. It involves nine different educational modes that students interact with and a six different types of instructional staff(!), each with a different set of roles. Let me break it down in terms of instructional staff responsibilities, which correspond roughly to learning modes.
Textbook and booksite. Bob Sedgewick and Kevin Wayne, the “creator gods” of this course, wrote the excellent textbook and created the accompanying “booksite,” a very effective online complement to the book. The course is usually taught by them.
Coursera. Bob did the online videos and Kevin helped develop the course, including the exercises; Josh is primarily administering it this semester. Enrollment is around 60,000! The online lectures are a vital part of the Princeton course because some of our lectures are “flipped.”
Slides (and course organization). Bob and Kevin again. Josh and I do tweak the slides quite a bit for our lectures, but I for one couldn’t possibly have developed this material (or even half of it) — it would have eaten up an entire semester. The organization is extremely well thought out. For example, we hit them with Union-Find in the very first lecture. If you’ve taken a data structures and algorithms class, you’ll appreciate how unusual that is. Having seen it this way, it seems obviously the right way to teach it.
Assignments and grading script. The assignments are highly effective, ensuring that students really understand how to design and analyze algorithms and translate them into code. But the real surprise to me was the grading script — while the actual grading is done by humans, the script pre-processes the submissions and finds almost all bugs, even design bugs. For example, it can (heuristically) tell if the student’s algorithm is cubic instead of quadratic by measuring running times on different inputs. It has evolved over more than a decade.
Lectures. In addition to the traditional goal of conveying information, we try to use the lectures to get the students to care about the course. There’s something irreplaceable about getting 300 people in a room excited about what they’re learning, letting them feel each other’s energy and generating social proof. This is very hard to achieve, but it’s worth a shot, and we’ve succeeded at times. For example, Josh said something so inspiring in his lecture this week that the students broke out into spontaneous applause.
Precepts. Decades of teaching research has established that passive transmission of information is just about the least effective learning method, and while we try to make the lectures as interactive as possible, there’s a limit. So precept is where a lot of learning happens.
We have so many precepts our preceptors have their own preceptor! Every week we have a meeting where Maia Ginsburg, the lead preceptor, presents a plan for the week’s precept, which we all then implement. Maia and Josh are at the heart of what makes this course tick on a daily basis. They are dedicated teaching faculty, and I really can’t imagine running a course like this without someone at the helm for whom it’s a primary responsibility. I would be completely useless at doing their jobs.
Online Q&A. There’s some member of the teaching staff (usually not me) “on call” at all times to answer student questions online on Piazza; the mean response time is a ridiculously impressive 10–15 minutes.
Lab. We hire students who’ve taken the course in previous semesters and done well to hang out in the labs and help current students with programming questions. Their role is indispensable.
Grading. For each assignment, Maia, with Josh’s help, develops a “grading rubric” that anticipates just about every possible error that students might make and defines how many points to deduct for each. This is another component that has gradually evolved with the course over the years; I was blown away by how much work goes into maintaining it.
Office hours. Finally a learning mode where there’s no particular innovation, as far as I can see.
Here’s a matrix that summarizes the division of labor. A filled square represents full responsibility and an empty square represents fewer hours devoted or implementing a rubric that’s already been developed.
Computer science education is at an inflection point — the new reality that we’re quickly approaching is that everyone in college needs a few basic computer science courses, regardless of major. Some CS departments are innovating and thriving in response to this challenge, while others are feeling crushed. Let’s have a conversation about what’s being tried, what’s working and what’s not, and how we can continue to scale.