Behind the Scenes: Teaching a Programming Course, Part 3

Reading Time: 9 minutes

This spring, I taught a course on iOS Development in the University of Chicago Master’s Program in Computer Science. In this series, I’m sharing some lessons from that experience.

In the last post, we addressed how to keep folks engaged through a three hour lecture block. Here’s a refresher from the conclusion of that post:

Though this may not be the case for all classes, our class found two shorter breaks more refreshing than a single, longer one. We also got a lot of mileage out of keeping the course material interesting by presenting it through a variety of different activities, all of which gave students more opportunities to directly participate than the lecturing with slides did.

In this post, I’ll zoom back out and talk about how I framed these activities together. I’ll also go over some of the resources that informed my teaching, and I’ll pick out a specific one to recommend to you.

For all these activities: Setup matters.

For the first few sessions of my class, I did not share my session plan with the students. Instead, we moved together from topic to topic, and I introduced the next topic right before we started talking about it.

Students had an easier time staying grounded in class, though, if they knew the plan for the session and could gauge our progress against it.

Here’s where that gets tricky: I did not always know exactly what we’d be able to cover. What if a portion took a lot more time, or a lot less time, than I expected? What if I needed to stop and answer questions for a while? What if one of the exercises proved particularly confusing? Those things can happen in any classroom, and longer sessions are particularly susceptible. Plus, this was my first time teaching this material. I could easily misjudge how long things would take.

So I had built flexibility into my plan by labeling parts of the lecture with a priority of 1 (essential) or 2 (not essential). If we hadn’t reached some predetermined point in the material by the time a break came up for the class, I’d remove a section with a priority of 2 to make sure we still finished on time.

Once I started sharing the plan with the class, adjusting on the fly meant doing things differently than I had said I would do them.

This didn’t happen to me often enough to become a huge issue, but honestly that might have been luck. If you’d like to try a strategy like this but you’re worried about mismatches between the outline and what you actually teach, there is a backup strategy that my students also found helpful:

Go from topic to topic during the session itself, then provide a summary at the end of class of what you’ve covered, and what (in general) you’re likely to do in the next session.

Resources that inform the way I teach

I knew that I wanted to commit to teaching as well as I could, so looked to folks I admire for examples. I re-read pieces of some of my favorite programming books to think about what made the author’s presentation of the topic so interesting or memorable. Big examples here: Working Effectively with Legacy Code, A Common Sense Guide to Data Structures and Algorithms, Machine Learning Refined

I also turned to other people when I had questions or struggles during my teaching.  First, I spoke several times with the academic director of the computer science program. His experience teaching students in general, and computer science specifically, enabled him to make practical, valuable suggestions when I was stuck. He also managed to anticipate (and allay, somewhat) my concerns about issues that were bound to come up in the course of teaching.

Second, I corresponded with a friend of mine who has been a women’s counselor for fifty years and a middle and high school history teacher for decades. He argues that the fundamentals of good teaching and good storytelling are the same. His advice to “present important material like a mystery, and engage the students in helping you solve it” directly influenced my design for the code labs, which were pretty popular in class.

Third, I chatted with another friend of mine who is a professional magician. At some point I’d like to do a whole post on the way stage magic can inform teaching and presenting, but for now, I’ll keep that secret for you :).

I also perused a few books that specifically covered how to teach. One of those books fundamentally changed my approach in the classroom: Chris Emdin’s book, For White Folks Who Teach in the Hood.

Dr. Emdin speaks specifically to the experiences of black youth whose white teachers don’t understand their lives.

Let’s address the elephant in the room: I teach in a graduate computer science program at an elite university. In order to end up in my class at all, every single student has had to successfully navigate white-centric academic paradigms for close to two decades. I don’t fancy myself a white person who teaches in the hood. Nevertheless, the time to unlearn racist ideologies is always.

But also—and this is a critical point—the changes I made as a result of reading this book shaped me into a better steward of learning for almost any audience. The only folks who prefer my old teaching style to my new teaching style are the folks who would have learned this material on their own in the absence of having a class at all.

And that’s not who I teach for, because those folks don’t need me. I’m less good, now, to that audience, and that’s fine with me because they’re not my audience.

Big things that I changed after I read this book:

  • I take time to consider what the students can bring to the classroom, that I cannot. In any classroom, that includes their unique interests and lived experiences. Specifically in the computer science classroom, it also includes their questions and concerns about the APIs we use. We can then further investigate these questions together as a group—even (especially!) when I don’t know the answer.
  • I collect regular feedback from students: not vague feedback on me as a teacher or the class as a whole, but specific feedback on the activities that we have tried in the classroom. This gives students an opportunity to participate in deciding how we structure our sessions.
  • I try to provide context for the material that I am teaching. Why is this API the way it is? What conflicts, decisions, and personalities shaped it to be like this? Do we see that in other parts of the API as well? Where are the inconsistencies, and why might they be that way?

Small things that changed after I read this book:

  • Instead of having students do independent lab work or take breaks in awkward silence, I play background music.
  • I have separate times and activities for students to take breaks and for me to take breaks. So I am accessible to students during their down time, but I also get down time to preserve my engagement capacity.
  • I don’t give extensions or extra points when students e-mail me to ask about them. I know that this leeway often only exists for students who were raised and socialized to see teachers as peers and ask them for things they didn’t initially grant. So granting this leeway puts students who were raised to see teachers as authority figures at a disadvantage (and—you guessed it—there are strong demographic trends here.)

I recommend giving this book a read regardless of who you are or who you teach.

Conclusion

Throughout the classroom sessions, I found it helpful to switch between a variety of activities to keep folks engaged. The students appreciated having a session outline to track these activities—even though that meant that they would notice if I changed the plan on the fly. They also appreciated having a summary at the end, so if changing things is a big worry, I think a teacher could do just the summary at the end and still see some benefit.

A lot of my teaching principles enjoy the direct influence of other people who know a whole lot more about teaching than I do. I tried to follow the examples in some of my favorite programming books in the way I explained technical topics. Several mentors made excellent suggestions that helped me navigate the ups and downs of teaching my first course, too. Finally, I took a lot of wisdom from books that specifically cover the topic of teaching.

Were I to recommend just one of these books, I’d recommend For White Folks Who Teach in the Hood (and the rest of y’all, too) by Chris Emdin. You can tell from the title that the book aims to inform a specific subset of teachers, but I think this book is worth a read regardless of who you are or who you teach. The changes I made as a result of reading this book shaped me into a better steward of learning for almost any audience.

If you liked this post, you might also like:

Reducing job interview anxiety (for when you put yourself out there for that teaching gig!)

This talk on giving and receiving feedback (A 13 minute distillation of a whole post series, just for you)

Principles of feature engineering (zero relation to the teaching topic, but this series was fun to write, and hopefully both useful to data scientists and illuminating for the data science-adjacent)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.