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]