DAVID MALAN: Hello. My name is David Malan, and I teach CS50 at Harvard, which is our introductory course in computer science for majors and nonmajors taught primarily in C and Python. Back in spring of 2020, Harvard, like a lot of universities, sent everyone home midsemester with classes, thereafter, online, and it soon became clear that fall of 2020 would be online as well. 

Now, CS50 itself has long been available online via Harvard extension school and, more recently, via edX as well. So we initially considered simply reusing the videos that we had filmed live in fall of 2019 since I didn't think I could do nearly as good a job from home via Zoom. But we realized that there might be a silver lining of that particular moment in time. With everyone off campus, there was an unprecedented availability of space on campus, in particular the university's Drama Center, home to the American Repertory Theater, was vacant, its team of artisans idled as well with no shows scheduled any time soon. 

And so we reached out to see if we might be able to teach the course live on its stage with students present only via Zoom and with just a few staff present in person. Amazingly, after quite a few emails and Zoom meetings, the answer came back as a yes, albeit subject to rigorous protocols. Only one person while teaching on camera could be unmasked at a time with everyone else wearing face masks and face shields separated from each other by 15 or more feet. 

Now, I should mention that, in healthier times, CS50 is already taught in a theater, a beautiful one at that, but what that theater doesn't have is a wide-open schedule, an entire prop shop in back, and experts in lighting and set design. All things considered, then, fall of 2020 offered an amazing opportunity for our computer science class to collaborate with a whole team of artisans to bring computer science to life with all the more theatricality than is ordinarily possible. Our pedagogical goal, ultimately, was to create all the more memorable moments for students particularly in those earliest days of COVID-19 with everyone online in front of a computer all day to help students visualize, understand, and remember concepts more than a lecturer's words alone might allow. 

That said, nearly all of the demonstrations that we did that semester on stage were really just higher-end equivalents of ones that we have long done more modestly in person in healthier times in classrooms large and small. Indeed, most everything you're about to see can also be done with some chalk paper and tape alone, but we thought we'd share with this talk just some of what we did that particular term and why we did it with even more in the paper. All of these slides can be found at cs50.ly/sigcse23. 

And allow me to emphasize that we only claim to have enacted these particular moments. Each was undoubtedly originated or inspired by my own teachers professors and colleagues over time. Here, then, is the theater in question. Here are those same seats filled virtually via Zoom with as many as 300 students at once visible across six very large screens. 

And here, closer up, is what I would see when interacting with students. What students saw, meanwhile, looked a little something like this, and it was on this stage that we brought one of our first demonstrations to life. Funny enough, the demonstration that students anecdotally mentioned as the most memorable over the years doesn't require a stage at all just a phone book, which, admittedly, is perhaps just as hard to come by these days. 

But it's a physical analog of the context that students of course now have in their phones, so the idea of searching for someone is no less familiar. Indeed, we use this prop to introduce students to algorithms. We start by asking how we might find someone, say, David in this here phonebook if it's sorted alphabetically by first name. 

And I propose to start looking from the beginning, one page at a time. After a few such page turns, I ask students whether the algorithm is correct. Invariably, a few students say yes, but a few also say no, conflating correctness with efficiency. So I then define both and then propose that we try to do better. 

I then start to flip two pages at a time, 2, 4, 6, 8, noting that it surely sounds and is faster, but is it correct? A student usually recognizes that I might accidentally skip over the person that I'm looking for, so I acknowledge that I might need to double back a bit if I've gone too far. It's still twice as fast, give or take a page, but can we do even better? 

I then propose to start in the middle. Looking down, I notice that I'm in the M section, so what do I do now? Well, David, which starts with a D, is surely to the left, so I can now figuratively and literally tear the problem in half, theatrically so, throwing half of the problem away. And I can repeat, repeat, repeat until I'm left with just one page. 

And to be fair, no more phone book, but we then talk about how we might analyze the algorithms, the first two linear and the third logarithmic in running time. And we then translate the demo to pseudocode, at which point we introduce vocabulary, like functions, conditionals, boolean expressions, loops, and more. 

