Anti-co-requisites
I’ve been attending a training bootcamp for new student advisors in my department this week. The bootcamp has been both educational and humbling; it is impressive how much our advisors know about our program that I, as a faculty member who teaches in it and sits on the committee that designs it, do not. There’s little to put in my blog about what I’m learning, however, because I don’t know enough about it to expound on it; but there was one point made on the first day that I do know quite a bit about and want write about here.
Our advisors had noticed three pairs of courses that they advised students not to take in the same term. If students do take both courses from one of these pairs in the same semester, their expected grade drops significantly. Given that we call courses that should be taken concurrently co-requisites
, these courses could be called anti-co-requisites.
The advisors also know that all six courses in these three anti-co-requisite pairs have a reputation for requiring extensive out-of-class work. But that alone is not enough to describe the anti-co-requisite relationship; courses from distinct pairs are often taken concurrently without undue difficulty. There’s something about the courses themselves that makes them hard to take together. But how could that be? What could make courses into anti-co-requisites?
I don’t have any solid evidence to use in answering this question, but from my experience designing and teaching courses and degree programs, I do have some hypotheses.
One type of anti-co-requisites that I have fairly strong evidence does exist I will call mutual prerequisites.
In these courses, the order you take them in is not important but whichever one you take second will be easier than whichever you take first.
In the cases that I’ve seen of this, both courses rely on a similar student attribute11 Often a less-direct attribute like perspective or attitude, as discussed in post 741 which students develop in part by being given a series of tasks that rely on it, rather than by more direct instruction.
At UVA, we saw this with our proof-using classes. We had two courses that had proving properties of machines or code as a significant part of the course but had no direct relationship between one another. Students who took them one after another received better grades in the later course, while those who took them concurrently received poor grades in both. We eventually made one a prerequisite of the other, with familiarity with a variety of proofs
as the articulation point, allowing the first to move more slowly for students with less proof experience and the second to move more quickly by assuming more proof experiences.
Computing courses often have programming assignments that are expected to take a student a week or two to complete. Students often find it difficult to estimate how much effort these will take, and many students work on these in a few lengthy sessions rather than a uniform spread of smaller effort. As a consequence, if the deadlines of these assignments in multiple courses align, many students find that pair of courses more stressful and difficult than otherwise.
This is, in some sense, and entirely arbitrary problem with many possible fixes. Students with better time management skills find this problem to be small22 In addition to other benefits; see the post Easier Yesterday. Adequate messaging and can reduce student procrastination and misjudging time. Requiring partial-solution milestone submissions can reduce students’ all-at-once scheduling tendencies. Moving deadlines can cause courses to no longer overlap their busiest days.
However, none of these solutions is without cost. Time management is hard to teach. Messaging about the importance of starting early only works if it is unusual; if it’s frequent students ignore it. Milestone submissions usually require providing students enough design that the milestone functionality can be defined, which can remove some of the design experience and freedom that some assignments are designed to exercise. Deadline motion is constrained by the common pace of a semester, and removing a deadline conflict with one course can create one with another course. While specific timing-based anti-co-requisites can be mitigated, removing them entirely from a curriculum is very challenging.
It is common for courses to use similar tools in different ways for different purposes. Most of the courses I took as a student used arithmetic and algebra, for example, and I can’t recall ever getting thrown by that and applying on course’s concepts in another course just because the math was similar. But that was because by the time I took those courses I had a very solid handle on math; it was by then just a tool, not a topic of significant thought in and of itself.
When I took my first course in C and my first course in Java, I had a very different experience. Many things about those two languages are similar: most of the syntax, many of the data types, most of the operators, and so on. But these were new to me, they required active thought. I would pay attention to writing code that could be either C or Java, but then reach a point where the difference mattered and my mind would take the wrong fork, then realize it had and second guess everything I’d been doing up to that point, an stress, errors, and inefficiency would ensure.
I think of this kind of anti-co-requisite as partial parallelism. There are two courses, the topics of which run in parallel, reinforcing one another; but only do so in part, with enough divergences to throw students off.
I had one experience with removing this kind of anti-co-requisite by reordering the topics in the courses in question. When Mark Florian and I were co-designing DSA1 (a first course in Java) and CSO1 (a first course in C and assembly) as part of UVA CS’s curriculum redesign a few years ago, we decided to put the Java language in the first half of the semester and the C language in the second half. I taught the C language as what if we tried to wrap assembly in a Java-like shell
and he taught the nuances of Java’s operations as because under the hood it’s all assembly so we get all of assembly’s oddities;
the courses thus went from being anti-co-requisites to being recommended to take concurrently because the parallelism was recognized and designed around.
In my experience, that’s an unusual case. We were given significant time away from other tasks to remove that anti-co-requisite, and were lucky in what was in our shared prerequisites and how much time we needed to spend on the partially parallel parts that we could design around it. Most of the other times I’ve been around one that time and focus and curricular flexibility was not available and partial parallelism was a more fixed source of anti-co-requisite.
We could argue with the correctness of this model, but it is the dominant model for child and young-adult education across most of the world, and has been for centuries. One of the strongest evidences that this is a good model that I’ve encountered is its correlation to anti-co-requisites.
Students seem to benefit from variety. When I advised students33 At UVA I was an advisor and faculty member; at UIUC we have professional advisors instead. I found that students who took on too many similar courses generally either dropped some or struggled. And this wasn’t really so much about topical similarity as it was about work similarity. Taking four classes about cybersecurity where one had math-oriented homework, one ethical reasoning papers, one assembly programming, and one web programming went fine. Taking four classes about unrelated topics that all had C++ coding assignments went poorly.
I experienced this myself as a student. When I would tire of trying to untangle obtuse texts it was nice to switch to struggling with a proof or banging my head against a debugger instead. These were all mentally tiring, but in very different ways. But in the semester where all of my classes involved the same kind of coding frustrations I almost cracked, spending much longer on each task than was my wont because I was worn out and inefficient at them.
I know of no way to resolve this type of anti-co-requisite. Once course topic and approaches are selected, some have enough intellectual effort overlap to be unwise to take concurrently.
The existence of anti-co-requisites can be readily demonstrated by comparing the drop rates and grade distributions of those who take them concurrently to those who take them sequentially.
That anti-co-requisites are about more than workload can be demonstrated by showing that courses from distinct anti-co-requisite pairs do not exhibit anti-co-requisite-like drops or grades.
Testing the hypotheses about why they are anti-co-requisite is much harder. A major confounding factor is that the measures I’ve suggested of anti-co-requisite-ness only manifest if a student’s overall course load is difficult and time-consuming. When I took anti-co-requisite courses my time invested and personal stress rose significantly, but I had the time and energy to compensate for that and there was no visible impact on my performance. The obvious way to test if one or another course design decision contributes to its being an anti-co-requisite is to change that decision, but doing so might also change the overall difficulty or time needed by the course, hiding the impact on the topic in question.
I personally believe the hypotheses I’ve given here. But I also acknowledge that my belief is based on the plausibility of the hypotheses and a small number of personal experiences which could be anomalous. I hope my thoughts about them may be of some benefit to students, faculty, and advisors even before experiments to verify or refute the hypotheses are performed.