Hi. I’m Chelsea Troy. I’m a computer science educator at the University of Chicago. Somebody at the University elected to entrust me with presenting a sample lecture to admitted students for the Master’s Program in Computer Science (MPCS) and the Computational Analysis and Public Policy (CAPP) programs. I cannot imagine why they did this, but I’m humbled and honored to represent the…phoenixes? Is that what we are? (UPDATE: We’re the Maroons, evidently. Look, people, I’m not an alum.)
The Task in Five Parts
Come up with:
- something engaging for experienced programmers,
- but accessible for non-programmers,
- that showcases the education we provide at the program,
- preferably with interactive components,
- with a runtime under an hour.
I failed at that last metric, coming in at sixty-one minutes. I’ll let you judge the other metrics for yourself.
The Topic: Analyzing Risk in Software Systems
Once I understood the audience, I knew I wanted to use some version of “the risk lecture.” It consistently gets name-dropped when I ask students which lectures helped them the most in their interviews or in their jobs. The problem: as designed, the thing takes a minimum of two hours to run (check out this recording of the full-length workshop that I adapted for practitioners at a professional conference).
In the sample lecture, I didn’t have that kind of time. So I took a look at the original workshop: what takes time about it? Well, we spend a ton of time analyzing risk in small groups, and we spend more time reconvening to integrate the groups’ work into a larger whole. It’s a good system, if you’ve got the ticks, but we don’t.
So I made an adjustment. Instead of breaking the audience into groups of four like I normally would, I decided I would have all of them simultaneously annotate the same document with their perceived risks and risk amplifiers. Estimated audience size: fifty. We were gonna do this with fifty freaking engineers.
I probably had enough time to test this approach, but what I didn’t have were fifty engineers. So I had to do some defensive design, come to class with backup preparations, and hope my plan would work.
Some days later, after I got hold of the recording, this is what my colleague said of the group risk analysis:
“I watched that part slack-jawed.”
– Esteemed Colleague
Did my colleague mean that he was witnessing a miracle or a total disaster? WATCH THE VIDEO AND DECIDE FOR YOURSELF!
Why am I showing them google search results for parrots? You’ll have to watch the video to know. Why did YouTube pick this particular 10 seconds of the recording as the thumbnail? That’s a mystery to all of us.
In pulling off this harebrained scheme, I’m pretty sure we performed the largest simultaneous software risk analysis ever done. Does NASA put fifty engineers on one risk analysis? Does LifeAlert? Do I actually think this is some kind of proxy metric for risk analysis quality? No, reader, I do not. But it’s fun to think about.
I do one other thing to shorten this presentation from its original length: I stop early. In the full length version, there is a longer lecture portion associated with mitigating and alleviating risks, plus a third group activity. That part of the workshop assumes prerequisite knowledge of things like automated testing and server region redundancy, so it didn’t pass the “accessible to non-programmers” requirement anyway. If these students want part three of this workshop, they’ll have to come to school.
Anyway, I hope you enjoy watching this sample lecture as much as I enjoyed preparing it.
Oh, and that image of the scarlet macaw that didn’t display on my slide? Here she is.
If you liked this piece, you might also like:
The time I talked about what counts as a programming language in front of an audience of programming language designers. I strategically saved this talk for a pandemic-era Zoom conference to eliminate the possibility that they’d actually throw tomatoes.
The Raft series, of course! Learn to implement a distributed system from the comfort of your home, complete with gifs and smack talk!
Lessons from Space: Edge Free Programming—about what launchpads have in common with software, and what that means for you and your work!