Revising CS222, Summer 2015 Edition

This Fall, I am teaching two sections of CS222. It is my only teaching obligation, but it also the first time I am teaching multiple sections of the course. My daily planning for the course has been relatively coarse-grained, doing a lot of in-class demonstrations and reacting to student questions. This won't scale well to two classes: I already get confused between what we talked about in different courses, so I know it would be troublesome when teaching two sections of the same course. Hence, I am doing more day-by-day planning than I normally do. This also gives me the opportunity to be more intentional about how we spend our time. There were always a few days in this course where I think, "I talked too much today." By planning out more ahead of time, I hope to spend more time having students actively engaged during class meetings.

The overall rhythm of the semester will be the same, with about three weeks of individual assignments, a two-week project completed in pairs, and a nine-week, three-iteration project completed by small teams. Students will be able to earn achievements during the two-week and nine-week projects, and these achievements will contribute to their grades.

The grading system itself underwent the most significant change. I had been using a system based on grade caps: for example, if you failed to earn satisfactory marks on an assignment, your grade was capped at D, and higher levels of grade were "unlocked" by earning achievements. I think many students enjoyed this challenge, especially as the achievements permitted students to play to their strengths and interests. However, some students—usually those on the bubble between success and failure—would find the system disheartening, especially when they unlocked higher-level grades but did not actually earn them. This was certainly a failure of planning on their part, as no part of the grade was ever hidden or secret, but it also plays to their weakness: their difficulty in planning was exactly what hindered them from succeeding within this system. As a result, I have moved to a more conventional weighted average.

To make this work with achievements, which previously unlocked higher-level grades, I now allow students to earn up to 20 achievement credits that contribute to their final grade. When a student claims an achievement, the claim can be validated in one of three ways: the student can make the claim themselves, they can have a peer validate it, or they can ask me to validate it. These earn one, two, and four credits, respectively, and requests for my validation can only be made after a peer validation is complete. The motivation for this is to encourage students to review each others' work and learn from each other, and also to limit the number of times I have to simply kick submissions back to the students for not having met some requirement.

I am taking a similar approach with assignments. Last semester, students had to earn satisfactory marks on the three assignments in order to unlock grades higher than D. However, I spent a lot of time returning student resubmissions in what felt like students throwing ideas at the wall to see what sticks. That is, it was not clear that the students were doing their due diligence, and this was both frustrating and a waste of time. Now, a student must pass a peer review before a resubmission will be accepted. I tinkered with grade incentives to conduct peer reviews, including punishments for approving low-quality work, but I decided to keep it simple: I am hopeful that positive peer pressure will encourage these evaluations, and there's an achievement to be earned for students who do several such evaluations. If this doesn't work, I can always add more rules and regulations around peer evaluations another semester.

We had been using Mercurial on a locally-hosted Redmine server, the interface to which was a bit awkward but not insurmountable. I like Mercurial, especially its elegant command-line, but I decided to switch to Git for the semester since it is more popular and built in to both Eclipse and IntelliJ IDEA. Unfortunately, the Git interface on Redmine is even worse, and fundamentally, no one cares if you can get around in that interface: it has no extrinsic value. I was approved for an educator's GitHub account, and so we're going to try that instead. I was hoping to get more experience with GitHub this summer, but our summer research project has involved much more paper prototyping and analysis than programming. I will need to tinker with GitHub a bit to figure out the tools and workflow, but I've heard good thing, and I know there's a large community of practice that I can hook into if I need it.

After reading Essential Questions, I realized that my standard FizzBuzz example—which I use to teach TDD—was not very authentic. It's obviously a made-up problem, and while it provides an adequate context for learning the basics of TDD, I started thinking about replacing it with something more interesting. I am going to try instead a simple program that computes how many days a person has been alive, in part because it provides a good opportunity to talk about using libraries effectively. Now that I'm using Java 8, I have access to a sane time library without having to use joda-time. I tried whipping up a sample UI, but there's no date picker in Swing. Turns out there is one in JavaFX, however, and so I figured I may as well make the jump to that UI library. I still barely know JavaFX, but I think we can get by enough to give students the sense of it, so that they can use it in their own projects if they want to.

I have started using IntelliJ IDEA in some of my own work, mostly because it's essentially the new standard IDE for Android development. I thought about using IDEA in CS222 as well, because parts of it are quite nice. However, there's one "missing" feature in IDEA that made me stay with Eclipse, and that's how it makes it very easy to ignore warnings. In Eclipse, compiler warnings are highlighted in the code and in the outline view of a project. Students generally come into the course completely ignoring warnings, but this is a habit I want them to break: I want them to think critically about warnings. I try to get them to realize why warnings are worse than errors, specifically because you can ignore them even though something is wrong.

Those are the major changes in CS222. I think that I have hit a lot of the pain points I wrote about in my end-of-semester reflection. I have also completely revised the course Web site to be a single-page application using Polymer, but I think that's a post for another time.