Critique-based Assessment

I said that in my programming courses (and others), I'd rather critique than grade, because grades are such a bad idea.

[And I'm not alone. Alfie Kohn's nice post references similar criticisms as far back as 1933!]

But schools want grades, and therefore so do students, so how do I assign grades at the end of a term?

Here's how my critique-based courses work. Instead "do it once, get a grade, repeat," the process is "do, review, re-do until mastered, then move on." More specifically,

• Students select and work on assignments (exercises, projects, ...).
• Students submit their best solutions to each problem.
• I critique each solution, pointing out weaknesses and areas for improvement.
• Unless the critiques are non-trivial, the student needs to re-do and re-submit. This happens for most initial submissions.

Quite quickly students begin separating out. Some zip through the early easy stuff, some need a lot of tries to get the basics down. In a standard course, the latter students would be forced to face more and more complex problems with incomplete skills, while the former students would be bored waiting for the challenging stuff.

At the end of the term (and usually at one or two mid-points), I calculate grades based on

• progress, as measured by the number, range, and complexity of assignments completed to this point,
• mastery, as measured by the lack of serious basic critiques in the solutions initially submitted, and
• effort, as measured by the number of submissions and re-submissions.

During the course I get to focus on what I care about: what problems are students having and what advice should they be given. There's no repeated reduction of wildly different points into singular point values. As a bonus, I get a detailed current picture of what students are having the most trouble with.

When I describe this to other faculty, the usual response is "whoa, that must take forever!" Indeed, without some kind of tool support, it would not be feasible to give detailed feedback like this to a large class, and it would be very time-consuming and error-prone to review and evaluate each student's history of interactions for an entire class.

Fortunately, we have the technology. Next time...

Critiques, not Grades

When teaching programming, I critique code, I don't grade it. Despite their ubiquity, grades have many problems. In no particular order, here are some big ones:

• For any solution complex enough to be worth evaluating, a single number is way too inadequate a measure of quality.
• Calculating a weighted average of inadequate individual grades to get a final grade makes things even worse.
• Who would you rather have working for you: someone who got 5 programs 80% done, or 4 out of 5 programs 100% done?
• A grade provides no useful feedback to the student on what was wrong and how to do better.
• Grading requires repeated arbitrary decisions about the relative demerits of misleading function names, bad indentation, failure to use standard library functions, and so on, when all I really care about is whether is something worth fixing or just noting.
• The students tune their behavior to optimize their grade based on whatever arbitrary rules I developed.

But if I don't grade, only critique, how do I figure out a final grade? Next time...