Core − Foundation ≠ 0

One of the surprises to me as we did the curriculum redesign, but one that made sense on reflection, was that there was consensus that some topics were core but not foundational. There were items that some thought were core and others did not, but there were also items most agreed were core but still not foundation. For example, computability theory was something we agreed that every CS graduate should know it, but had no courses that relied upon it in anything more than the loosest way. Partly this was because the topics that depended on it were at the graduate level: we were teaching it as a prereq for students future grad studies, not for our own courses. Partly this was because understanding theory provided useful perspective and attitudes which streamlined many topics but were not directly needed for any one of them. Partly it was a recognition that computability theory is part of the canon of ideas in CS.

Because we teach one topic at a time, one of the important topics one must be last one we teach and thus not foundational to any other. To limit the core to the foundation would be to require some elective after each and every core topic, which is not usually a reasonable constraint on a curriculum.

Foundation − Core ≠ 0

There are also topics that we identified as foundational, important as a prerequisite to many other courses, that we did not feel were core. Generally these were enabling technologies, used not because they were interesting (at least at the level of detail we were using them) but because they enabled something that was. Some examples we decided we didn’t need to teach, like the ability to type or speak English; others we decided we did need to teach, like the ability to navigate the Linux command line or speak SQL.

The non-core foundation often had a level of choice. We had courses that required students to know some large-scale programming language; it was up to us which of more than a dozen candidate languages to pick. We had courses that required students to be able to use some database; it was up to us whether we taught them a relational database, object database, or graph database. We had courses that required students to know the developer tooling in some operating system; it was up to us which OS we used. And so on.

Foundation isn’t intrinsic

There are many pairs of topics that have enough overlap or cognitive relatedness that teaching one before the other lets the second one be taught more easily. We often encode these as prerequisites, or if within a single course by the order in which they are taught.

However, the order part isn’t as fixed as I initially thought. Often, you can switch the order and still make a useful prereq in the other direction. Doing this requires a change in the curriculum, which isn’t necessarily easy to design, but the longer I spend in curriculum design the more convinced I become that many different orders can work.

Because of this mutability, I’m starting to doubt that anything is intrinsically foundational. What seems like the foundation under one teaching model turns into the capstone under another, and vice versa. When I was starting out as a teacher and noticed topics that could be reverses it seemed like a major discovery, an interesting special case in the curriculum. A few years later I thought that the curriculum was about half-and-half topics you could swap the order of and topics that had an intrinsic best order. Now I’m beginning to doubt there are any you couldn’t swap around if you wanted.

That said, there is need for consistency in ordering if you want many instructors to work together on a degree program: you need a foundation, even if the blocks you put in it are somewhat arbitrarily selected. There are also topics that are more central, related to more other topics than most, and making those the foundation can decrease the depth of the prerequisite chain. But when someone says you can’t learn X until you learn Y, they usually actually mean I’m not prepared to teach X to people who don’t know Y rather than any intrinsic ordering in the ideas.

Required Electives

Most degree programs that I’ve encountered include some required courses and some electives. Electives provide the learner some agency in choosing what they learn, but being required to take some electives without being required to take any specific ones is not an obvious educational choice. Be definition, we’re happy graduating students who didn’t take each course in the set of electives so why do we need to have students take any of them?

Some electives form a set that any member of provides the thing we care about. For example, at UVA many of my students were required to take at least one second writing requirement; each of these courses covered a different topic, but all discussed a topic in enough detail to require a medium-length essay about it, which was what motivated this pool of electives.

But many electives have a less well-defined goal of making a student well rounded or giving them breadth or building their perspective. For example, in CS degree programs it is common to require 4–6 upper-level CS electives which may have completely disjoint topics with unrelated assignment structures and so on. Part of the motivation for this is the desire to have every student see the foundational knowledge from the required courses used in several disjoint situations, resulting in a perspective about what is essential and what is incidental that we don’t know how to teach directly.