What We Learned in CS222, Spring 2017 Edition

It is time, dear reader, for the End of Spring 2017 Blog Posts!

I want to start with my traditional "What We Learned in CS222" post, wherein I share an overview of what my students believed they learned in CS222, as self-reported on their final exam. This semester, they came up with 104 items in half an hour, which struck me as kind of low, but it was also a talkative group: several had a rather long wind-up to stating the item that would eventually be written down. Each student was given five votes to identify the items that were most important to them. After voting, we gathered items with the same number of votes into bins. These were the top five—the items with four or more votes:

Item	Votes
Clean Code Naming Rules	9
Test-Driven Development Process	8
Single Responsibility Principle	5
User Stories	4
Test often	4

Interestingly, the first four on this list were the first, second, seventh, and eleventh items listed, while the fifth was the very last—the 104th.

Regular readers may recall that "Clean Code" usually comes up early and is highly voted upon. I was surprised when the first contribution from the students was not just the generic "Clean Code", but specifically the naming rules. It's true that students continued to struggle with naming rules throughout the semester, but I do not think that this was much different from any other semester.

I'm not sure I have other new reflections on CS222 that I haven't shared before, except that there were a few times during the semester that I realized too late I should have had achievements for out-of-class activities that I value. The first was the CS120 Art Show, which is run every semester by my friend and colleague David Largent. We use a media computing theme in CS120, and the Art Show is an opportunity for students to select their favorite work from each section and have it showcased in the Atrium on campus. Celebrity judges then give awards based on the visual design as well as the source code design. Most of my CS222 students went through this course, and it would be valuable to have them go talk to the first-year majors and minors about their experiences. Since it's valuable, I could easily make it an achievement.

Similarly, reading students' essays at the end of their third-and-final project iteration, a few mentioned getting feedback from Code Smash!, which is the closest thing we have to a CS club. Most that referenced it talked about getting feedback from upperclassmen, while one wrote with pride about how a particular aspect of his final project let him help an upperclassman. It got me thinking that participation in Code Smash is valuable and should be rewarded, and as I considered this, I realized the somewhat special place that CS222 students find themselves in: they know much more than the freshmen about programming, but they know much less than the seniors about the various subdisciplines of Computer Science. I can imagine adding some kind of achievement to reward either "reaching down" to help those lower in the curriculum, "reaching up" to get help from someone with more experience, or maybe a single achievement that takes the two experiences and invites reflection on the contrast. I am uncertain whether this would be the same as the Art Show idea or if it has a different spin, but it's something for me to consider when I do my annual course redesign.

A few days ago I wrote about the attendance problem in CS222, in the context of our roundtable evaluation. This has been simmering on the back burner, and I wonder if the achievement system provides an answer here as well. The truth is, I don't want students to come to class "because they have to." That's the wrong attitude, and it fosters disengagement and bitterness. Frankly, those students need to mature before they can succeed anyway. However, I can use achievements as an incentive, and I can perhaps close the loop between the in-class activities and the final projects or essential questions. I am thinking of an achievement that asks a student to reflect on three in-class activities they participated in, encouraging them to draw the lines between the specific actions of the activity and the goals of their project teams.

Next Fall, we're finally moving CS222 back to a Tuesday-Thursday 90-minute schedule, the way that it was the first 2–3 years it was offered. I have been asking for this revision for years, since 50 minutes is just not enough time to introduce an idea, engage teams in meaningful work, and have them share and reflect on their experiences. This means I will have to do some rather significant revisions to my course plan during my annual course redesign. I used to give daily assignments that were due Tuesday and Thursday, which caused some whinging from students but also kept everybody on strict schedule. I stopped doing that with the switch to MWF because the grading load was too high for me to keep up with. I am leaning toward bringing those daily assignments back as a replacement for the more broadly-defined weekly assignments I have been using for a few years. I expect I will post again over the summer as I sort out those details.

Thanks for reading!