During the dry years of this blog I engaged in various activities. Too many too list here. One of those was helping redesign the required CS courses at UVA; I’ve written and presented various parts of that elsewhere, but wanted to post four ideas here.
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 content11 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.
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 prioritize22 e.g. IDE debugger or CLI debugger or both? and what specific competencies in each to expect33 e.g. is sed
s
. Implementing the resulting spec also revealed that there is a lot more to teach than we thought: it is true that all the things s///
pattern enough, or do we also teach //
and y///
?ls
can do fit in a 1000-word manual page, but all the things we do with ls
could take multiple days of instruction.
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:
On Trusting Trust44 Ken Thompson, Reflections on Trusting Trust, August 1984, Communications of the ACM 27(8), pp. 761–763. doi:10.1145/358198.358210
malloc
s 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.usably secureclause of the ACM code of ethics item 2.9
It’s About Power66 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.
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:
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.