I write down everything the students say on sticky wall pads, and volunteers help me spread these out across the room. With a 30-minute time limit, Section 1 came up with 162 items, and Section 2, 139. It's a bit tiring on the arm, but aside from deteriorating penmanship over time, it's not so bad. For voting, I give them stickers, and they mark their top five (approximately, depending on how many they generate). Some students get really excited about the stickers, and I think everyone enjoys the physicality of the process: getting up, walking around the room, placing stickers. A colleague who taught a third section borrowed parts of my exam format, but he used a Google Doc to type up suggestions, and then students marked their votes in the document. There's a sense in which this is certainly more efficient, and though I've never tried it this way, I can't help but think that it loses something.
This semester, I had two sections of the course. Section 1 generated more items and was fairly consistent with the seriousness of items. This is in contrast to Section 2, where there were a lot more silly answers, and more people talking on top of each other. This reflects differences in the two courses generally: Section 2 had many more students who were eager to talk, at both appropriate and inappropriate times.
Without further ado, the top voted items from Section 1 were:
- Clean Code (12)
- GitHub (10)
- CRC Cards (6)
- Red-Green-Refactor (6)
Clean Code was a major theme for the course, Robert Martin's book being one of our required texts. They spend a lot of time with the ideas of Clean Code, from their individual assignments to their nine-week project. Individual ideas from Clean Code inevitably show up on the lists as well, but the holistic concept tends to get a lot of votes.
I think it's important that students come around to seeing GitHub as a critical tool and not just a troublesome course requirement. In their final essays, many students wrote about how they were initially confused by git and GitHub, but after working with it, they could not see moving forward on any team project without some kind of version control. I think this is a win for the course design. I spend relatively little time showing them the details of version control, since so much of the need is contextual. I have been using git long enough that I can usually help teams back out of problems they create, or at least advise them on how best to take the nuclear option. Also, many students wrote about getting help from upperclassmen when they had repository troubles, which again speaks to a great success for the course: giving the students enough tools, understanding, and connection that they can build some networks of their own.
I assume by "Red-Green-Refactor", the students really meant "Test-Driven Development" and not just that one particular expression. As for CRC Cards, I was surprised to see them show up as a top item. I spend a little time showing them how to do early class modeling with CRC cards, and usually there's one team—or sometimes just one or two people—for whom this helps open their eyes to concepts of object-orientation. Here, six students said this was one of the most important things they did all semester. CRC Cards are a good example of an authentic activity that makes a great in-class exercise, and as I shift to including more pre-recorded video content, perhaps I should be on the look out for more exercises like this.
Along those lines, I will digress from the What We Learned to focus in on one student essay that helped me see something interesting this semester. Two weeks before the end of the semester, I had a spare meeting slot to fill. Reflecting on how students still (as is frequently the case) were having trouble following the steps of TDD, I decided to take a step back and do a workshop on problem analysis. I dug up two examples from their prerequisite courses: turning an image into greyscale and binary search. The students worked in cross-team groups to come up with a list of tasks that could be used to drive a solution via TDD. Shockingly, in the first five minutes, nobody even showed a trace of being on the right track; really, they wrote out how they solved the problem two semesters ago. I interrupted and reminded them (for surely, I had said this before) about how to use the given-when-then format to specify test, and I demonstrated with a tabular representation (which I had not done before). After this, a third of the groups headed in the right direction, and the rest eventually got there after I made them compare theirs to what others were doing. In the essay I mentioned above, a student pointed to this particular exercise as a turning point, where all the pieces aligned and she could see how to turn her struggling final project into a real example of understanding TDD. This makes me think that I need to either spend more time at the start of the semester on pure analysis outside of programming, or that I need to teach TDD more cyclically, with these kind of interventions spread throughout the semester as students are building maturity—now that I write that out, I am definitely leaning toward the latter, though the former would be much easier!
Back to "What We Learned," these were the top items for Section 2:
- Clean Code (15)
- Test-Driven Development (14)
- GitHub (13)
- Why we use object orientation (7)
- Big Picture Thinking (5)
There are two very interesting pieces here. First, it wasn't just "object-orientation" that students voted for, but the reason for it. Maybe this is just a fluke of how a student articulated their personal lesson, and then everyone else voted for it as being close, but I do think there is something more substantial and philosophically grounded here. I have the students read an excerpt from Holub on Patterns that I consider an exemplary explanation of object-orientation. In their reaction essays, most students agree that the reading was transformative to them, helping "object-orientation" move from a buzzword thrown around in prerequisite courses to a coherent design concept.
The other fascinating piece is that last one. When a student said "Big Picture Thinking" during the brainstorming session, I wrote it down, since as I told the students, brainstorming isn't a time for deep analysis and discussion but for honest and safe idea generation. Still, I didn't know what this student meant by that, not in any particular sense. Yet, here it is, one of the items with the most votes for the section. Several students chose this as a topic for their final essays, so I was able to gain some perspective on this. These students wrote about how the course helped them transition from a myopic view of programming as individual tasks to solving problems. In the prerequisite courses, they were told what to do, and they had to do it well to progress; in my course, they were given a playground of ideas and challenged to come up with something interesting to do with them. Many of these students wrote about how this experience helped them remember why they wanted to study Computer Science in the first place: so they could be creative, so they could solve people's problems, so they could be part of a community.
I think it was a good semester in CS222. I wrote several notes to myself during the semester about potential changes, and many of them still center around this "flipping" idea. As I have used more and more YouTube videos to complement or supplement class meetings—and the old ones don't go away!—it makes me realize that I don't have a very good sense of how students are using the videos as part of their process. I can see the view count, and so I know that not everyone is using them at all, even when it is "required." However, several students have also told me that the videos are invaluable. I would like to think some more about this, come up with some new plans especially for the first few weeks of the course, where I could rebalance the readings, viewings, and activities.
The other piece that still lingers in my mind as ripe for revision is one I've written about here before: the balance of assignments vs. a portfolio approach. Right now, I have the students complete three assignments, and they can revise them as often as they need in order to show mastery. Their solutions draw from a wide variety of programming experience, but this means that there is a lot of variance in student experiences with the assignment as well. That's somewhat problematic, as a major point behind individual assignments is to ensure individual students have common foundational knowledge, since the nine-week project gives lots of room for variation. I keep returning to the idea of portfolios: what if each student had to prepare a portfolio that included examples of their ability to, say, refactor a method with too many parameters, or apply the Single Responsibility Principle? I'm just not sure how I would manage it, in part because the course already requires quite a bit of grading time, which eats away at other responsibilities.
Next semester, I have three different courses. I am teaching one section of CS222, I have my Game Studio course, and I have a brand new course: CS691 Software Requirements and Design. With the winter break being so short, I am still not sure if I will do any structural revision to CS222 for the Spring. It's also winter break, and I should be spending quality time with my wife and sons. Come back in May, and I will write about what students learned in the Spring semester, regardless of whether I shake it up or not.
Thanks for reading! As always, feel free to leave a note in the comments.
No comments:
Post a Comment