|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:
|Clean Code takes practice||13|
|It's OK to fail or start over||6|
|How to reflect on work||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.