Peer Grading Guidelines

As we've mentioned in class, you're going to be grading one another's assignments. Learning to read, evaluate, and test other people's code is an extremely important skill for any programming you'll do as a part of your job, be it in industry or academia. If you're a novice programmer, you'll get the chance to see how more seasoned programmers attack various problems, and pick up a few tricks. Even if you're old hat at this, I can virtually guarantee that you'll learn something by thinking back through the basics, or explaining why something isn't working in simple terms. Plus, you'll get much more feedback from your peers than we'd have time to provide on every single assignment.

Send what where?

First, let's go through the mechanics of how we've set this up. Here's how the system will work:

• Grading assignments for the whole quarter will be posted on the course wiki. Additionally, you'll get two emails shortly before each homework is due -- one telling you who you're going to be grading, and the other telling you who's grading your homework. In particular, their email address will be in this -- we don't want to post a list of everyone's email on the course webpage, for obvious reasons.

• By the beginning of class on the day homework is due, you should submit your homework via email to your assigned grader. Just to be safe, you might consider cc'ing [email protected] on the email, just in case you run into any trouble with your message getting to their inbox.

• You have until the beginning of the next class day to actually get the grading done. (This may sound like a fairly intense schedule, but trust me, you don't want to let grading hang over your head. I speak from experience.) You should send an email to [email protected] and the person whose assignment you're grading, which contains a copy of their assignment, and your comments. (More on your comments below.)

So to summarize:

• homework to your grader on due date
• graded assignment to us by next day of class

How should I grade?

First and foremost, let me say: your goal as a grader should be to provide as much useful, constructive feedback as possible. We're going to have a simple grading scale for each problem: everything gets either 2, 1, or 0 points. For the record, we're not trying to meet any "curve" here -- we'd be happy to see most students get full credit on most of the problems they do, as long as they're actually correct.

• 2 points: Everything is basically right on the money, and works correctly. If there's some really minor corner case that doesn't work, but that's the only thing that's wrong, it should probably still qualify for full credit. If everything works, but it's ugly, that's okay -- we're not grading on style. That said, style suggestions are exactly the kind of thing you should offer as a grader, if you can.
• 1 point: On the right track, but they missed something significant. A vague guideline would be this: if you notice that they missed something noteworthy, but you think it would be easier to fix their code than to just throw it away and start over from scratch, it's probably a 1.
• 0 points: Way off. Basically, if you'd rather just start over from scratch than try to fix what they wrote, it's probably a 0.

An important note: you should be able to back up any claims about their code failing to function with inputs that demonstrate the bad behavior. So if you say "this goes into an infinite loop sometimes," you need to back that up with an example of input that goes into an infinite loop.

Are we graded on our grading?

Yes, you are. We're going to glance over the comments you make, and we're looking for a few things:

• Did you actually read and try out the code?
• Do the comments say something useful?
• Do you back up claims about things being broken with bad inputs?

Basically, we're going to look and make sure you took the time to grade carefully.