What you do, what I do

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 going beyond being someone who can get a program to work, to being someone who can write clean maintainable code that developers enjoy working on. Although this course uses Lisp and JavaScript, most of the critiques about maintainability apply to all programming languages.

The Cycle

Here's how the process works:

Expect to re-do most things, especially early on. Normally, you should have two or three different exercises going through the revision cycle in parallel.

Grading

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

You do get a course grade. It is based on three factors:

Details

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

Submit solutions through the Code Critic link on Canvas. The Code Critic is also where you can see a complete history of your submissions.

The Code Critic is for solutions only. Do not use the Code Critic for discussion or messages.

If you have trouble accessing the Code Critic, post to Campuswire.

If you want to ask about a critique, see above.

Don't send code for review to email. I will just 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

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.

If I believe copying has occurred, I will submit the evidence to your dean. Since cheating on some exercises calls into question all the code you've done, and your grade is based entirely on your code, the effect on your course grade may be substantial.

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: MWF: 4:00pm - 4:50pm
Location: Tech LR 2

Contents

Important Links