What you do, how I grade

Treat this course like a job. Your grade is your performance evaluation. The key performance measures are:

• maintainability of code produced
• quality (correctness) of code produced
• quantity of code produced

One goal for this course is to improve the maintainability of your code. To do that, this course replaces the standard two-step "code - grade" pattern with a cycle of "code - critique - revise."

The Cycle

Here's how the course works, as far as coding and grading:

• You use the web-based Exercise Queue to select an exercise and send me a working solution.

  Working means that the code has been cleared by both the Unit Tester and the Lisp Critic.

• I use the same system to annotate your code with detailed critiques.
• You respond to all of the critiques by revising and resubmitting your code.
• We repeat this cycle until I tell you to move on.

Normally, you should have two or three cycles going at on at once, involving different pieces of code.

See the Code Critic FAQ for common questions about this process.

The Exercise Queue

To access the web-based Exercise Queue, click on this link to the EECS 325 Arch Home Page. Log in with your netid, then click on the Code Critic link on the left. After that, things should be obvious.

Email me for things requiring immediate attention, e.g., "the web server is down." Always put EECS 325 in the Subject.

Don't mix these up. If you send urgent messages to the queue, I may not see it for several days. If you send code to my personal address, I will tell you to submit it via the exercise queue, and you'll end up later in the queue than you would have had you sent it directly there.

The Rules of the Queue

Here are the rules for normal exercise submissions. Some of these are enforced automatically by the exercise queue system:

• Short code only -- no more than a dozen lines of code.
• No attachments -- copy and paste code into the body of the message.
• No untested code -- I really really hate getting code that doesn't run.
• No output -- unless you demonstrating a function you've invented for yourself.
• No test cases or code -- testing is good, automated testing is even better, but don't send testing code to me.
• One exercise to a message.
• Don't repeat yourself -- each submission should demonstrate something new.
• Don't repeat me -- don't include previous conversations between us, except for specific questions.
• Don't get ahead of me -- at most 3 brand-new items in the queue (no limit on resubmissions).

In slightly more depth:

Keep submissions short.

Each submission should be no more than a dozen lines of code. I neither need, want, nor can handle long code files for critiquing.

Keep submissions coherent.

Each submission should be about one thing. Don't cram several exercises together. If piece of stand-alone code is only one or two lines, it may not be worth submtting in the first place.

Keep submissions interesting.

There's no point to sending me code that was trivial for you to do. It proves nothing about what you know. If everything in the textbook was easy, let me know. I'm sure I can challenge you.

Submit at a steady pace.

Send no more than 2 to 3 pieces of new code a week. If you send less, you'll fall behind and fail. If you send more, you'll be sending too many pieces of code with the same mistake repeated over and over.

Send only working code.

Test your code on more than one example. If something happens that you can't figure out, contact your TA. Code that doesn't work is returned with the comment "This doesn't work. Did you test it?" Sending it wasted your time and mine.

Use copy and paste, not attachments.

Include your code directly in your message. It takes me twice as long to reply to code stored in attachments. Don't retype -- you'll introduce mistakes and differences and I'll be critiquing the wrong thing.

Don't include prior submissions or my replies.

I have all our discussions and will compare as necessary. Only include notes from me when you have a particular question about something.

Don't get backed up.

If you get backed up and then send a ton of stuff, it won't help. I put long submissions (more than a dozen lines of code) and excess submissions (more than 3 or 4 from the same person) at the end of the queue.

Key Features of the Cycle

No grades.

I only critique your submissions, I don't grade them. Your grade for the course is based on how much better your codng is by the end of the quarter compared to where you started.

No hardcopy.

All work is submitted electronically.

Very few class-wide homework assignments.

The only assignments I give to the class as a whole are things to do in preparation for the next class meeting. These are separate from the do/review/re-do cycle.

No due dates.

However, if you sending me less than 2 to 3 things a week, you're in trouble.

The Skills

The skills to be demonstrated can be measured along these dimensions:

• Maintainability of code produced:
  • Readability: Good names, the Cardinal Rule of Functions, good use of whitespace, "short attention span programming"
  • Modularity: coherent modules, well-defined module interfaces, no unnecessary shared global variables
  • Appropriateness: appropriate use of built-in Common Lisp functions, data structure, and control flow constructs
  • Documentation: commenting (what not how)
• Quality of code produced:
  • Coverage: range of inputs handled, errors handled
  • Adequacy: appropriate depth of representation, range of inferences supported, "thickness of interface"
• Quantity of code produced:
  • This is the least interesting dimension, but if you're not writing very much, or take forever to do something simple, then there's a problem.

When you get stuck

If you have trouble with some piece of code,

• narrow the problem down to the smallest code you can
• email it and a log of the input/output to me.

If you're working on a window-based system, you can probably use cut and paste to get the input/output log.

Narrowing down the source of a problem is one of the key skills in programming. Often, once you've found the expression that causes the problem, the reason is obvious. Even if it's not to you, the TA or I can figure out what's going on much more quickly from two lines of code than ten.

Warning

"xxx doesn't seem to work" messages are absolutely useless, and will be returned with an annoying equally useless comment to that effect.

Comments? Send me email.