The two people who devised this course–Jonthan Frankle and I–both studied computer programming in college (he much more recently than I) and took from those experiences the critical importance of weekly, graded problem sets. Students in this class must complete a problem set every week of the semester. These are calibrated to be quite tricky, full of small details and annoying little edge cases that require time and hard work to perfect.
At least in my opinion, the problem sets are the heart of the course. The essence of programming is not the syntax or the programming tools. One learns to program by writing complicated little computer programs that require perservence and hard work to complete. This explains why so many people try and fail to teach themselves to program, even though we live in the golden age of free online programming tutorials, books, and MOOCs: it’s too easy to get stuck on a tricky problem. Without the motivation of a deadline and a grade hanging over your head, only the truly self-motivated will power through to the correct solution. Stepping through a tutorial or MOOC while skipping some of the problems will not a programmer make.
The final grade in this class is based entirely on the successful completion of these problem sets. There is no final exam, and participation counts for only a little.
It is an understatement to say that these problem sets cause unsuspecting law students a lot of angst, and in some cases outright stress and unhappiness.
There are at least three important ways that graded problem sets disrupt the settled expectations of 2Ls and 3Ls:
There is a correct answer. Law students learn from the first moment of instruction that there often is no right answer to a legal question. Law school exams tend to reward the ability to see both sides of an argument, marshalling out the best arguments for one side, responding with the other side’s best rejoinder, repeating in infinite regress, until time runs out. In stark contrast, the problem sets we assign almost always have a correct answer. The code complies with the full specification of the assignment, or it doesn’t. There aren’t gray areas in the middle.
It is hard to predict how much time a problem set will require to complete. It wasn’t until I started teaching this class that I recognized something that had previously escaped me about legal education, and perhaps about social science education in general: you can plan your life in advance in most law school classes. A law student–from the most diligent to the most indolent–can schedule the amount of time he or she can allocate to the various tasks for a particular class in advance: “I’ll spend 10 hours on the outline, 9 hours taking practice exams, 3 hours with my study group, and 4 hours taking the exam.” Or, “I’ll spend 10 hours doing background research, 10 hours writing the first draft, 1 hour getting feedback from the professor, and 15 hours editing this paper.”
You can’t do that with a problem set. The best problem sets introduce small little difficulties that might take ten minutes to work through or ten hours, depending on your programming ability and on the vagaries of whether or not the correct creativity neurons fire at the right time. Every undergraduate computer programming student figures this out early in their education. Trying to bend the work on a problem set to a pre-specified schedule is fantasy. Some weeks, the problem set will take half as long as you thought it would; other weeks, it will take twice longer than you feared it might.
Finally, it is hard to solve a problem set in one sitting. Often, you need to work a bit, get stuck, turn away from the task, and return to it later. Every programmer will tell you a story about the tiny bug that they couldn’t conquer throughout a marathon coding session, only to have the answer come to them in the shower, or as soon as they looked at the code again three days later. The number one mistake our students have made, despite the many ways we have tried to counsel them not to do this, is to plan to complete their problem sets in one sitting, the day before it is due.
Because the main goal of this blog is to help administrators and professors at other schools decide whether this course is for them, I want to emphasize the two points of this post: if you want your students to learn to program, you need to force them to complete graded problem sets, but if you do so, be prepared for the pain of unsettled expectations.
We have tried to do many things to soften the impact of these defeated expectations. We blanket each week with office hours–students will have access to a schedule which allocates fourteen hours each week with a professor or TA for small group help with problem sets. We use an online messaging tool called Piazza, designed to let students help one another when they are stuck (subject, however, to a pretty strict no-collaboration policy). And as of this year, we now assign one problem that is due before the add/drop date for the course. You can’t understand what makes a problem set difficult until you’ve tried to complete one.