Reading Time: 7 minutes

This spring, I taught a course on iOS Development in the University of Chicago Master’s Program in Computer Science.

I had spoken, mentored, given workshops, and guest lectured before, but I had not taught a full class. I took you on my journey through the application process from syllabus design to doing the audition lecture. Now that I have taught the course, I’d love to share what I learned.

This is the first post in a three-part series:

So, in no particular order, here are some things I didn’t know when I started teaching that I’d be glad to know going into it again.

Questions

I knew, going into teaching, about the awkward silence between students and a teacher after a teacher asks a question. I felt sure that I would be the amazing, inspiring teacher who traversed this boundary. I was not, at least not yet.

Maybe you will be that teacher. I wish you the best of luck. Let me share with you everything I tried, in hopes of giving you a head start.

• I tried asking questions where we had just discussed what the answer would be.
• I tried asking questions that the students had learned the answer to in the last class. 
• I tried waiting for 20-30 seconds for an answer. Again silence, though after this went on long enough, one student in class would roll their eyes and say the answer. It was always the same student.
• I tried asking questions with no right answer, to prompt a discussion.
• Before I asked questions, I reassured the students that there wasn’t a right answer and I expected speculation.
• I tried doing an experiment with class participation, then engaging in a discussion of our results. This actually sort of worked. We had just finished a discussion of the efficiency of network requests. So, during our ten minute break, half the class streamed Spotify for ten minutes, and the other half streamed Pandora for ten minutes. We noted that Spotify streaming ran down the handset battery faster than Pandora, and we speculated on what some of the reasons for that might be.

I can’t say I have solid recommendations, therefore, on encouraging the students to answer questions.

Here’s what I can say: when students first join a class, they don’t know the teacher, so they’re apprehensive about how the teacher might react to wrong answers. For this reason, on the rare occasion that a student answered, I would be sure to tease out the truth in their answer regardless of whether it was right to encourage more speculation in the future.

And as the class wore on, students didn’t answer more questions from me. What they did do was ask me more questions. We went from a silent class to a class where students would interrupt me to get clarification or additional information. If I knew the answer, I’d share. If I didn’t know the answer, I’d make a note of it, do some research after class, and share what I had found out during announcements at the beginning of the following class.

The increased question-asking also correlates with a livelier class in general. In a future post, I’ll talk about some of the changes I made to help folks stay engaged through the three hour block.

Live Coding

When I started teaching, live coding terrified me. I knew I would mess something up and confuse all my students, and they all would hate me. I tried to avoid it by writing all my example code beforehand, divided into step-by-step commits that I could check out one by one to show incremental change.

This might work for some stacks. It didn’t work well for iOS because iOS depends on the use of an integrated development environment called XCode that includes a lot of clicking and dragging, changing things in drop-downs, and other visual interface elements that don’t show up well when I check out commits. Students needed the opportunity to see me do those steps. So, I had to do it live. Most of the time, it went OK.

I got lucky: live coding only went sideways for me twice.

The first time, I had used a prefab master-detail app template. That’s how I learned that the Apple team favors a programming pattern for master-detail that I find unnecessarily complicated and prone to issues. I went to refactor something, and some stuff stopped showing up on the detail page. Luckily, my amazing TA (Hannah Bennett) was there, and she had offered to keep an eye on things to help out as needed. She and I are both tenured pair programmers. So, when things stopped working as expected, she and I were able to collaborate in real time in front of the students to debug things. In the end, we figured it out. The slip ended up being a useful demonstration for the students of how to incrementally debug when things go wrong.

The second time, I did not get so lucky. I was nesting some stack views inside of stack views, and I went vertical-then-horizontal when it really would have made more sense for my end layout to go horizontal-then-vertical. I didn’t quite realize this until I was trying to show them some relatively advanced options for manipulating stack views, and they weren’t working the way I had envisioned. I didn’t have time to fix it at that point. I didn’t want to just let it go, because my pet peeve as a programming student has always been teachers who try to show me how to do things with code that doesn’t work. So I drew a diagram on the board of how I would do it. Then, after class, I changed the code, pushed a new commit to the repo, and sent the students a note that the example now worked as described in our diagram from class.

On a third, related occasion, I wasn’t live coding: instead, I had made an app before class that persisted data three different ways on three different branches (UserDefaults, FileManager, and CoreData). During class, I found a bug in my FileManager implementation. It didn’t help that, in the moment, I didn’t understand exactly what had gone wrong. But in this case, I used what I learned from the stack view situation. I went home, debugged on my own, found the problem, and fixed it. Then I pushed a commit to the repo with the fix. Then I wrote up a summary of what I had discovered and what I had changed, and I sent that to the students.

So, I do better in anxiety-producing situations when I have steps to follow. That’s why I have steps to follow when I receive critical feedback.

I found that having steps to follow for code going wrong during class made me less apprehensive that it would happen. That’s important because there’s no way that I know of to avoid this happening sometimes, no matter how much we prepare. But I could follow up with a fix and know that I wasn’t leaving my students stranded. After I had established a pattern of doing this, my students also knew to expect it, so mess-ups during class-time coding made them less nervous, too.

Conclusion

Going into my first teaching position, I wanted to avoid some of the awkward and detrimental things I have seen in computer science classrooms.

I didn’t manage to avoid them, exactly. I still asked questions that landed flat. I still had live coding sessions go wrong.

But I learned new things about how to salvage these cases and turn the experience into something from which the class can still benefit. In these two cases, most of the lessons came from my own experimentation.

I learned other lessons during this course by asking the students themselves. I talk about some of those in the next post.

If you liked this post, you might also like:

The rest of the behind the scenes series

The leveling-up series on advancing your own skills

The series on reducing job interview anxiety