It was good to teach CS222 in person, although I have had enough of rotational attendance, face masks, and physical distancing. All of these things significantly inhibit learning, and I'll be glad to see the back of them.
One of the most significant challenges this semester was not apparent when we started. There are always some students who feel that they are not proficient with Java, but I assure them that the prerequisite courses build in enough Java for us to make sense of the readings. Transfer students often come in without Java experience at all, but I point them toward The Java Tutorials, and that's enough for them to be able to read Clean Code. As the weeks went on, though, it became clear that this cohort was different. It became clear that they had done very little programming of any merit in the prerequisite course, that it had really not prepared them for CS222. This put me in a bad situation: I am still beholden to the learning objectives of my course, even if those teaching the prerequisite course did not hold up their part of the curriculum.
I tried using the existing achievements system to address the deficiency. I introduced a new one based on in-class examples that was really about practicing Java along with CS222 course concepts: namely, Optimas, which was to use TDD to develop a Roman numeral converter. Only a handful of students attempted this, which was good for them. It was not clear to me that other students were willing to put in the effort to make up for their deficiencies. Indeed, while there are usually some obvious slackers on teams, I feel like there was a lot more dead weight on teams this semester, people who, from looking through git logs, didn't seem to do anything significant on the projects.
It was in the last few weeks of the semester that I felt like I could see all the issues more clearly. Just before the third iteration of the semester project, I put up a required video about project planning. The video was under ten minutes long, and it was designed to help them understand how quality can be maintained only by managing scope. Two weeks after posting this required bit of instruction, I happened to be on my YouTube Studio page, which showed me that this video had only three views. There were 28 students enrolled in the class.
This became fodder for our last-day discussion, which had a tumultuous design. To summarize the major talking points, I mentioned that a student had referred to my feedback as "brutal," so I asked them to reflect on how honesty is mistaken for brutality. I showed them the CS121 learning objectives, and I told them that I had looked up their grades for that course, which were all A-B grades. My question for them was, "Who is brutal? The one who gives you honest feedback so that you can meet the objectives, or the one who gives you an A grade when you have not met them?" Then I pulled the rug out from them, pointing out the low viewership on the exact video that was designed to help them do their best in the final iteration: the blame is not external to them! In this way, I tried to show them that, like all of us, they are victims of their environment, but also like all of us, they have the opportunity to overcome it—but many did not take that opportunity.
All that is to say that there were a lot of ups and downs. The grades were, overall, very low, since many students never resubmitted anything from early in the semester, most teams only met some of the final project requirements, and many students did not engage with the achievements. One could blame pandemic malaise, but the fact remains that this cohort of students will struggle to move forward through the curriculum. I put together an optional summer enrichment program for them, consisting of a series of exercises designed to reinforce CS121 data structures knowledge while strengthening their CS222 skills as well. Given their low engagement, I honestly do not expect many to pursue it, but at least I feel like I offered something to them in the face of a systemic failure.
One of the things this made me reflect upon, though, is potential holes in my grading scheme. I had a student who seemed to be willing to do anything for credit except work on the project. This student completed achievements, wrote essays, praised teammates, but never seemed to write a single line of code. Indeed, to be honest, I am not certain that this student can write code at all. Yet, the student could have earned a C- and moved forward in the curriculum. It makes me realize that, after many years of having basically the same grading scheme in CS222, perhaps I should revisit it, perhaps in light of some of my work on checklist-based specifications grading, as I use is Game Programming.
Two other items are high on my list of changes to consider for the future. One is that analysis of git logs makes it obvious that many teams—the poorly performing ones, not coincidentally—have inconsistent progress throughout the iteration. Reflecting on this, I think it is in part due to the institutional brainwashing and the anti-thinking promoted by tools like Canvas. To wit, if I have an iteration deadline three weeks away, Canvas shows it behind anything else that is due sooner. It gives students the illusion that the work is distal, when it is in fact supposed to be consistent throughout. Put another way, Canvas makes it look like the increment has a deadline rather than that there is consistent work to be done. One way around this is to abandon Canvas altogether for this kind of work, but I would still have to put grades there somehow. Another way is to institute something like weekly labor logs, as I did in game design last semester, so that students see something due each week. That sounds like the tail wagging the dog, but I wanted to mention it here for the next time I prep for CS222.
The other thing that really has to change is my articulation of a "critical component" in the increment presentations. I have used this terminology for years, and despite how much time I spend reminding students and describing the requirements in text, there are always people who get it wrong. I think this is in part a naming problem. I think I will change the name of that aspect to "Teach Us Something." It is a bit cumbersome to talk about "the Teach Us Something requirement," but I think that will resonate better in more students' minds.
No comments:
Post a Comment