Sunday, January 5, 2014

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:

Fall 2010Fall 2011Fall 2012Spring 2013
Team programmingObject-oriented designClean CodeDRY
Test-Driven DevelopmentCoding conventionsTeamworkClean Code
Use of software librariesAgile ManifestoSRPBuild one to throw away
RefactoringEffective JavaClass designRefactoring
UMLTest-Driven DevelopmentNaming Conventions
Design patternsStack OverflowResearch before acting
Most Popular "What We Learned" Results by Semester

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:
Clean Code takes practice13
Pair programming10
It's OK to fail or start over6
How to reflect on work5
User stories5

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.


  1. Looking over the top 5 you listed and thinking back to our time at the Virginia Ball Center, I feel like each of those was a key part of what we did--especially the first and even more especially the third. Our community partner, the Indianapolis Children's Museum, gave us some blunt feedback about our first presentation. One week later we came back with a very different experience and they were very impressed. If we hadn't been willing to trash our work and start over we wouldn't have anything near the product we finished with (a very good product, I'd say).

    I don't know what we would have ended up with had we continued on the same path (which we did consider for a bit). It very well could have been something we, ourselves, would have been pleased with, but it was far better to please both ourselves and our partners.

    I think it's great that these 222 students realized they learned that it's acceptable to "fail or start over." There's no reason to become so attached to a piece of work that you can't take constructive feedback, can't throw it out to start over, or simply become so stuck on an idea that you're missing something even better.

    1. Yeah, I hope this lesson "sticks" with them. None had community partners or real external stakeholders. My hope is that when they get to the capstone (or a game studio course), they will have a tacit understanding of why they need to prototype, to sketch, and to not fear throwing things away!