This afternoon I gave a lightning talk at Tufts. The whole event was really wonderful and it was fascinating to learn about all the different kinds of research going on here at Tufts. Every talk I saw was unique and fascinating. Since I wrote a speech, I figured I might as well share it here:

Hello, my name is David Zabner and I am a first-year STEM Education Ph.D. student here at Tufts. I have spent the last few years teaching computer science, at bootcamps, here as a TA, at Cornell College as a lecturer and for two weeks in China as a visiting faculty member at a university there.

I am going to start by describing my experience of teaching in China and I will argue that we should teach computer science in as much the opposite way from how it is taught there as possible. This is necessarily an extremist argument and I will happily admit that the most perfect way almost certainly lies somewhere in between the two extremes.

So there I am at a small Chinese university, hired to lecture about Java programming for two weeks, 10 1.5 hour classes, to about 100 students. My plan had been to review Java basics over the first three days to get students used to listening to lectures in english, and then to move on to more advanced topics in Object Oriented Design. On the first day I found out three things:
1. I needed to speak slower than I thought possible in order to be understood,
2. The classroom I was teaching in had one wall covered in answers to a multiple choice exam on english and
3. My students knew absolutely nothing about how to program in Java or for that matter in any other language.
These students, many of whom brought laptops to class, had not even installed the tools necessary to actually program on their machines. This was very surprising to me as I was teaching at the end of a semester in which they had all been studying java and I knew that they had all already taken a class in C++.

I asked around and got a basic explanation for why this was the case: the programming classes these students had taken consisted of a semester of lecture, followed by a high stakes final, which was not changed from year to year and which every student cheated on. The faculty informed me that given that every single student cheated they had the option every semester of failing all the students, and losing their jobs or allowing them all to pass. 

In short, this classroom of pedagogic hell had the following characteristics:

1. Education based purely on lecture
2. No chances to practice the thing being learned
3. No feedback from classmates or instructors
4. A single event that decides a students grade

When I got home, knowing that I would get a chance to teach an introduction to Computer Science class of my own the next year at Cornell College so I set about designing the opposite class. It had these characteristics as goals:

1. Education without any lecture at all
2. Constant practice of the thing being learned
3. Regular feedback from classmates and instructors
4. Many chances to affect a students grade

To give the students practice, feedback, and many chances, I used mastery grading and a huge quantity of optional homework, which I highly recommend, but I want to focus here on “content delivery”.

This consisted of coming to class every day with some code that I wrote and handing it over to students with a button that ran it (I did this using a wonderful platform called Replit). I then asked the students, alone, in groups, and as a class to de-code what I had given them, explain it, identify patterns and rules, and make changes. I was inspired by a poetry class I took at Cornell that focused on learning to do close reading before writing your own poetry. Once they had decoded and were comfortable with reading the day’s code, the homework consisted mainly of prompts asking them to edit and extend the code.

I found that teaching this way was spectacular! Firstly, with a little structure and support from a partner, every student in my class was able to, in an hour and a half, go from never having seen code before to confidently explaining the behavior of 100 lines of Python. By the first midterm students were able to do the same in a programming language, Golang, that they had never seen before, while under the time pressure and stress of an exam. Secondly, by untethering myself from the lectern I was able to dedicate more time to supporting students alone and in groups. This meant not only individual attention for the students, it also meant that I could focus on discovering what my students were and were not learning. Finally, students reported that they loved this method of learning and I had zero incidents of students falling asleep in class. 

I also hope that this gives my students a durable ability and confidence to learn a new programming language, a skill critical to anyone who is programming regularly and even more important for those who program rarely, as every time they sit down to do it it will probably be in a new language!

One of my goals over the next few years is to find ways of answering the question of whether or not this way of teaching works as well as I think it does. Since I am just starting to learn about how to do educational research I am still a little unsure of how I will answer that question but if you have ideas, I would love to hear them.

Thanks for your time! Any questions?