Roundtable course evaluation in CS222

This is the final full week of classes at Ball State, with one more regular class meeting on Monday before final exams Tuesday through Friday. I had planned out everything that needed planning in CS222, but this past Monday had a hole. It would have been easiest for me to schedule a "studio day," where I show up to class and help teams out with their final projects, but I decided I wanted to do something different: I held a roundtable discussion with my students about their experience this past semester. The decision was motivated in part this semester's abysmal attendance, but as I got to reflecting on it, I realized I had many more questions about the students' experience that perhaps an open discussion would address.

I announced the plan for the week to Blackboard, and I came into Monday with a fairly simple plan. My idea was to talk through four prompts: What were the highlights of the semester? What were the stressors and low points of the semester? Why was the attendance so poor all semester? What advice would you give for next year's students?

I was surprised to see a great turn out on Monday, although it was less clear to me if they had actually read the announcement of what we would be doing that day. We pushed some tables out of the way and circled the chairs for the discussion, and I opened with the first question listed above. From here, there were never really any dead spots for the 45 minutes or so we had; the conversation flowed from one topic to another. As time went by, I did occasionally steer the group to get at those four issues above, but it was much more organic than I imagined it would be.

The notes I took are mostly chronological, but I'm not sure that it makes sense to share the results in that order. My goal here is not to recreate the conversation but to provide enough notes that others—including Future Me—can use these observations to make course planning decisions. I should mention that not every student spoke up, probably about half, with some saying more than others, as these things tend to go. I don't present these notes as representative of the whole class, but as a record of what was shared.

The highlights reported by the students included "story time", which I took to mean my sharing of relevant (or not?) anecdotes to support the themes of the course. Students responded positively to the self-driven format of the course, with several stating that they had never had a class like this. One student pointed out specifically that he loved the format, even though he didn't take the most advantage of it; he would do it differently a second time, if he could. When I asked whether there was anything that could be frontloaded to encourage the kind of behavior he described, the group didn't really come up with anything. The class examples from the first third of the semester were also cited as highlights, with the observation that the examples in Clean Code tended to be abstract, but the things we built were real applications. This was interesting since our examples were, in my opinion, ridiculously small, but to the students this was still more valuable than the incomplete examples (that is, they are only portions of systems) given in the book.

A student suggested that he would like to have an example of perfect Clean Code—a project that he could look at for exemplars of all the ideas he needed to know. Several students nodded in agreement that this would be useful. I decided to play devil's advocate, and I asked them if they thought there was a poem that they could read that would show them everything they needed to know about poetry, or if there was a novel that was clearly The Best Novel in English. They realized quickly of course that this was ludicrous, and it seemed they quickly made the association back to code. I acknowledged that the desire for such a thing is not bad, but that I doubted that such a thing existed, or that it could exist. Instead, I encouraged them to think about what they would want out of this desire, and how they would get it in different ways. (When I posted a version of this story on Facebook, a friend and alumnus coined the term "Clean Code Unicorn," which I quite like.)

The discussion veered a little bit from this concept, but as part of it, students expressed a desire for more examples of high-quality code, including specific examples of Model-View-Controller architecture. The speaker acknowledged that I had, in fact, provided reference to some, such as Guava, and that Robert Martin has some wonderful lectures on YouTube. Acknowledging the authenticity of the desire for more examples, I asked what would actually motivate students to study those examples. One student said his two-week project grade was motivation enough, and another called for "points".

One student expressed a frustration that not everyone in the class knew how to learn from the book. He himself had read the book when it was assigned and studied it rigorously, but he was working on a team with students who had not done this, and so they had no concept of what they were doing wrong. It was refreshing to hear a student express this concern that so often I hear faculty discussing! Several suggestions were made to ameliorate the problem, including making a guide on how to use examples from the book, doing more whole-class work sessions to solve refactoring problems, and homework assignments with canned bad code examples. The most innovative recommendation was to have a Challenge of the Week, like a sudoku or crossword puzzle, where the class would be given some code to refactor toward cleanliness in exchange for some kind of course credit.

