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 and, in particular, the United States, the University has wisely elected to run all of the spring courses online.
So in this post, I’ll show you how I’m getting from the lists of concepts and skills I showed you last time to specific topics for a session.
A Recap: Deciding What to Cover
I wanted a course that would help computer science students develop the technical and intellectual skills to become effective software engineers. I wanted these lessons to apply to many stacks (not just mobile stacks), but I wanted to use mobile stacks as my examples.
How did I get from that highfalutin’ goal to “OK, what should we cover in this class?” Here’s the technique I used, which I described in more detail in the last post:
I wrote a list of things I’d like the course to cover and color-coded the list into three groups:
- Skills (specific programming practices and ideas)
- Concepts (general frameworks to help students think about building robust software)
- Context (broader software engineering topics for sparking discussion and building professional awareness).
That post shows those three color-coded groups on a piece of notebook paper. I copied them all onto post-it notes that I could easily move around, and I started sticking the post-its on a laminated foamcore poster that I had lying around. The poster allows me to move my “draft syllabus” between workspaces, like my desk, the floor, and the wall. On it, I clustered the post-its into groups that represent different sessions of the class. I can move the concepts between the different sessions as I get a better idea of what I want to cover, and in what order:
Defining a Critical Path through the Material
Next, I needed to get more specific about how to teach these skills, concepts, and context. This class uses mobile APIs as a substrate upon which to build software engineering skills—to discuss how to derive joy, and challenge, and rigor, and quality, from what we produce as programmers.
Unlike the iOS Development class, which aims to cover as much of the iOS API as possible, for this class I need the critical path through a mobile API that will touch on:
- programming language design
- evaluating program design
- UI design and UI flexibility
- programming paradigms (both imperative and functional)
- HTTP Connections
- Object storage and data privacy
- testing, debugging, and version control
I have worked on iOS apps in ride sharing, health insurance, voter engagement, and citizen science, among other things. Each of those apps were different, but they all required some kind of list-detail flow. What’s more, every app I have worked on—from Android to the web and back—has had a feature with a list-detail flow. So some kind of list-detail app makes sense for this course.
I fired up XCode and got to work on an example list-detail app. Pretty quickly, I was about 450 pages deep into Simon Ng’s book, Beginning iOS 13 Programming with Swift, and I had my example app: Angry Birds*.
*Not the game where you slingshot cartoon birds at cartoon pigs. My app, instead, showcases a list of birds. The birds look angry. That’s it. That’s the app.
This functionality should be sufficient for students to grapple with all of the above concepts—without being so much that they lose sight of those concepts in a desperate dash to crank out features.
Determining Order
The syllabus for this class is brand new, so there are no precedent runs from which I can determine how fast I can expect the students to move through the material. In fact, even if we did have precedent runs, they would hardly apply to this quarter: the whole school is remote for the first time ever, many students are caring for children and parents while sheltering in place, and the quarter started a week late to manage the adjustment—which, in a quarter that customarily has only ten weeks to begin with, means that this class has ten percent less class time than a class during a normal quarter. In essence, I cannot reliably predict how much we’ll get through in each class.
I’m an engineer, though. We face this problem all the time. Engineers (and product managers, and designers, and business people) all really suck at estimating how long projects are going to take, especially when they contain unknowns. We mitigate this by putting the highest priority stuff first in the backlog. Wherever we get cut off, we can be the sure that we saw to the most important things on the list.
It’s similar for this class. I move the post-its around to group the ones that are related to each other. Then I take the first, say, ten, and I build a lesson plan with that. Ten seems like an overestimate of what I’ll get through in Session 1, so I know I’ll have enough material for the full session. That session will give me an idea of how fast we’re going to move. And when that session is over, I’ll take the leftover post-its that we didn’t cover, plus the next group of ten, and plan session 2.
In the next post, I’ll dive deeper into how I get from those ten post-its to a lesson plan.
If you liked this piece, you might also like:
The rest of the posts about teaching and designing lessons
The leveling-up series on advancing your own skills
The series on reducing job interview anxiety