I sometimes write about what I’m learning from teaching computer science courses: first an iOS Development course, and now a course of my own design called Mobile Software Development. You can see all the posts in the “Designing a Course” series right here!
When I started writing about how I’m designing this new course, I was planning on a colocated academic quarter, where I would meet the students in a classroom. As pandemic has engulfed the world, the University wisely elected to run all of the spring courses online.
So in this post, I’ll show you how I’m getting from list of topics to cover in a session to a plan for what we will do in the session.
A Buffet of Teaching Methods
One can do all kinds of things in a classroom. When folks picture a classroom, though, the image usually features one tactic in particular: lecturing.
Don’t get me wrong; I’ve hopped on a soapbox in my day. But I have some heterodox views about speaking that impact my willingness to lean on lectures. They are that:
- Story narration excluded, the info transfer threshold for a talk is about 20 minutes. After that, audience comprehension drops off a lot. My talks are usually didactic tech talks, which aren’t narratives. So I keep my talks to 20 minutes.
- Talks are even tougher to make effective in a live remote format than in an in-person format, or even a recorded remote format.
I don’t find three hours of remote lecture to be an effective use of teaching time. So I spend a lot of time—and even more this quarter—experimenting with other ways to deliver information, like:
- Pre-recording my programming demonstrations and letting students follow them at their own pace during class, while making myself available for questions in a chat channel.
- Creating code challenges for students to approach, individually or in pairs, followed by a video tutorial explaining a solution.
- Creating discussion prompts and dividing students into small groups to discuss them.
- Creating sample applications and prescribing changes to those applications for students to code together in groups.
- Opening question and answer sessions during class about specific topics of the students’ choice.
Fitting Instruction Methods to Topics
Suppose I have this list of things that I want to talk about in an upcoming lecture:
- The Kotlin Programming Language
- Automated Tests
- Regression Prevention
- Engineering Codes of Ethics
This list looks short, but it’s pretty ambitious for three hours (I have learned this the hard way. Just like it’s hard to estimate how long something will take to code, I find it hard to estimate how long something will take to teach—especially if I want to answer the questions and make sure I have everybody on the same page).
I want to include a few different information transfer formats, and I want to switch up what we’re doing every 20 minutes or so. I call this the “Adult Sesame Street Model.”
The book Street Gang by Michael Davis chronicles the development of Sesame Street, the legendary public television show for children. In 1969, children’s television “best practice” was to make things repetitive and thereby overtake childrens’ inability to pay attention. Sesame street took a different tact—instead, the show kept each of its stories and lessons to a tight three minute timeline. This worked with children’s attention spans, rather than against them, and delivered a variety of lessons and stories in an episode.
My lessons are 180 minutes; 3-6 times the length of a Sesame Street episode. And I teach adults, not children. So instead of a “tight 3,” I go for a “tight 20.” But I want to preserve the feeling of those episodes in an evening of teaching: each premise is over before it gets boring.
Slotting in my Tight 20’s
Here’s how my lecture plan might look to cover those four topics above. I’m going to put some phrases in italics; we’ll come back to them.
10 Minutes – Debrief the homework, in which the students wrote their first android app. I will ask them how they like Android development, and how it compares to their experience with iOS development.
20 Minutes – Intro to Kotlin. Students divide into groups of four. Each group receives a shared presentation with 9 slides, and each slide has a question about Kotlin on it. The students work together in their groups to find the answers to the questions. I bounce around between the breakout rooms to answer questions and monitor the shared slides files to determine when the groups are done.
20 Minutes – We all regroup, and I go through the answers to the questions. I invite specific groups to chime in if they got the answer right to the question I am going over at the moment.
12 Minutes – Break
15 Minutes – They individually write their first unit test in Android, following a video demonstration I made for them at their own pace, while I am available for questions in a chat window.
10 Minutes – They then watch a tutorial video that reveals a bug in the Android app they have developed!
15 Minutes – They work in groups to try to write a unit test that replicates the bug, using a piece of example documentation that I selected for them. I bounce around among groups to see how they are doing.
15 Minutes – They watch a video that explains how to write the unit test.
8 Minutes – Break
15 Minutes – I introduce another group activity in which we talk about our codes of engineering ethics (I asked them to consider personal codes of ethics for homework)
40 Minutes – In groups, students receive three scenarios of varying levels of ethical ambiguity. For each one, they discuss for about eight minutes what they would do. Then we regroup and spend four or so minutes discussing their answers.
5 Minutes – We go over the homework for the following session.
There’s a fair amount of pedagogy going on in this lesson plan. It’s not the subject of this piece, but I’ll point some of it out briefly, for interest’s sake:
- Students get to share their opinions at the beginning of class. This warms them up to participating with an “easy” question that gets them thinking of themselves as practitioners of a craft, rather than observers.
- For programming demonstrations, I have done the demonstration ahead of time, effectively cloning myself so I can answer questions in real time.
- For the Kotlin questions and the defect replication test, students try to find the answer themselves before I share it. This allows them to practice their investigation skills and also helps them invest in the questions, so they bring curiosity about the answers to the discussion where I reveal those answers.
- During regroup, I call on groups that got the answer right. Once I have demonstrated a pattern of doing this, students trust that I’m calling on them to elevate their findings, not embarrass them. They’re more enthusiastic to answer.
- Students do most of their programming (left brain) work early in the class and move to imagined scenario (right brain) work as we approach bedtime.
But most importantly, I am not talking for longer than 20 minutes at a stretch, and I only do that twice in the whole 3 hour lecture.
Now, what’s up with those italicized parts?
What preparation do students need to get the most out of this?
This is the part where I work backwards. For each topic, I consider what knowledge or experience students need to bring with them to class in order to enjoy and learn from the activities. I call this prerequisite knowledge or experience a stimulus—this is the word that crossfit coaches use to describe what physical adaptations they want an athlete’s body to make in response to a training program.
Here’s the thing: coaches don’t just want to hammer an athlete with as much work as they can take. Coaches instead want to deliver the highest likelihood of the desired stimulus with the minimum amount of stress on the athlete’s body, because more stress exposure = more risk of injury. Injured athletes don’t earn money for coaches.
Similarly, I try to design homework assignments to maximize likelihood of delivering the learning stimulus while minimizing stress on the students. I choose, build, and curate activities that meet the stimulus-to-stress ratio I want, and I assign those at the end of the class prior to the one where I want the students to know these things.
Those italicized items in the lesson plan indicate work the students should come to class having already done, so they’re ready for the activities ahead.
You also see a ton of group work in the above lesson plan. In the next piece of this series, I’ll talk specifically about group work.
If you liked this Q&A, you might also like:
The three-part series on teaching a programming course
The behind the scenes series
The leveling-up series on advancing your own skills (which will soon be an audiobook read by yours truly. Preorder here).