What you do, how I grade

You code, you test, I critique. Testing looks for bugs in your code. Critiquing looks for things testing can't find, such as

This course is about mastering coding, becoming not just someone who can get a program to work, but someone who can write clean maintainable code that developers enjoy working on. Although this course uses Lisp, most of the critiques apply to all programming.

The Cycle

Here's how the process works:

Expect to re-do most exercises, especially early on. Normally, you should have two or three revision cycles going at on at once, involving different exercises.


I do not grade solutions. Either a solution is fine, or it needs work.

At the end of the course, your grade is based on three factors:


Selecting Exercises

The Exercise Page lists the approved exercises for this course. They are bundled by topic and separated by difficulty. It is your choice which topics to do first. A good strategy in general is to do a few easy exercises in a topic first, then jump to a challenge in that topic when you feel ready.

If you are very new to programming or Lisp-like languages, do earlier bundles first. If you are more experienced, jump directly later bundles. If you encounter problems, or receive an inordinate number of critiques, go back to earlier bundles.

Submitting Solutions

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

The Code Critic

To submit solutions to the web-based Code Critic:

After that, things should be obvious.

Critic Access Issues

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

Don't send urgent messages to the queue. I may not see it for several days.

Don't send code for review to email. I will tell you to submit it to the Code Critic. 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 submissionsm:


Plagiarism is unacceptable.

Code you submit to the Code Critic must be your own. No copying, adapting, and submitting code from a github repository or a friend is allowed. Studying someone else's code for a specific exercise is not allowed.

Copying and studying working code makes sense when your goal is building an application. But your goal in this course is learning how to be the person who writes the code you copy.

Plagiarism detection will be applied to your code. If I conclude copying has occurred, I will submit the evidence to your dean. Since provable cheating on some exercises calls into question all the code you've done, and since your grade is based entirely on your code, I have to recommend failure in any cases of plagiarized code.

How To Do Well

Challenge yourself. 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 at least 2 to 3 pieces of new code a week. If you send less, you'll fall behind.

Re-test after every change. No matter how trivial you think the change is, run the tests just before submitting. You'd be surprised how often you break something with a small change.

Don't get stuck. Work on several problems in parallel. If you can't get something to pass all the tests, or if there's an error message you can't decipher, and you've devoted several hours to the problem, get help.

What I'm looking for

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

Faculty: Chris Riesbeck
Time: Monday, Wednesday, Friday: 11am - 11:50am
Location: Tech LR5


Important Links