Week 8: The hard stuff

We’re heading swiftly toward the end of the term: next Wednesday is the last day of classes, and June 8 is the last day of finals. While at many times this term seemed like a colossal slog, now that we’re finishing up it seems to be moving at warp speed.

At this point in a normal term, I tend to ease up a bit. I know my students are stressed and tired (heck, I’m stressed and tired), so I refrain from assigning new, heavy things. The key focus now in Software Design is on finishing their term-long website projects, which keeps them plenty busy anyway. Integration is hard, so I want to give them the space and time to grapple with those tricky integration issues and annoying well-this-worked-before-why-is-it-crashing-now? bugs.

I’ve eased up this term, too, and perhaps it’s even more important now, as we’re all worn down by the fatigue of uncertainty, the struggles of learning in community online, and too much Zoom.

There are two course activities I typically do in the last couple of weeks in the term: a code review, and project presentations. Both, it turns out, are challenging to rework in a fully virtual environment. I still haven’t figured out how to pull off the project presentation piece, to be honest, although I really need to figure out something ASAP! But I did find a way to pull off the code review, and I’m eager to see how it goes.

Code review should be easy to pull off if you do it the way it’s normally done — as a way to review/test/try to break code for which you’ve submitted a pull request. This assumes access to a common repository and that you’re all working on the same codebase, which is not true here. My version of code review in Software Design resembles peer writing workshops. I divide students into “feedback groups” (usually two development teams per group), have them exchange code (usually a specific class and any helper classes necessary to understand that class), and have them review code more like you’d review writing. Groups project code onto one of the many monitors in the classroom and gather around tables to discuss it.

I considered several different ways to do this virtually and asynchronously, and weighed using various tools. In the end, I decided the costs of throwing yet another unfamiliar tool at my students outweighed any small benefits they’d derive from learning that tool. So students will use Google Docs, copying and pasting the relevant code into a Google Doc, and optionally applying syntax highlighting with one of the myriad tools out there. (I suggested Code Blocks, and I just found an online highlighter that actually connects to a website, unlike the others I tried.) Students will use the commenting feature to highlight and provide feedback on specific aspects of the code, and set up Slack channels in our course workspace for longer discussions about the code under review. This way, I can dip in and monitor the level, type, and content of feedback that teams exchange with each other. Which is actually a net benefit, because I’ll get much more information on how students review each others’ code than I do normally when I’m flitting around the room trying to listen in on each group’s feedback! (And I can provide a better post-mortem after the fact, using specific comments and examples.) In our synchronous class meeting today, before they start code review in earnest, I’ll have them work in teams to review a short snippet of code, so that they can practice the workflow and get feedback from me on how they’re reviewing code. I’m really eager to see how this goes.

The hard stuff, as I alluded to in the title of this post, leveled up this week, not just in my course, but in pretty much every aspect of my job:

  • I received unexpectedly bad news about my planned research project with students for the summer, and scrambled to work up a replacement project (after panicking, swearing, and throwing things, of course).
  • In a similar vein, I’m working with others on how to create a community of student researchers when they are all isolated from each other and remote. It’s not impossible, but it’s new to us and tricky to do well.
  • Students who struggled all term continue to struggle, meaning I’ve had some difficult conversations about what it will take to pass the course (even with our version of pass-fail grading, which is basically “pass with a C- or above”, “pass with a D”, and “fail”).
  • Discussions about next year continue, maybe not as fruitfully as I’d like and maybe with fewer answer and many more questions/unknowns than I’d like. It leads me to question whether the right conversations are not happening at all behind closed doors, or whether the right conversations are happening behind closed doors and the failure is in communicating this information to faculty and staff. Regardless, the end result is the same — more angst, more uncertainty, more anxiety about the future.
  • I have some big tasks on my plate — make sure research students get paid this summer (no small feat when it seems like everyone’s projects keep changing), assigning Comps (capstone) groups for next year, conducting oral exams for this year’s Comps students — that take plenty of time and mental/emotional energy, both of which are in short supply lately.

The best I can do is to do my best in managing my time and my energy levels, doing what I can when I can, and taking the time for self-care so that I can be present, mentally and emotionally, for all of the hard stuff on my plate. And to remember that now, especially, good enough is good enough. This will let me get to the end of the term in one piece, and leave me with enough emotional and mental space once the term concludes to reflect on the term and apply what I’ve learned to….whatever fall term and beyond look like.