Reading Time: 13 minutes

This post is part of a behind-the-scenes series about how I obtain and prepare for opportunities like podcast interviews, speaking gigs, and instruction roles. The last one talked about syllabus design, the example being a course about iOS.

After I submitted that syllabus to a local University I did a telephone interview, and after that they brought me in to deliver a sample lecture on the topic of the UITableView (a key component in iOS development).

So this post focuses on how I planned that sample lecture!

Teaching to the Brain’s Strengths

Years ago, I assistant-taught for Dr. Jeremy Watt in an evening course on machine learning. His book, Machine Learning Refined, had profoundly impacted my understanding of the concepts I had read about in other sources.

Here’s why: Dr. Watt starts by explaining a few fundamental concepts, and then he illustrates how many of the applications of machine learning stem from one or more of these fundamental concepts. He shows his students the connections between different ideas and highlights their similarities rather than their differences.

That’s the opposite of what we see in a lot of scholarship—and particularly academic writing. We talked about this in a previous post about academic papers:

Journals and dissertation defenses also both favor findings that are “new,” so scientists are forced to artificially differentiate their work from previous work, even if they’re substantiating existing claims or creating a model that’s extremely similar to an existing model. When done in iterations, this veers the academic literature in the direction of making everything seem more complicated than it is.

The brain has a hard time organizing and remembering a lot of little disparate pieces of information. Our learning thrives, though, when we can connect new information to the existing network of information that we already understand. If my fiddliest rule of teaching is to insist on precision in the syntax of the technical examples I show, them by broadest rule of teaching is to insist on drilling some critical fundamentals and then connecting new information to those fundamentals later on.

So I imagined my lecture on the UITableView in the context of the broader course. I considered the following: how will this lecture contribute to the overarching goal of helping students think critically about code, and particularly about iOS code?

On This Map, You Are Here

Here were the course goals as discussed in the iOS syllabus:

• Understand the difference between functional and imperative programming and identify good use cases for each

• Test and implement fully featured iOS applications using Swift and Xcode

• Appreciate and participate in ideation and user testing as well as implementation and deployment

• Analyze the decisions that app developers make while building products for the App Store

I wanted to situate this sample lecture in the context of the course. I shared these assumptions with the sample lecture audience before I began the lecture. I assumed that this lecture constituted Hour 7 out of 30 in an iOS course for students who knew at least one programming language, but not necessarily Swift.

In this course, we would have already experimented with both imperative and functional programming. We would also have already talked about test-driven development, and we would have already walked through a test-driven example with several database objects as well as a plain old Swift object that would help us manage the database objects. Finally, we would have already written our first iOS app: a single view application in which we used Interface Builder to make a UIStackView for displaying a to-do list.

So in this lecture, we would refer back to our understanding of imperative programming, testing, and interface builder components.

Creating a Curricular Story Arc

At the end of lecture 6 where we made our first app, we ran into a challenge: no way to manage an arbitrary number of items on our to-do list. We would overcome that challenge in this, lecture 7, with the UIStackView.

Here’s why that’s important: folks have an easier time absorbing knowledge if they have previously run into a need for this knowledge. Learning feels, this way, like a mystery to solve instead of a set of things to memorize with no clear purpose. I have seen many lectures that include lots of explanation, then say at the end why this matters. I find it more effective to reverse the two. Hence, the challenge. I would also need to come up with a challenge to end this lecture, which we would resolve by learning more information in the following lecture.

Highlighting the Connections Between New Information and Recurring Concepts

I also wanted students to understand where we are in the context of the wider programming world. The goal is not to produce iOS programmers: the goal is to produce competent programmers. iOS is the medium rather than the subject matter itself.

To draw an analogy: I went to art school. We started with black and white charcoal drawings. Later we used pens, then color pastels, then paint. The lessons I had learned in charcoal—lessons about composition, contrast, and perspective—also transferred all the way up to paint. I didn’t start over with “how to make a nice picture” in every medium. Similarly, I wanted to use iOS as a practice medium for exercising programming concepts.

So what are the composition, contrast, and perspective equivalents in programming? For my course, I alighted on two broader concept areas I wanted students to understand: the design of programs in general, and the design of mobile apps specifically.

Here are the two lists I came up with:

What characteristics do we consider in evaluating program design?	What characterizes mobile apps more than other programs?
Robustness: How does the code react to the unexpected? Developer Legibility: What would it take for another technologist to maintain this code? Dialogue: How does a user share their expectations about this program? Performance (accuracy): How close is this program to its user’s expectations? Performance (speed): What is the time frame for this program to give the users what they want?	UI Flexibility: for different screen sizes and orientations Object Conservation: to preserve the use of memory and resources on a relatively small computer Tall Hierarchies of Inheritance: to abstract away the details of object conservation from app developers Networking Efficiency: for working in circumstances of weak connectivity

First, in previous hours of lecture, we would have talked about program design: what makes a good program? How do we talk about a program besides “I like this program” or “I don’t like this program?” The first list gives students tools to think about programming, design their own programs, and understand the motivations behind the choices other technologists have made.

