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 talked about questions and about live coding. In this post, we’ll address a particular challenge: a three hour lecture block.

My class block ran from 5:30-8:30 PM on Wednesdays.

Picture this: it’s halfway through the week. Folks are tired from their full time jobs or other classes. After the day is practically over, the students come to a technical class. For three hours. 

My first few lectures exhausted everyone involved. If I didn’t prioritize drinking water, I would find myself coughing. At the end the students would sit, staring, catatonic, before silently trudging out the door.

I needed to figure out how to make these classes work better. So I talked to a few students after class, and a few more at office hours. Then I started testing some changes to the class format. I made surveys with Google Forms after the third lecture and the sixth lecture (out of ten) to get the students’ perspectives on what worked and what didn’t. I’ll share some of those results with you throughout the remainder of the series.

Here’s what I learned.

 1. Breaks matter.

Three hours is too long for most folks to stay focused in class. I knew this going in, so for the first two lectures, I included a fifteen minute break about halfway through class.

After the second lecture, I replaced that break with two ten-minute breaks. This separated the class into three sections, each one a little under an hour. The students immediately seemed more lively at the end of class as a result of this change compared to the previous two sessions. I wanted to make sure that I wasn’t misreading this, so I included a question about it in the first survey:

You can see, one student did prefer the first way. Unfortunately, when you’re working with a group like this, you can’t please everyone.

I later tweaked this to one 12 minute break and one 8-9 minute break. I did that because we have a cafe close to the class building where folks would go to get food or coffee during the first break, and it took people about 12 minutes to get back from doing that. I wanted folks to have the chance to get something to eat without missing things. I myself would bring yogurt or a bar to eat during the breaks, but I would stick around in the classroom to answer questions. I did get a “break” during the sessions, but it wasn’t the same as the student breaks. We’ll talk about it soon.

 2. Variety matters.

For the first two sessions of class, I switched back and forth between two activities: lecturing with slides, and writing (simple) apps from scratch while the students watched.

I do think the slides had their place. When students have never seen iOS before, the slides help me provide them with some critical context. In retrospect, I would have changed the live coding part in those first two sessions.

As the sessions continued, I introduced other activities to the class.

Some examples:

 1. Code-alongs

Instead of coding by myself for the students to watch, I’d break down my demonstration into steps. I’d do one step, then leave time for the students to do it. In retrospect, I wish I had done this instead of the live coding in the first few sessions.

Here, I ran into a speed dilemma. One or two students really wanted me to go faster here, but most students wanted me to slow down. So I started asking, at the end of each step, if I had everyone, and waiting until folks seemed ready before I moved on.

People liked these, on the balance:

 2. Code labs: For these, I would make an app before class with any features that were tangential to the day’s lesson already implemented. I would leave out a feature that required some of the concepts that we were learning that day.

Then, after introducing the concept, I would direct the students to the app repo, and I’d challenge them to implement the feature. These were usually small features: animate this specific view, adjust the font size based on the device orientation, or fix a table view bug whose cause we just discussed. Students would get ten minutes to implement the feature themselves.

Once ten minutes were up, I would do the code-challenge myself in front of the students. This served several purposes:

1. It helped the students stay engaged, because problems feel more interesting when you have already tried to solve them yourself, or have developed your own questions about them.
2. It gave me an opportunity to take a break in class. Since students knew I was going to implement this in front of them in a few minutes, they didn’t ask many questions during code labs. This felt in line with the activity’s design: the point is for them to try new things on their own first. This gave me an opportunity to drink water or go to the bathroom, since I usually found myself answering questions during student breaks.

People found these really useful, based on my collection of pies:

Code labs also received several compliments in the student comment portion of final course evaluations.

 3. Demo apps

As we progressed through the class, the concepts we were learning built on more foundational ones, and they became too complex to efficiently live code from start to finish in class. So in these cases, I would again write an app before class to demonstrate the new material. I would then walk the students through that app during class—in fact, I sometimes combined the demo app and the code labs by making examples that demonstrated most of the concept, with one piece left out for students (and then me) to implement and commit.

Students could clone these demo apps to play around with the new concepts and run their own experiments. To me as an engineer, this type of resource feels more practical than slides.

 4. Spelunking app store apps

I found a list of open-source iOS apps written in Swift, and I narrowed this down to apps that were deployed in the app store. The list included some interesting apps: a Swift implementation of the game 2048, an app to help people track their water consumption, an app to mix music tracks, among others.

For each big concept we covered in class, I would try to find an example of its use in one of these apps. I would then pull down the code, and together with the students, we would explore it. We would first locate the part of the app that contained the concept in question with a combination of search tools and understanding how apps are organized. We would option-click on iOS API methods to read their documentation, then command-click to verify their implementation. We would change things in the client code and run it on the simulator to confirm whether our changes showed up in all the ways we expected. My hope is that this exercise reinforces code exploration and debugging skills that students can use in any language or framework.

I don’t know if my hope was realized, but students did appear to get something out of it:

This activity also got a couple of mentions in survey comments: at least one student particularly wished to see more of this.

 5. Discussions

I would try to set up a question and give the students an opportunity to talk to each other. This didn’t work as swimmingly as I might have hoped. We did get somewhere once, as discussed in the previous post of this series.

The discussions didn’t share the universal popularity of the other activities, though:

I’d like to keep working on this before I opine on how to do it.

Conclusion

Three hours is a long time for folks to focus on technical skill building, particularly at the end of a long day. In order for it to work, we needed to take breaks, and we also needed to keep things interesting.

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 the next post of this series, we’ll zoom back out to talk about session structure and helpful resources for teaching.

If you liked this post, you might also like:

More career-building posts (think podcasting, speaking, etc.)

This post on pair programming (I didn’t force the students to pair, but I believe the skill is valuable)

The leveling up series (people like this, so when I run out of ideas for this section, I link to this)