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
- maintainability: modularity, naming, structure, etc.
- appropriate use of a programming language and its libraries
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.
Here's how the process works:
- You select an exercise and send me a working solution.
- I critique your solution and return it to you.
- You revise and resubmit your solution.
- We repeat this cycle until I have no more critiques.
- You repeat this process until the course ends.
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:
- Progress: How far did you get? How many different kinds of problems did you do? How difficult were these problems? How many different topics did you explore? How many skills did you demonstrate?
- Quality: How good is your code by the end of the course? What level of critiques are you getting?
- Effort: How often and how steadily did you submit, including revisions? How hard did you push yourself from your personal starting point?
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.
- Use the web-based Code Critic to
submit working solutions.
Working means that the code has been cleared by both the Unit Tester and the Lisp Critic tools.
- You will receive an email when I have critiqued your code.
- Respond to all of the critiques by revising and
resubmitting your code.
- Only resubmit code that you changed.
- Don't ignore critiques. If you don't understand or
agree with a critique, send me email containing (in plain text)
the code, the
critique, and your response.
EECS 325:in the Subject line and the name of the exercise.
- We repeat this cycle until I tell you to move on.
- There is a limit on how many new exercises you can submit at once.
See the Code Critic FAQ for common questions about this process.
The Code Critic
To submit solutions to the web-based Code Critic:
- click on the Code Critic on Canvas link on the right
- log in to Canvas
- click on the Code Critic link under Modules
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:
- No untested or partially working code -- I really really hate getting code that doesn't pass all the tests.
- No code output -- unless requested by the exercise
- No testing code -- unless requested by the exercise
- No book code -- only send code you wrote
- No comments -- comments are a bad idea anyway, really, trust me; it's OK however to use a comment to ask me a question
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.
What To Do If You're Stuck
Don't stay 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.
If you are getting an error or strange result, don't post solution code, even broken code! Instead, do this:
- Write a simple version of the
code that has the same problem.
- Usually one or two lines of code can reproduce any bug.
- Often doing this will make the problem and fix obvious to you.
- If still puzzled, do a web search with "lisp" and the relevant bits of the example, e.g., "lisp delete first element."
- Look in a Lisp FAQ.
- If all fails, post your short code and the results to Piazza.
If you still can't figure out what's happening
- Email me your code, the exact call you tried, the exact output you got, and the exact output you expected
- Put all this in plain text in the body of the email. No attachments!
- Put EECS 325: in the Subject line, followed by the name of the exercise.
"xxx doesn't seem to work" messages are absolutely useless, and will be returned with an annoying equally useless comment to that effect.
What really happened was that you tried X and expected Y but saw Z. Either you wrote X incorrectly, or your expectation is incorrect.
What I'm looking for
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.