Second, we would also have talked about mobile development. This is an iOS course, and we use the iOS framework. But iOS shares lots of characteristics with the Android framework, dual-platform mobile frameworks, and the ancestors of the mobile phone (think palm pilots and mobile scanning guns). I want students to know that, if they know iOS, they already know a lot of things about Android, too. When I learned color pastels, much of what I learned with black pastel came to my aid.

And critical for professional technologists is the ability and enthusiasm to work on problems that they’ve never solved before—sometimes, to work on problems no one has solved before. And the key to success at this, in my experience, is building confidence that we already know some of what we need, and we have ways to figure out the rest. Equipped with those two things, we can get astonishingly far.

The Lecture Itself

So, at the beginning of the lecture, I shared my assumptions about what we had already covered. Then, I wrote an abridged version of our two guiding lists on the board: one for general programs, one for mobile apps. I would want to refer back to these throughout the lecture to talk about why UITableViews work the way they do and what we can learn from them about general programming concepts.

I had prepared a repo for this lecture, where I test-drove our entire UITableView feature before class. For this, I drew heavily from Dr. Dominik Hauser’s book, Test-Driven iOS Development with Swift—though I wrote several things a little differently than the book based on my own test-driving preferences :). I made commits for each and every step so that I could walk through them with the students:

Why didn’t I live-code it? Two reasons. For one, live-coding is very error-prone, and that throws off students who are new to the material. Case in point: I did, in fact, start off the lecture by live-coding a minimum viable list app. This was a review of the theoretical “homework” I would have given the students to prepare for this class. The demo took about 4 minutes and served as an overview on the UITableView. It included about a dozen lines of code. In the four minute demo, I accidentally autofilled the incorrect implementation on one line: an implementation that omitted an optional unwrap (in Swift, this is done with a ‘!’ at the end of the line). It took me several seconds to spot the error. This is in a four minute example with twelve lines of code—and an example, no less, that I had dry-run three times that morning to make sure I could do it cold. In a complicated, test-driven, professional-level implementation, how often would this have happened?

The second thing about live-coding is that, by default, it puts a lot of emphasis on syntax. Students do not need me to give them syntax: XCode gives you syntax. Documentation gives you syntax. If those both fall through, you can Google syntax. My value, as an instructor, comes from drawing the connections between concepts and explaining the why of things, rather than the syntax. I wanted to show students precise code and spend my time pointing out where it was beautiful, where it was ugly, and why, why, why.

To that end, I had some notes about which elements of each step I wanted to emphasize in class:

I would pull up each commit step by step and show the students the diff in AppCode (which didn’t want to open the first few tries, so after the lecture I tested out the same thing in gitx, and I I’ll use that for lecture diffing from now on). Once we had the diff up, I would check the notes and emphasize the parts of the commit that introduced new concepts or reinforced old ones. The most important ones, which you can see in the lecture notes, are the arrows: places in the implementation where we reinforced some of our general concepts about mobile development. We stopped several times in lecture to tie back our examples to the two lists we had written at the beginning.

One other thing on lecture execution: I try, throughout, to give students an opportunity to share their thoughts. For example, at the beginning when we wrote down the lists, I would ask here for folks to tell me what I should write (which they would theoretically know from previous lectures, were this not a sample). At step 3, we differentiate UIDataSource and UIDelegate. Throughout the remainder of the lecture when we implemented a method from one of these protocols, I asked the students which one they thought it came from based on what the method did.

Finally, you’ll notice in the lecture notes a big box at the end of the step list that says “CHALLENGE: HOW DO WE ADD, REMOVE, STORE DATA?” I wanted to end the lecture with a challenge we faced in our current approach, so that students had a little mystery to think about that we would solve in the following lecture with some new concepts. For the next lecture, we could either go into manually adding data (forms) or fetching preexisting data from an API. Both of these features are ubiquitous in production iOS apps, and we would want to find opportunities to do them both in future classes.

If you’re interested, here are the slides that I used for this lecture as well.

Conclusion

Preparing this sample lecture gave me the opportunity to think about some questions that I think are important in lecture design:

• How would this lecture fit into the overall syllabus for this course?
• How would the syllabus for this course contribute to students’ overall education, including their preparation for other courses?
• How do I articulate the concepts I want students to carry with them into those other courses, and what can I do to constantly refer back to them as we learn new material?
• How can I create tension from the last lecture to this one, with a challenge that students are excited to solve?
• How can I include some “live action” so that students get to see some coding happen in real time?
• What other resources do I need to prepare so that I can provide students with precise syntax while spending lecture time emphasizing why we might do things this way?
• Where can I engage students by giving them opportunities to apply information they already have to a new situation?
• How can I create tension into the next lecture with yet another challenge that students will want to solve?

In the process, I had the opportunity to draw from my memories of excellent teachers I have had in the past. As I continue to look into opportunities to teach, I’m excited to meet other instructors and learn even more about the art of informing and inspiring others.

If you liked this post, you might also like:

This post containing my first screencast (a very different medium for teaching than lecturing)

The leveling-up series (about personal professional development, inside and outside the context of being taught)

This post on pairing (one of my favorite information transfer media)