Less is More

The first of several major changes we made to the CS curriculum was a revamp our introduction to programming course. And by revamp I mean we removed half the course’s content¹¹ In particular, we removed: static typing, classes, inheritance, and compilation. These had previously been 7 of our 14 weeks of instruction. and don’t replace it with anything. We moved what we removed to other classes, removing content from them too to make room.

End result: happier students, happier teachers in that course, and happier teachers of down-stream courses. The first two were no surprise, but why were instructors of later courses happy that students had seen less material? Because they had seen more of that lesser set. A solid knowledge of functions and loops was more helpful that a weaker knowledge of functions, loops, classes, and types, and it led to a more solid knowledge of classes and types when they came along in a later course too.

Although less dramatic, we found similar outcomes in other courses. Removing content was always a net win. Obviously it won’t always be a net win: there are things worth teaching. But it appears that most professors’ instinct is to teach more than is optimal, so cutting some of what we pick is generally wise.

Teach the Tools

When we reviewed our curriculum, we found that there were many tool proficiencies that later courses assumed but earlier courses didn’t teach. These were seen by the teachers of early courses as intellectually uninteresting, but by teachers of later courses as important to know. Our default practice was to have a few light-weight do-on-your-own tutorials and hope students would figure out the rest on their own. But it was clear from complaints of teachers in later courses that that approach was not working.

Our solution? Add tool proficiencies as official learning outcomes of required courses. Doing this resulted in interesting conversations about which tools to prioritize²² e.g. IDE debugger or CLI debugger or both? and what specific competencies in each to expect³³ e.g. is seds s/// pattern enough, or do we also teach // and y///?. Implementing the resulting spec also revealed that there is a lot more to teach than we thought: it is true that all the things ls can do fit in a 1000-word manual page, but all the things we do with ls could take multiple days of instruction.

Context in Context

I have found that if you ask faculty in technical fields about ethics and societal context, they’ll generally both (a) say its important and should be taught and (b) say their classes aren’t the right place to teach it. I said this myself more than once. But stand-alone courses on these topics rarely have a good reputation.

To help rectify this, we asked the committees designing each course what social and ethical issues are relevant to this course? Usually that question resulted in initial silence, but the one and then another topic would come up which were either particularly important for some technical topic in the course or easily illustrated using content in the course.

Taking the two courses on systems programming and computer organization which I helped pilot as an example, we included the following:

• After teaching students to build a simple processor we demonstrated how to add a backdoor to the processor circuitry, then discussed On Trusting Trust ⁴⁴ Ken Thompson, Reflections on Trusting Trust, August 1984, Communications of the ACM 27(8), pp. 761–763. doi:10.1145/358198.358210
• After running into challenges with getting all mallocs to pair with a free and introducing memory checking mode in compilers, we discussed how the debugging hooks the memory checker used was a good kind of backdoor, then had a class discussion about when adding a backdoor is ethical and when it is not, and discussed how that motivated the complex wording of the ACM code of ethics item 2.8.
• After an assignment where students had to make their code from an earlier assignment robust to various kinds of incorrect input we discussed the relative effort needed to implement vs harden vs prove safe⁵⁵ we used seL4 as an example of proof complexity as they’d not experienced that yet: Klein, Elphinstone, Heiser, Andronick, Cock, Derrin, Elkaduwe, Engelhardt, Kolanski, Norrish, Sewell, Tuch, Winwood (2009) seL4: Formal Verification of an OS Kernel ACM Symposium on Operating Systems Principles pp. 207–220. and why we might chose to deliver mostly-functional code now vs quite-safe code much later, including how this conflict is encoded in the usably secure clause of the ACM code of ethics item 2.9
• After mentioning power as a separate thing we could optimize processors for instead of speed we discussed the environmental impact of computers.
• After discussing the scale of the command-line and discussing how hard it would be to ever compress that into a GUI we discussed power-user interfaces generally and the inequitable power allocation that is intrinsic to all engineering, using It’s About Power⁶⁶ Sepehr Vakil and Jennifer Higgs. 2019. It’s about power. Commun. ACM 62, 3 (March 2019), 31–33. doi:10.1145/3306617 as a framework for the discussion.

I could go on, but hopefully this is enough to show that there are ethical and social contexts that are both directly related to and easily discussed in the context of technical topics. Whether this approach will prove to be a winning approach or not remains to be seen, but it was positively received in our initial piloting of the courses.

Classes with a Story

Students are motivated by many things. Deadlines and grades are the easiest of these motivations to use, but tends to make a class that is not very fun to teach or take. Personal interest, either existing before the course starts or developed through the instructors’ contagious enthusiasm and fascinating examples, makes for enjoyable classes but is not easily created. I found a nice middle ground to be a story to go with a class.

I was asked to design and pilot two courses which had topics lists containing many things most students traditionally did not have much personal interest in. Assembly, memory management, caching, virtual memory, synchronization: these are topics that are so far from popular that languages are built to conceal them and some schools don’t teach them. How was I to make the courses work? By telling a story.

I looked for a story for each course that was short, a sentence or two in length; that could explain why we were doing each part of the course; and that could be understood before the course content was. These were the stories I came up with:

• Nothing is magic: from electrons to programming languages is one understandable topic on top of another. Understanding those steps isn’t just for fun: it’s the physics behind our engineering and helps you understand why computers are the way they are.
• The quest for faster hardware has resulted in sensible, usually-invisible decisions that occasionally do things you never expected. Understanding those decisions helps you write code that outperforms your competitors and mitigate security leaks.

Once I had these stories there was work to do: topics needed to be reordered, examples changed, lectures revised so that everything supported the story. But it was worth it: students understood the place of the topics they didn’t find intrinsically interesting and gave me their attention without my needing to force it. And that made teaching the classes much more enjoyable than otherwise.