Saturday, May 6, 2017

What We Learned in CS222, Spring 2017 Edition

It is time, dear reader, for the End of Spring 2017 Blog Posts!

I want to start with my traditional "What We Learned in CS222" post, wherein I share an overview of what my students believed they learned in CS222, as self-reported on their final exam. This semester, they came up with 104 items in half an hour, which struck me as kind of low, but it was also a talkative group: several had a rather long wind-up to stating the item that would eventually be written down. Each student was given five votes to identify the items that were most important to them. After voting, we gathered items with the same number of votes into bins. These were the top five—the items with four or more votes:

Clean Code Naming Rules9
Test-Driven Development Process8
Single Responsibility Principle5
User Stories4
Test often4

Interestingly, the first four on this list were the first, second, seventh, and eleventh items listed, while the fifth was the very last—the 104th.

Regular readers may recall that "Clean Code" usually comes up early and is highly voted upon. I was surprised when the first contribution from the students was not just the generic "Clean Code", but specifically the naming rules. It's true that students continued to struggle with naming rules throughout the semester, but I do not think that this was much different from any other semester.

I'm not sure I have other new reflections on CS222 that I haven't shared before, except that there were a few times during the semester that I realized too late I should have had achievements for out-of-class activities that I value. The first was the CS120 Art Show, which is run every semester by my friend and colleague David Largent. We use a media computing theme in CS120, and the Art Show is an opportunity for students to select their favorite work from each section and have it showcased in the Atrium on campus. Celebrity judges then give awards based on the visual design as well as the source code design. Most of my CS222 students went through this course, and it would be valuable to have them go talk to the first-year majors and minors about their experiences. Since it's valuable, I could easily make it an achievement.

Similarly, reading students' essays at the end of their third-and-final project iteration, a few mentioned getting feedback from Code Smash!, which is the closest thing we have to a CS club. Most that referenced it talked about getting feedback from upperclassmen, while one wrote with pride about how a particular aspect of his final project let him help an upperclassman. It got me thinking that participation in Code Smash is valuable and should be rewarded, and as I considered this, I realized the somewhat special place that CS222 students find themselves in: they know much more than the freshmen about programming, but they know much less than the seniors about the various subdisciplines of Computer Science. I can imagine adding some kind of achievement to reward either "reaching down" to help those lower in the curriculum, "reaching up" to get help from someone with more experience, or maybe a single achievement that takes the two experiences and invites reflection on the contrast. I am uncertain whether this would be the same as the Art Show idea or if it has a different spin, but it's something for me to consider when I do my annual course redesign.

A few days ago I wrote about the attendance problem in CS222, in the context of our roundtable evaluation. This has been simmering on the back burner, and I wonder if the achievement system provides an answer here as well. The truth is, I don't want students to come to class "because they have to." That's the wrong attitude, and it fosters disengagement and bitterness. Frankly, those students need to mature before they can succeed anyway. However, I can use achievements as an incentive, and I can perhaps close the loop between the in-class activities and the final projects or essential questions. I am thinking of an achievement that asks a student to reflect on three in-class activities they participated in, encouraging them to draw the lines between the specific actions of the activity and the goals of their project teams.

Next Fall, we're finally moving CS222 back to a Tuesday-Thursday 90-minute schedule, the way that it was the first 2–3 years it was offered. I have been asking for this revision for years, since 50 minutes is just not enough time to introduce an idea, engage teams in meaningful work, and have them share and reflect on their experiences. This means I will have to do some rather significant revisions to my course plan during my annual course redesign. I used to give daily assignments that were due Tuesday and Thursday, which caused some whinging from students but also kept everybody on strict schedule. I stopped doing that with the switch to MWF because the grading load was too high for me to keep up with. I am leaning toward bringing those daily assignments back as a replacement for the more broadly-defined weekly assignments I have been using for a few years. I expect I will post again over the summer as I sort out those details.

Thanks for reading!


  1. The Top-8 list from my section (out of 83 items) was thus:

    - Start on a project earlier than you think you should / Coding always takes longer than what you anticipate (9 votes)
    - The importance of spending some time naming variables (6)
    - Test driven development (5)
    - 8:00 AMs are not my thing, I don’t like 8:00 AMs (5)
    - How to adapt a plan as you go (5)
    - Red-Green-Refactor (4)
    - Giving each class a single responsibility and nothing more (4)
    - How important having a driven group is (it would have been impossible to complete our project otherwise) (4)

    We talked about combining TDD and RGR into one item before they voted, but the group felt that RGR was a subset of TDD and wanted to keep it separate. I see a lot of overlap with your list.

    I like your ideas for new achievements (art show, reaching down/up to give/get help, and linking in-class activities). Also remember that I've introduced a couple of achievements dealing with diversity, and rereading the text. Maybe we can work together to develop them later this summer.

    We both get to do a bit of schedule juggling for this fall. You got the Tuesday/Thursday schedule back, and I'm going back to a Monday, Wednesday, Friday. I need to start lobbying to get us both on a Tuesday/Thursday schedule.

    1. The re-reading one, I'm still not sure about it. I refined my achievements system a few semesters to only include things that are outside what is needed for normal classroom success. Re-reading the book, that's just plain required to understand it. Of course, many of the students don't know that! So the question for me is this: is it worth adding an achievement to incentivize something that everyone ought to be doing anyway, or is it better--if I want that behavior--to just grade for it, and let the achievements maintain purity of design? Currently, I do the latter: in feedback on the two-week project and many final project iterations, I say directly, "You need to re-read the chapter on XYZ" or "You need to revisit your assignments" (which includes reading, natch).