What NOT to Do in a Programming Class...

... assuming your grade matters to you.

Why care at all

Ok, so this is going to be a bit cynical. I've heard all this high-profile rhetoric for quality education that makes a lasting impact on society. This is an abstract vision of education, to which we all aspire. However, when the nuts and bolts start moving, it might not all be that smooth.

From students' perspective, the best way out of oddities of the educational machine is to avoid them. One of the biggest bullets to dodge is inadequate grading that destroys motivation. Below is my understanding for the reasons of inadequate grading and simple tips to avoid most of it.

I take the context of a programming class to be more specific.

Why it happens

To understand why grading is never perfect, we need to look at it from a TA's side. The grading TA's goals are: to finish grading (a) as quickly as possible (b) with a reasonable average and a sufficient variation of grades and (c) with as few objections from students as possible (precision and consistency). Notice that there's nothing here about absolute perfection.

So it is the traction between the ideal abstract educational vision and workflows of TAs that produces singularities in grading.

The bulk of programming assignments are carried out and graded off-line, with little to no interaction between a student and a grader. In this situation the opinions of a student and a grader can part ways in many fashions:

• Underspecified assignments, resulting in either too different implementations or a lack of discriminating factors.
• Inability to clarify aptly (applies to both sides). 
• Assignments with internal inconsistencies (e.g., conflicting goals).
• Judgment-based assignments (known to start with "Design a...").
• You name it. 

When one of the above happens, TAs are not very likely to interpret it your way. Also, if they can find an easy error, they would do it, rather than proving a complicated error to you. Remember: TAs want to be done with grading ASAP, hopefully having done decent job. But not vice versa.

How to avoid sharp corners of grading

Now you've made it to the most useful part of this post.

What NOT to do in a programming class homework:

• Answer questions with rambling paragraphs and fuzzy thoughts.
• Commit files to wrong directories.
• Violate file/class naming directions (this screws up scripts and frustrates everyone).
• Admit your own mistakes up-front (you're not in a court, this will not halve your sentence).
• Be late with submissions (always submit a semi-working version before a deadline and proceed with caution).
• Screw up formatting/encoding.
• Fail to mimic the resemblance of code comments (of course nobody will read those, but it's a good habit to have).
• Forget to put startup instructions for a set of applications (graders start digging your code, which is never good).

If you feel something is going to be used against your grade, argue consistently and unemotionally up-front. If a dirty trick has been used against your grade ("your UI colors are messed up, and I cannot read labels"), shoot a couple of emails to the TA and appeal to common sense ("I couldn't have controlled every single execution context").

---

Now, finals are a very different beast. Given the tradition of not giving written feedback and higher grade value of final, TAs are much more interested in being fair rather than correct. So correctly solving the task and showing the understanding should be a priority. Oh yeah, and bad student handwriting is the most frequent cause of TA suicide during the finals week (the leading cause semester-wise is messing up svn repositories).

One more thing: negate the argument "this minor change will not affect your grade" by "this is exactly what one prof told me last Fall, and I ended up with a B- and now have to pay $10 more for car insurance".

Ciao!