Even with small classes, grading homework or exams is time-consuming if you want to offer detailed written feedback or critique. Though I’m not averse to red ink, I have always disliked the impersonality of checks, slashes, or other symbols of “correct” and “incorrect.” There are degrees of correctness and incorrectness, and I wish to be more helpful and guide students toward understanding. I also believe students are more likely to develop a conscientious approach to learning if they realize I am personally interested in their progress.
The urge to inform students of exactly where and how they went astray is to resist. But as we all know, written feedback tends to be offered more liberally on papers near the top of the stack. And there is the possibility that a significant percentage of the papers feature the same error. The first few times I see that error, I might respond with written feedback, but at some point I realize I may have to write the same paragraph twenty times. Finally, in many cases the same lack of understanding or mastery that caused them to err on a problem also prevents them from comprehending my feedback.
To maximize the quality and quantity of feedback given, while minimizing the inefficiency (and occasional waste) of delivering all this feedback by hand, I’ve developed what I call feedback codes. These are lettered abbreviations appearing on student papers courtesy of my red pen; a separate handout provides the translations, which I only have to type out once. Some codes can be applied across all courses; some I’ve designed for particular courses. Here are samples of generally applicable codes and the translations I provide to students:
IDF: This stands for “I don’t follow.” But what it really means is, “You’re not being sufficiently clear”, or “You haven’t argued this in a comprehensible manner.” In other words, perhaps I do indeed “follow” to some extent; maybe I see what it is you’re trying to say. But you need to think about why it is that what you actually said is less than clear.
IMD: Include more detail. Your work appears to be technically correct but leaves out one or more steps which readers should see. NS: This stands for non sequitur, a Latin phrase meaning “does not follow”. For example, “I like pecan pie, therefore, it will rain today.” The conclusion is not a logical consequence of what precedes it. You should think about why what you wrote down is a non sequitur.
NP: “No penalty.” Sometimes I may object to something incorrect you wrote down, but there is no penalty because it deals with some issue not germane to the concept being tested, or because it has no negative impact on your solution to the problem. So NP means that that part of what you wrote did not affect your score adversely. Whatever points you lost were due to something else. WWTN: “Where was this needed?” Usually, all information given in the statement of a problem is actually essential for a valid solution. So if you have what you allege to be a correct and complete solution, but there’s some piece of information you never used, I might circle it and put WWTN. The message is that you should have noticed you never incorporated that information… and that should have made you suspicious of your work.
CTAE: “Clue to an error.” Sometimes your “final answer” could not possibly be correct, but you don’t notice because you didn’t take the time to interpret your own results. For instance, suppose you are asked to find the volume of something and it requires computing an integral, and according to your work the value of the integral is negative. Well, then… how could it correspond to a volume? That is your “clue to an error” somewhere. Or let’s say you are supposed to sketch the graph of a function, and according to your sketch, the graph has two points where the tangent line is horizontal. But according to other work on the page, there is only one value of x where f' (x) = 0. That inconsistency is your CTAE.
The examples can be modified to refer to some other sphere of assumed knowledge. Here are a few codes I use specifically in Matrix Algebra, where certain errors in terminology, notation, and operations are especially common:
CM: There is no such thing as a “consistent matrix”. The terms consistent and inconsistent apply to linear systems, not to matrices.
DM: There is no such thing as division by a matrix.
DO: You have different objects on the two sides of this equation. Perhaps one is a scalar, the other a vector; or maybe one is a vector and the other is a matrix. But the objects don’t match; they are of different type.
MB: You don’t mean multiplied by; you mean dotted with.
NC: Matrix multiplication is not commutative; that is, the order in which matrices are multiplied matters. Switching the order of the factors may change the result.
NS: This matrix (or these matrices) is/are not given to be square, so we may not assume that.
PV: There is no such thing as the product of two vectors.
My students first see a code key when I return their first assignment. This is when they form their first impressions about the quality and style of feedback they can expect to receive. New codes can always be added as you think of them later, and you can just provide the students an updated key.
The codes have two side benefits. They free up time to include more personal handwritten comments. In addition, my students have told me that the Matrix Algebra codes help to prevent the kinds of errors they address. My students often consult the key and make corrections and revisions before turning in their homework.
Time spent: One hour per course designing codes and their descriptions/translations (most of which can be reused in the future).
Time saved: Fifty students per semester is typical for me, and I do all grading myself. Each student completes 12 homework assignments and 4 exams, and feedback codes likely save, on average, one minute per paper. Total time saved comes to at least 13 hours per semester.
If you have large enrollments, and teaching assistants do most of the grading, feedback codes could be useful to help save them time. You might prefer to create a single code key for everyone’s use, as this could improve the consistency of the grading and give your TAs insight into your expectations, for them and for the students.
John Tolle is an Instructor in the Department of Mathematics and Geosciences at Penn State DuBois. You can reach him at firstname.lastname@example.org.
Teaching Time Savers Archives