Dropping the requirement for separate reflections has allowed me to expand the writing requirements within the achievements themselves. I will be keeping the policy that allows students to resubmit achievements, which I had not allowed on the reflections due to the overwhelming amount of my time this would have required. Focusing my grading efforts on the achievements, and seeing them as the primary non-programming writing artifacts, I will be able to give more direct feedback and, hopefully, see students improve their writing more visibly.
Similar to my game design course revision, I have pulled the achievement system out of the first few weeks of the class. A gentler introduction to the themes of the class will be had from a more conventional approach, with assigned reading, in-class activities, and small practice assignments. The achievements system will kick in during the two-week project, which precedes the major, nine-week project.
Last year, I probably came the closest I ever will to my hypothetical "your grade is the lowest grade you earn all semester" grading scheme. It was a good teaching experience, and it formalized—in the course structure—the idea that a good computer scientist needs to be balanced. However, it did lead to some stress and heartache at the end of one of the semesters. I cannot say much about it publicly, but the anonymous version is that a team did a crackerjack job on a project but had not met the requirements for a passing grade in other areas. This experienced forced me to reflect on whether or not this grading scheme really reflected what I believed and valued. Of course, every semester is an experiment, and so I will try something different this year.
In the Fall, students will be able to earn up to a C grade by simply doing the final project reasonably well. If a student gets up to a C-level grade in the final project, that's all he or she needs to get that grade in the course. This sounds "average" to me: if you can work together with a group of near-strangers, understand the rules of Clean Code, and make a passable project, you can get through the course. (Majors need a C− or better to move on in our curriculum—a policy I disagree with, but that's for another day.) This will permit achievements to actually represent something beyond the usual, something "good". So, a student must complete ten achievements in order to get a B-level grade. If a student wishes to show that he or she is "excellent," an A-level grade can be earned by additionally completing a quest. I am not sure that's the right word, but it's better than "meta-achievement," which I used last year. Some quests are completed by finishing coherent sets of achievements, but I have used this to also open up new opportunities. One quest is completed by having the final project be a contribution to an open source project, and another is completed by working with a real client. I am hopeful that these will be enticing to the students and encourage them, from the beginning, to take the initiative and do something ambitious. Even if they take a risk and fail, they won't "fail" the course, since they can always fall back on a lower—but still passing—grade.
Last year, I did not include formal peer evaluations into the grades as I had in the past. It was still clear to me who was contributing to projects and who was not. However, I will have about twice as many students in the Fall as last Spring, and an order of magnitude more projects to monitor, so I am bringing back peer evaluations. The peer evaluation form comes from a 2011 blog post, and I have described precisely how it fits into the grading scheme on the final project specification. In the past, I have sometimes forgotten to tell students ahead of time how each iteration is graded, but this time I have laid out all the details. I have occasionally not counted the first iteration at all, since they are sometimes pretty rough. This year, I will be using a quadratic series: first iteration has a weight of one, second iteration has a weight of four, and third iteration has a weight of nine. This should ensure that students still do an honest job on the first iteration while also reflecting that they should be getting better at working together as time goes on.
This Fall marks an important change in the population of my students. In Fall 2013, the foundations curriculum committee enacted a change to our introductory programming sequence. It had previously been taught in Java both semesters, using a conventional approach (read that with a bit of a sneer). Last academic year, our students started in Python using the Media Computing approach, following that with a more conventional course introducing data structures using Java. The Spring CS2 course was a bit rocky, as to be expected with any such shift in a curriculum. I would expect the students coming into CS222 in the Fall to be particularly weak with Java, although this will become less of a problem as the wrinkles in CS2 get ironed out. Time will tell what kind of remediation I will have to do. The truth is that most of these students have been programming for such a small amount of time, many harbor deep misunderstandings about essential programming ideas when they come into CS222. The good news is that by having them work in teams on a real project, they can learn from each other and be motivated to do better. Indeed, this is one of the main outcomes of CS222, so that then these students can move on from our foundations courses and be productive in the rest of the curriculum.
Here are some links for reference:
- The course description for Fall 2014 and the final project specification
- Last year's course descriptions for Fall and Spring
- Last summer's post about Advanced Programming course revisions
- My reflection on using achievements during 2013-2014