A few weeks later, we revisit algorithms but in the context of arrays specifically. For this moment in time, I've long used sheets of paper taped to the board with numbers written in chalk behind each to represent some arrays, that the sheets are covering the numbers is deliberate. Neither we nor a computer can see all of the numbers at once. We must index into it to see one at a time. Sometimes we've used small gym lockers instead to make even clear that the numbers are effectively behind closed doors. 

But in fall of 2020, the theater had a whole warehouse of props used in past shows, and so we brought those doors to life size with an eclectic array of seven actual doors on stage. Behind each was a number, brought to life by the theater's prop shop, some with fur, some even with googly eyes. I then used these doors to search for a particular number, once with the numbers unordered and, again, with the numbers then ordered after which we named my two approaches-- linear and binary search respectively. We then transitioned to a discussion of asymptotic running time, including big O and omega. 

Now, in healthier times, we would have two students volunteer to do the searches instead, though we've found that it helps our own pedagogical narrative to guide the students toward one algorithm than the other rather than simply invite them to find some number without any guidance. Otherwise, the first student invariably hesitates, thinking there's some trick to finding the number when there isn't, and then they start opening doors randomly, much like a game show, rather than linearly. 

And worse, they sometimes find the number in question behind their very first choice of doors, which, of course, is hilarious and met with applause from their classmates. But it's not exactly ideal for a discussion of upper bounds, though great for lower. So the specific narrative for this moment rather depends on just how much the instructor leaves to chance. 

The next week we focus for some time on how to swap two values in memory as might be necessary when sorting the last week's array so that you can, in fact, use binary search. We take out two glasses of water, each a different color thanks to some food coloring, and we ask a volunteer-- or, in fall of 2020, a colleague in another room via video conference-- to swap the two values. 

Invariably, the volunteer hesitates, at which point I dramatically offer up a temporary variable in the form of a third glass, although one year, students simply swapped the positions of the two glasses and thought we were done. And then we enact swapping the two liquids using the third variable. We then transitioned to issues of scope and the implications of passing by value or reference. We consider code, like this here, which, similarly, swaps two values A and B perfectly fine but fails to swap the callers, copies thereof. So at that point, we introduce pointers. 

Now, I should mention that, a few years ago, I thought it'd be clever to demonstrate XOR swapping as well whereby you can swap two values using bitwise XOR operations without a temporary variable. And so I used water and oil for that demo, thinking cleverly that the two wouldn't mix and so I could get away with just two glasses. It turns out that's easier said than done in practice and yielded a memorable moment that just didn't work very well. 

We continue our discussion of memory, though, that same week, representing pointers metaphorically as mailboxes. And one mailbox is an address, like 0x123, and at that address is 50, an int. At this point, I tend to put on an oversized foam finger akin to what you'd see in stadium to make clear that one value effectively points to the other. Admittedly better than standalone mailboxes might be a whole wall of apartment mailboxes akin to an array, but the standalone mailboxes are much easier to transport and use in traditional classrooms as well. 

Toward the end of our semester, we also introduce students to a bit of SQL and, eventually, concepts like race conditions. We suppose that there are some popular posts on a social media site that lots of users are liking at once, and we suppose that the site is using two SQL statements to keep track of those likes, one to select the current number of likes and one to update that number by one. 

We ask students what might happen if those two statements aren't executed atomically for each user's like, together at once without interruption, by some other user's like. We answer that we might miscount the likes, but why? Well, we walk over to an actual refrigerator on stage, or a plastic miniature thereof. And we suppose that two roommates have the same in their dorm room, and both of them really like milk. 

One roommate comes home one day, opens the fridge, and they discover they're out of milk. So they head to the store. Meanwhile, the other roommate comes home, opens the fridge, discovers the same, and heads to another store without crossing paths with the other. Eventually, both of them return home only to realize that both of them have bought milk. But they don't really like milk that much, so some of it will now go to waste. 

So how do we avoid that problem? Now, at least one student usually suggests that we leave a note on the fridge, which would, indeed, suffice, but we take the opportunity more dramatically to lock the fridge all together. We explain that the solution for likes in a database is also a lock or lower-level transaction, and we emphasize that both problems arose because we inspected the state of some variable while it was being updated and made a decision based on that state. 