Another student suggested that I provide more guidance about naming conventions in general. Clean Code talks about the importance of good naming, but it doesn't get into cultural norms such as "a method should not be called setX unless it is a mutator that takes an X as a parameter," "a boolean method should be named isX for ease of reading conditionals," or "methods that make other things are often called createX methods." This student was reacting to some feedback I had given on that team's previous submission, where I gave pointers like these (maybe exactly those, actually). That is how I usually handle these cases: as students come across common problems—which will manifest differently for each team—I will provide guidance on them. After the discussion, it got me wondering if the student mistakenly thought that the team "lost points" for this kind of thing; it may be an easy mistake to make since my guidance on naming might be interleaved with more serious Clean Code violations. Since it's not clear to me that I can frontload all of the cultural naming rules in a way that students will be able to internalize, maybe what this student really wanted was clarity in which parts of my feedback were formative vs summative.

We talked about attendance a bit, but I prefaced the discussion by saying that I understood that few people really enjoyed 8AM classes: we couldn't control the scheduling, so I wondered if there was anything else contributing to low attendance. For those who don't know, I don't record student attendance or grade participation, but I won't go into my philosophical and pedagogic argument for that here—that's for another blog post. However, because I don't give "points" for attendance, one student framed it as, "People don't come to class because you don't care if they come or not." I pushed back a bit, and he backpedaled on the "don't care" part, but this idiomatic expression belies the mental model. I would argue that I don't take attendance because I do care, but it's very easy for students to misconstrue this. As in many cases, it's the students who are least capable of drawing this conclusion who are in the direst situations from missing it.

The other factor impacting attendance, according to the students, was that some of their peers have the perception that what we do in class doesn't matter: because it is not directly graded, they can simply skip class and ask their peers for a high-level view later. This is not surprising to me, since during the nine weeks of the final project, I use class time on activities that are designed to foster students' success in their projects: code reviews, philosophical discussions, UI design techniques, teamwork skills, and so on. These are not directly graded, but they are carefully designed to complement what students are doing. The ones who skip because these things "are not important" tend to be the cocky ones who can sling a bit of code, but who reject the idea that they are unprofessional in their techniques. Again, tragically, these students miss discussions of concepts such as second-order ignorance, and because they miss the discussion, they miss the point. It does make me wonder if more students would be impacted by changing some of my assessments in the course to directly bring in these concepts,  although I worry that this is a slippery slope leading way from authentic project work. As it is now, students either take my advice or not, and those who do tend to succeed, and those who do not, do not. Some of my best experiences have been with students who rejected feedback in one semester and then enrolled in my class a second time and really nailed it—these are cases where I truly believe I have made a lifelong impact on a student.

Looking over my notes on attendance and participation notes, I jotted in the margin that I could use my course's achievement system for participation somehow. This system has provided a good mechanism for rewarding the various kinds of virtuous behaviors I want students to practice. It would be very easy to add one with criteria such as, "Write a reflective essay about three in-class activities in which you participated, relating it to your final project." That's probably what I'll do for Fall.

In the last few minutes of our discussion, we focused on the advice that this semester's students would give to those taking the course in the Fall. Here's what came out of the discussion:

• Do the assignments in the first three weeks. Students can resubmit assignments throughout the semester, one per week. Some students make the mistake then of not working on these right away. As a result, they quickly fall behind, since then they're being graded in projects on concepts they have not yet wrestled with at all.
• Go through the book, which I interpreted to mean, actually do the assigned reading when it is assigned, so you know when you need it later.
• Pick an easier project. I joked about this being like Hofstadter's Law: pick an easy project, then pick an easier project.
• Name correctly. Students mentioned again that the idea of naming correctly is almost trivial, but the implications of actually naming correctly are profound.
• Talk to other students outside class. They mentioned the programming club, Code Smash, as a good source, and just generally talking to upperclassmen, as ways to get more feedback.
• Watch out for StackOverflow and tutorials. They are often abstract and don't follow best practices of Clean Code.
• Keep up to date, in particular with platforms like Android, where advice from five years ago may very well not be applicable today.

I think it took me longer to type this up than the discussion itself, but I'm glad I took the time to do it. I hope that you might find something interesting in here for yourself, dear reader. As always, feel free to leave a comment about your own experience, advice, or teaching practices.