Once again, my CS222 students made lists of what they learned in the past semester and voted on the most important items. I taught two sections, and their top items are similar; I'm listing the item as well as the vote count.
10AM Section:
- Single Responsibility Principle (9)
- Test-Driven Development (9)
- Team development (6)
- Refactoring (6)
- GitHub (6)
Noon Section:
- Learning from failure (13)
- Clean Code (11)
- Single Responsibility Principle (8)
- Test-Driven Development (8)
- Group programming / team-oriented development*
* There's no vote count on this item because these two were combined after voting.
"Failure" came up as an item in the 10AM section, but it received few votes. Someone in the noon section articulated the same phenomenon as "Learning from Failure," and it got the most votes of any single item. Indeed, learning from failure came up in many final essays from both sections, and it is always a strong theme in the course.
Another interesting note about the final exam: for the first time, I heard about a student who read my blog to try to figure out what to expect on the final.
As I wrote about earlier, I introduced a few changes this semester. One of the most significant was that I replaced the overall grading scheme: previously, I took a grade as a maximum across several categories, but I switched to a model where everything contributed. I like the philosophy of the max-based grading: you're only as strong as your weakest category. However, this did cause students to lose heart when they fell behind in one category, after having spent a lot of effort on a different. This semester I used a more conventional scheme, like this:
- Final Project (50%)
- Final Exam (5%)
- Assignments (25%)
- Achievements (20%)
Those numbers are not arbitrary: I based them off of imaginary worst-case scenarios. (It may be helpful for this discussion to remember that I am using triage grading, not the arbitrary historical accident that is the 90=A, 80=B, etc..) If a student did everything perfectly except achievements, they would earn at most a B. Similarly, no assignments results in a max of B-, and no final project is D+. I didn't perceive the problem of student frustration as with the max-based system, but I still feel uneasy about this other model. I'm not sure how to combine the two models except with something more like contract-based grading. That is, I could set up a series of rules, such as capping the grade at B+ if you do no achievements, or capping the grade at D if you do not get satisfactory scores on each assignment.
The switch to GitHub went fairly well, although I am sure I can clean up a few loose ends. I plan to record a few extra instructional videos about recommended workflows as well as how to deal with merge conflicts. It was definitely less flaky than using our departmental-hosted Redmine server, and the difference between git and Mercurial was nominal for the students. I still prefer the Mercurial command line, but I am growing accustomed to git's, and I've come to really like the ease of interactive rebasing to clean project history.
Since I have been using IntelliJ IDEA Community Edition in my personal work since summer, I am seriously considering having students use this instead of Eclipse in the Spring. They barely know Eclipse coming out of the prerequisite course, so I am not too worried about cognitive load. This will make it easier for students to pick up Android Studio if they want to, and I really prefer the git integrations of IntelliJ. The only real downside is that IntelliJ's compiler warning reporting is much easier to overlook compared to Eclipse's, and it's already hard to get students to recognize that these warnings need to be addressed.
I have been using a model of assignments inspired by mastery learning: I give three assignments—one during each of the first three weeks of the semester—and students can resubmit them up to once per week until they get full marks. Again, I like the philosophy of this model, but the execution is still troublesome. The problem is not so much in the submission/resubmission policy but in the breadth of the assignments. Each has a similar form: go find some source code and apply a subset of Clean Code rules to it. I think what's happening is that stronger students already have the ability to read a difficult text, parse it out into manageable pieces, and then apply those pieces to a new context. They usually get it wrong here and there, and with some guidance, show that they have learned it. The academically weaker students struggle in many more ways, though: in addition to the inherent difficulty of the material, they also have difficulty reading complex texts, analyzing artifacts, and having a sense of focus. It has made me wonder if I should move to portfolios instead of assignments. That is, rather than proverbially throw students into the deep end to sort out Clean Code rules, what if I made a list of criteria, such as, "Refactor a variable name" and "Refactor to extract smaller methods from a long method." This could potentially help scaffold the weaker students: they would have these criteria at the time of reading Clean Code, and this could help guide their attention. When they are looking at code, they would not have to try to remember all the relevant Clean Code rules in their heads, but could instead look just for items that matched the criteria.
I am excited about the idea of portfolios in CS222, but there is no clear best technological platform to support this. I am tempted to try to do it on GitHub using MarkDown since that would eliminate any problems with students using bad document formatting. I am leaning toward a solution like what I use for achievement submissions: make a form on Google Drive that sends data to a spreadsheet that students can see, with students submitting links to portfolio documents; record my evaluations in that sheet; use a pivot table to summarize how many "portfolio points" a student has earned. This would be completely outside of Blackboard, so I would have to copy the scores at the end of the semester, and students would have to go to the sheet to see their current tally, but I think these are fairly small costs.
I didn't do quite as much blogging this past semester as I had hoped to, but I am happy with the other work I got done. I have not made the opportunity to write about how I got involved in the Interactive Learning Space initiative, but suffice it to say that I'll be able to teach CS222 in an interesting new space in the Spring. The room has easily movable chairs and tables, multiple projection surfaces, and—really strange for my building—natural light!
That's it for this end-of-semester report. I'm still having a lot of fun with CS222, a course that is working really well despite my constant tweaking.
No comments:
Post a Comment