Those then are just a few of the memorable moments that we present in the paper. We discuss others as well. We use a black box to explain functions with inputs and outputs. We rearrange plastic numbers to explain sorting, using one shelf for selection sort and bubble sort but multiple shelves and, thus, more space for merge sort. 

We create a pyramid of cardboard bricks to explain recursion whereby a pyramid of height n is but a pyramid of height n minus 1 plus an additional layer of bricks. We draw on a grid of tiles to explain memory, each representing some number of bytes. We allocate wooden blocks to build a linked list of nodes, though I should mention that of all the demonstrations we did that term, this one I actually regret. 

When the prop shop asked, how large I'd like the blocks to be? I proposed three feet. Well, it turns out that three foot nodes made out of wood are much, much, much heavier than I thought, a testament perhaps to how difficult it is to manage memory. 

We hash oversized playing cards into actual buckets to explain hashing and hash tables. We enact callback functions by phone whereby I ask a colleague a question, and he calls me back with the answer. And we use light bulbs to explain binary, each week encoding an Easter egg in the theater's own stage lights using unicode. 

Ultimately, our use of so many physical props in fall of 2020 was well received by students with 65% of students reporting that they loved, use thereof, and 27% reporting that they liked. We asked students more specifically, though, just how helpful they found each demonstration, and atop the list, funny enough, was arguably the simplest of them, tearing a phonebook to explain binary search. 

At the bottom of the list, meanwhile, was the black box to explain functions. Here along the vertical axis is each demonstration, and each horizontal bar depicts just how helpful students found each demonstration. From left to right, blue is very helpful, red is somewhat helpful, and then neutral, somewhat unhelpful, very unhelpful, and unsure. 

So a long blue bar means that many students found a demo very helpful, and a shorter blue bar means that fewer students found a demo very helpful. We explore in the paper why we think that might be for some demos. For instance, we suspect we're not spending enough time using the black box to explain functions and that we're actually spending more time than is necessary using light bulbs to explain binary, though future work includes identifying more precisely why some didn't work as well as others so that we can retool. 

From surveys of students, though, we already know that the course's use of physical props, help me understand at a different level and help me remember the material better, which was precisely a name. They made me comprehend something instead of just recalling it. For instance, I will never forget about locking transactions. Think double milk jugs. Or link lists, think boxes connected by arrows pointers. 

It helped to visualize all of the code and ideas that would otherwise just be letters, symbols, numbers, and indents. It really helped me stay engaged, especially in the virtual nature of this semester. The flip side, though, is that all the theatricality, even if modestly implemented with just paper and tape, does come at a cost, namely time. 

As one student put it, the demos were often unnecessary, helpful but unnecessary. For me, an animated diagram on the slides would have been sufficient and often felt that these demonstrations took up more time than necessary. And another student distinguished between engagement and actual learning. I like them because they were engaging, but I don't think they helped a lot with my learning. That said, another acknowledged that I don't really get value from stuff like that, but I know it helps others. 

So that's a balance we ourselves have long struggled with. Indeed, if there's been one long-standing critique of CS50 it's just that it's too theatrical for some students tastes. In fact, one of his papers on reviewers couldn't have said it better. In a teaching environment, there is a balance that needs to be struck between the inquisitive newcomer, who we want to inspire, and the more advanced early student that we want to challenge. 

How much theater in the classroom for an individual class is advisable? Finding that balance, then, is among our own goals ahead or perhaps confirming that we have found it, even if the global optimum isn't locally optimal for some learners. And we don't yet, but it would be nice to track the impact of these memorable moments on students beyond the end of our own one course or, better yet, beyond graduation as via surveys or even assessments to ascertain if they help students visualize, understand, and remember concepts only in the short term or in the long term as well. 

Videos of all these demonstrations and more can be found at youtube.com/cs50. Please do reach out via email with any questions, and thank you to all of my colleagues at Harvard, to all of my teachers and professors past, and to our friends at the American Repertory Theater. Theatricality does not require an actual theater, but in that particular moment in time, we do think our course was the better for it. And it seems only appropriate to end this talk now on a theatrical note. 

[MUSIC PLAYING]