What we learned in CS 222: Spring 2018 edition

I've had the pleasure of teaching the CS 222 course since fall 2015. Having just started to blog last fall, last December was my first opportunity to blog about the end-of-semester activity we conduct in this course. This blog entry will report on this spring's course.

The final exam process for CS 222 consists of three parts. First, the students are asked to list everything they can think of that they learned--directly or indirectly--because of their participation in CS 222 this semester. Once the consolidated list is compiled (and cleaned of duplicates), each student has a limited number of votes to cast to identify the items they feel are the most significant. And lastly, each student then selects one of the items which received the most votes and writes a reflective essay about how they learned that item.

As we cleaned the list, we decided to place some individual items under a heading (e.g. Clean Code); it was the heading that could then be voted for. The consolidated list contained 97 items (after creating these consolidations and removing duplicates). Each student had seven votes to cast for the items they felt were the most significant for them. Because of a tie for seventh place, we included eight items in our "Top N List," which ended up including these items (votes shown in parentheses):

• Clean Code: Best practices of code structure (23)
• Test-Driven Development: Using test classes to guide production code (22)
• Git (12)
• Object Oriented Programming Model (9)
• Behavior Driven Development and User Stories (9)
• Stages of group development (Forming, Storming, Norming, Performing, Adjourning) (8)
• Empathy cycle (acceptance testing) (8)
• Plan and track your work (8)

The students in the fall 2017 section of the course developed this list:

• Clean code techniques (15)
• TDD (15)
• Stack overflow (14)
• It’s easier to take the time to write cleanly than to write dirty code and fix it later. (8)
• Code is like art. Anyone can look at code and call it beautiful, but it’s rare to find someone who can tell you why. (7)
• Time-management is a key factor in a lot of things (7)
• Consider what the needs of the end user are when developing functions, rather than developing functions based on satisfying your own goals for your application. (5)
• Navigation of GitHub (5)

Comparing the two lists, I see many similarities. Both lists include references to clean code, TDD, Git, and empathy/considering the users' needs. Clean code and TDD are major themes of the course, both of which are completely new concepts to the students. As such, they struggle with them. Similarly the use of Git and GitHub is new to virtually all students, and causes its own challenges, until they take the time to figure it out. The empathy theme comes from a discussion about a design cycle model a few weeks before the end of the semester. Planning and tracking work, and time-management are related items on each list, but have a bit different focus. Few students have had to manage a project that lasts more than a few days, so it is no surprise this would make it onto the list.

New to this year's "Top N List" is object oriented programming (OOP), user stories, and stages of group development. OOP terminology was on last fall's master list, but only received four votes. User stories received one vote last fall. Stages of group development was mentioned last fall, but did not receive any votes. It is rewarding to have it make it onto this year's list, because I added this topic to the course when I started teaching it. Noticeably missing from this year's "Top N List" is Stack Overflow, although is did receive six votes, so it was close.

There were a few items that I found interesting, but didn't receive enough votes to make the "Top N List."

• How much fun and how rewarding teamwork can be
• What I enjoy working on versus what I don’t enjoy working on
• Implementations are almost always more complicated than they appear at the surface

I like the that a few students now believe teamwork can be a positive experience. The fact the it didn't make the list could be that most students had already figured it out, or maybe they didn't experience the great teamwork these students did. It is always good to know what brings you joy, and what does not. The few students that voted for that item may well save themselves some grief in the future. The last item relates to the "plan and track your work" item which did make the list. Again, few students have had to deal with a "large" project, so there were lots of surprises awaiting them.

Comparing the course grades of this semester's students to those of the fall semester, the grades dropped slightly, though not what I'd consider significantly. Percentage wise, there were fewer Bs, more Cs.

	Fall 2017	Spring 2018
A	42%	42%
B	48%	42%
C	10%	16%
D	0%	0.0%
F	0%	0.0%

Last fall, I started using specifications grading for this course, but the assessable items did not change--only how they were evaluated. I reflected on my experiences with this transition in my previous blog entry. I continued with this method of grading this semester as well. The drop in grade for a couple students can be attributed to one student not "carrying their weight" within their team, and thus was rated low on the final project (which had a significant impact on their course grade), and another student simply not submitting much work, other than the projects.