Saturday, December 21, 2019

Back in the Saddle: Preparing to teach CS222 in Spring 2020

I taught CS222 for many semesters in a row, and then I was surprised to get a semester's reprieve in Spring 2018. Imagine my surprise when this reprieve extended through Fall 2019! Now, after several semesters away, I'm scheduled to teach CS222 again in Spring 2020. I want to share here some of the changes I've made and what I'm hoping to accomplish. I am excited to teach this class again: it is a formative experience for our majors at an inflection point in the curriculum, and I think it plays to many of my strengths.

There are a few relatively superficial changes in the course plan that I have put online. I added "The Big Idea" section to the main overview page. This was a direct response to doing a routine evaluation of a colleague's course plan. Our committee uses a form to drive the review, and one of the questions on the form asks whether the instructor has any statements about their goals for the course, separate from the catalog description and departmentally-approved learning outcomes. I realized that I frequently talk about such things but did not have them in writing. "The Big Idea" section describes how CS222 is positioned in the curriculum and what I hope students get from it.

Another addition to the course site is the Tips page. This section began as a short collection of writing tips meant, primarily, to help students understand what I mean by the word "essay." It is one of those words that has unfortunately been beaten senseless by the educational establishment. As I worked on this section, it grew to include an excerpt from the 1920 edition of The Elements of Style and some process advice adapted in part from Jordan Peterson's. I tacked on a few programming tips that I often share with students. I am still tempted to add more to it, including tips for how to take notes during meetings and from reading. I realize, however, that if students don't read the course plan, then I'm writing more for me than for them. I expect to keep adding to this page as the semester progresses, monitor whether students reference it in their speech and writing, and ask them about it a few weeks into the class.

I seriously considered dropping the whole Achievements system that I innovated in this course some ten years ago. I love the idea that students have agency in deciding what to pursue, but I don't like the idea that students who are already bad at time management can easily dig themselves into a hole. I decided to keep the system with a few tweaks, although it's hard for me to explain why. I am afraid it is inertia. The major change I made to the achievements system was to formalize the levels of validation into "stars": a student can turn in anything they self-validate for one star, or they can get a peer validation for two stars, or they can get me to validate it for three stars. The most efficient path, then, is to do something well, get a peer's and then my validation, and then get three stars in one submission. We shall see if students go this way, or if anyone purposefully hammers out sequential low-quality one-star submissions.

I want to spend more time working with students in class on refactoring exercises, making sure I help them both see the affordances for action and learn the techniques required to perform the refactoring. To this end, I have prepared a series of relatively simple example programs that we will work on in class. This means less of my show-and-tell and more students getting their hands dirty.  This should help impediments and confusion rise to the top, where ideally I can act on it. Right now, there are only about twenty students in the class, which is much more manageable than filling the room to its ~35-person capacity.

As I wrote about in a Fall semester reflection, I noticed that my students in upper division courses do not understand version control. Students in Game Programming talked about version control as if it were just for back-ups, and my HCI students admitted to being terrified of pull requests. I plan to do more careful scaffolding around git and version control this semester, with more structured exercises both in- and out of class. I have not designed these interventions yet.

I would like to keep the schedule where the first three weeks introduce the major topics, the next two are spent in a rigorous, well-defined project, and the last nine weeks are spent in three three-week iterations of an open-ended project. I am still not sure how to align this goal with the more structured activities I want to add except, perhaps, to make the two-week project much more tightly connected to in-class activities. That is, I can make it almost more like a lab than a project. For example, on a given day, I could introduce the idea of a merge conflict, and then we could actually make one in our projects. I have not set aside the time to plan this part of the course yet, following the design dictum that one should put off design decisions to the last responsible moment: if I can get to know the class a bit, then I can put together the two-week project as we need it, once I have a sense of how they are responding to the other material. If we need to cut a week or two from the major project, I am not opposed to that either: we can always cut it to three two-week iterations, for example.

Many years ago, I requested to only teach this course in 75-minute blocks. This means it would be offered Tuesdays and Thursdays instead of Mondays, Wednesdays, and Fridays. I have taught it in 50-minute blocks before, and I found that we would always get interrupted in the middle of a complex activities. Unfortunately, the administrative staff in charge of scheduling forgot about this request and gave me the MWF schedule. It will be convenient in some ways, since my other class is MWF mornings and this will be MWF afternoons, but I remain concerned about the level of depth we will be able to get into in any given class meeting. I hope that my targeted exercises and careful planning will give us tight learning loops rather than interrupted longer loops.

Thanks for reading. Feel free to check out the course plan and let me know if you have any thoughts, feedback, or suggestions.

No comments:

Post a Comment