Saturday, December 16, 2017

What We Learned in CS222, Fall 2017 Edition

Continuing my series, I would like to share with you the results of the CS222 Fall 2017 Final Exam exercise in which the students list what they learned and then vote upon them. This time around, I set a timer for 30 minutes and told them, "Let's see if we can get 100." I don't normally set a goal like this, but I think it inspired them to create one of the longest lists, at 155 after removing redundancies.
Each student got seven votes—the floor of the base-2 logarithm of 155, of course. Items with six or more votes formed a convenient cluster, and this set included:
  • TDD (13)
  • Good names (12)
  • Refactor vs. Redesign (7)
  • Self-reflection (7)
  • git (6)
  • Objects vs. Data Structures (6)
  • Time management (6)
These reflect the kinds of things CS222 students usually vote for and write about. TDD is a major theme of the course that a lot of students struggle with, and git is used throughout the course. Good naming and the object vs. data structure issue come right out of Clean Code. More teams than usual struggled to incorporate feedback into a viable final project, and so it's not surprising to see time management show up. 

The other two are a little surprising. Self-reflection is something that I emphasize throughout the course, most often manifest in reflective writing. Writing reflectively is required in several assignments and at the end of each iteration, and it also features in many achievements. It doesn't normally show up as something that students believe is one of the most important outcomes of the course, but I am glad to see it there. Maybe the fact that so many teams struggled means that more of them saw the value of careful reflection. Buried deeper in the "what we learned" list was another item I don't remember seeing before, "Improving composition skills." It did not receive any votes, but the fact that a student recognized that my feedback was designed to help him become a better writer, well that's a win in my book.

"Refactor vs. Redesign" is also a bit of an odd duck. I regularly hear students begin to misuse the word "refactor" to generally mean "do something good." I called a team out on it in my comments, reminding them that the two words mean different things. Many members of that team chose to write about this phenomenon, although honestly their definition of "refactor" was still not as crisp as I would have liked.

There were a couple of other interesting items mentioned that reflect the particular challenges this cohort faced. Accumulating a few votes were items like "Contingency planning," "You can always do better," and "Don't be complacent with your own code." "When to ask for help" got two votes, which is good but maybe not enough, since in many of the third iteration projects, I had to include the rhetorical question asking why they had not come to consult with me—particularly on iteration 2 feedback that they didn't incorporate. One of the most fascinating essays I read was of a student who came to the realization that criticism of his work was not criticism of him, and he contributed "Separating yourself from your work" as one of the most important things he learned. Perhaps one of the greatest items, which earned three votes, was, "We are beginners." I always close the class with a discussion of the Dreyfus Model of Skill Acquisition as part of a bigger presentation about the science of learning, and this articulation is, I think, the students acknowledging where they are and where they have yet to go. Indeed, a few of their final exam essays talked about a recognition of how much more they had to learn, which—in the Dreyfus Model—is a sign of the shift from Advanced Beginner to Competent.

One student offered "People don't change" as something he learned. He and I had talked about this, and he had written about it before, and it's a powerful idea about the nature of humans. Like many teams, his had some trouble with delegation and commitment, and he was disappointed when second-chances appeared to be squandered. Right after his item was logged, a student from another team offered, "People change!" (To which someone else added, "People!" but I didn't log that one.) The juxtaposition of these shows the variety of experiences and interpretations of human behavior present in the class. Turns out "People don't change" got two votes and "People change" got none.

The grades this semester were overall lower than previous semesters, in large part because so many teams dropped the ball on the third iteration, which is worth 9/14 of the project grade. However, very many students also did not take the opportunity to revise their assignments. This has two implications: first, their grades suffered; second, it implies that many had not taken the time to really understand the material on which the whole final project was based. Reading their essays, I think the students had good growth experiences despite the relatively low grades. Everyone who clearly put in effort passed the course, and I think they will be able to draw on what happened in CS222 to achieve greater successes in the future. 


No comments:

Post a Comment