What We Learned in CS222, Fall 2013 edition

For several semesters, I have been using the final exam to collect information about what students value having learned in Advanced Programming. Students work together to come up with a list of items they learned during the semester, and then they vote on which items were most important to them; full details on this approach can be found in my January 2012 blog post and my 2013 SIGCSE paper. I first used this format in Fall 2010, and I shared results from Spring 2013 in my post from May 2013. This table summarizes the top items from four different semesters:

Most Popular "What We Learned" Results by Semester

Fall 2010	Fall 2011	Fall 2012	Spring 2013
Team programming	Object-oriented design	Clean Code	DRY
Test-Driven Development	Coding conventions	Teamwork	Clean Code
Use of software libraries	Agile Manifesto	SRP	Build one to throw away
Refactoring	Effective Java	Class design	Refactoring
UML	Test-Driven Development		Naming Conventions
Design patterns	Stack Overflow		Research before acting

It might be worth noting that the first two columns used Joshua Bloch's Effective Java as a primary text, and the latter two used Robert C. Martin's Clean Code.

This past Fall was my first experiment in coupling achievement-oriented assessment with essential questions, maintaining my usual emphasis on reflective writing; I wrote a bit about that experiment just the other day. Looking at the results from Fall, here are the most popular "What We Learned" statements:

Item	Votes
Clean Code takes practice	13
Pair programming	10
It's OK to fail or start over	6
How to reflect on work	5
User stories	5

It is interesting to me that instead of simply saying they learned "Clean Code" as in previous semesters, these students agreed that Clean Code takes practice. It may be just anecdote, but this was the first semester that I allowed resubmission of work—part of my attempt to encourage mastery learning. Although I frequently felt like my feedback was not being heeded during the semester, perhaps this indicates that the resubmission policy helped students learn something quite valuable: not just the idea of Clean Code, but that putting these ideas into practice is difficult.

The middle row—it's OK to fail or start over—may be related to the resubmission policy. However, I suspect it is more directly related to the final projects. There was more than one team to whom I gave the same advice after two or three iterations, only to have them still not follow it. Some teams made significant platform changes between iterations, changes that forced them to abandon large parts of their implementation. I think that this is an important step in the students' maturation: they likely never had to throw away working code before, nor did they have to deal with a changing definition of "working."

I am pleased to see "How to reflect on work" was one of the top items, since the students spent a great deal of time during the semester writing achievement reflections. Although I have changed the balance of achievements and reflections for the Spring, as described in my previous post, I hope that this Spring's group will have a similarly positive experience regarding reflective practice.