Thursday, March 26, 2020

Online Status Report Meetings in CS222

My four CS222 teams presented their first iterations of their final projects just before the switch to all online instruction. These are projects that are completed in three three-week iterations. Before the weekend was up, I had given considerable written feedback to each team on that first increment. This was probably on par with the level of feedback I would normally give, although I was careful to try to complete each thought rather than leave breadcrumbs intended to point us to conversation.

By Monday of this week, I was worried about them. One of the groups, which was already doing a bang-up job, had reached out to me for help in understanding the feedback and acting on it, but the other three were fairly silent. They had a minimal amount of structured work during the week, work that was designed to help with the online transition; they did this work, but I didn't hear much substantial from most of the teams. So, on Monday (that is, four days ago), I was considering whether or not I should mandate online check-ins: I didn't want to impose, and I know everyone is stressed, but I also wanted to make sure they were all making progress. In a conventional classroom, I could accomplish this by listening in, looking over their shoulders, or even just seeing who was skipping meetings; these affordances disappear online. I decided, late Monday, that we should do it.

Tuesday morning I posted a new group assignment that required each team to pick from a set of times for a 30-minute status report with me. This was halfway through iteration 2, so it seemed a fortuitous time. I heard from each team by Wednesday morning, and I had all the meetings on Wednesday afternoon. Each were conducted via Zoom, which has increasingly become a technology for which I am grateful.

I was quite tired by the end of the day, but it was definitely worth it. The average meeting was closer to 40 minutes than 30, and by sharing screens, we were able to look directly at the code problems currently facing the team. I could answer their questions, and I could also point out problem areas. In one case, a student pair was struggling with model-view separation: they said, "Well, this is model but this is view," which was actually incorrect. By looking at the code, I could not tell what they thought belonged in each layer, but by having a conversation, I could hear where their misconceptions were and then provide tactical guidance. I used Zoom's remote control feature with each team, and one of the teams had no idea this was available... despite my encouragement to adopt Zoom for distributed pair programming because of this feature. Unsurprisingly, this team also struggled with basic patterns of collaboration. Again, this is a great win for me as a teacher, because we got to start having conversations about that as well.

It was a great experience, even though it took all afternoon, and I'll definitely make it a requirement for the next iteration. I hope that it helped break down some barriers so that more students remember that I'm just an email away to help. Indeed, even in my Game Studio class—where I have four teams instead of my traditional one—I plan on asking in tomorrow's all-hands meeting about whether this is something they want to institute. It's certainly another case where I would usually make opportunities to look over shoulders and listen in to conversations, whereas those things are all now invisible to me.


No comments:

Post a Comment