The everyday blog of Richard Bartle.

RSS feeds: v0.91; v1.0 (RDF); v2.0; Atom.

Previous entry. Next entry.

5:58pm on Monday, 28th November, 2011:

Marking Time


Over the course of my travels last week, I managed to mark the bulk of the CE217 assignments that were handed in the week before. I did the last one on Sunday. Free!

Well, free of CE217. The CE317 Lua assignment was due on Thursday and I have over 40 of them. They take over an hour each. I managed 3 today (a day when I have no teaching) so I don't expect I'll be finishing them by the 2-week deadline we're given. As I'm only half-time at the university, in theory I should have twice the time to mark them (in computing terms, my execution time should be the same as for everyone else, but my elapsed time should be double). I'll have to mark a bunch of interim reports next week, too.

The CE217 assignment has a very strong marking scheme. I give it to the students, they do that hit-the-marking-scheme thing that they were taught at school, and the end result is an average of (in the ones I just marked) 64%. This is 10% less than most of them have been trained to expect, but in line with what they can expect for their examination.

The CE317 assignment, on the other hand, has no formal marking scheme. I basically want to know how well they can program in Lua, but they tend to have different idiosyncrasies. I can hardly give them a mark scheme that says "use of for loops instead of while loops" or "not putting things like if x ~= false". I can't even say general things about control or data structures, as they have cunning ways to mess those up, too. If I said "no repeated chunks of code" they'd do things like put in extra spaces and change variable names so the code wasn't (in their view) repeated. As it is, "put in comments" is often interpreted as "say that outputresult() outputs the result".

By not providing an explicit mark scheme, I can do a kind of parallel marking: if they do something right, that can sometimes account for their doing something wrong. For example, if their program doesn't work then that would normally be a seriously bad thing and would feature largely on a mark scheme; however, if the reason it doesn't work is because of some small mistake in an intelligent addition they made that went beyond the specification, well, they should probably get more marks than someone whose program only works because there's so little of it.

This way, from the students' point of view, it's as if I'm marking out of 120 — they'll end up with more marks than if I marked out of 100. They just have to wait weeks to get the feedback...

Latest entries.

Archived entries.

About this blog.

Copyright © 2011 Richard Bartle (richard@mud.co.uk).