Last semester I wrote about how I was introducing my students to code review. I thought it worked pretty well and was anxious to try it again.
Well, I did the lesson(s) again this past week and it looks like it's a keeper. The setup was pretty much the same with some hiccups due to using a new platform. Last semester I used plain GitHub public repos. This time, I've been using GitHub classroom which I like very much but I forgot that I made this assignment use private repos which turned out to be a hassle.
If you didn't read the previous post the short version was:
group the kids in two's
Each does a written (no talking) code review on the others previous lab. Very little guidance was given as to what the review should look like.
We then did two parings where one person talked through a live code review with the other.
Finally, we did one more written session.
This left person with three reviews.
This took the whole class since we had to finish some other material before starting the reviews.
As a follow up assignment, they're going to add a feature to another student's solution to the lab they reviewed.
It seems that the class was effective when I taught it last semester. I've come to that conclusion because I'm teaching that group again in their Data Structures class and they seem to do better with Pair Programming (which I related to a live, real-time code review) and it does seem that they're paying at least a bit more attention to the issues we highlighted in the code review lesson.
I won't get the same chance to follow up with this group but I can at least see in the next few weeks if it had any positive affect. One of the things I'm curious about has to do with the student's backgrounds. Last semester's students all had a year of APCS-A under their belts before coming to Hunter. This semester's students had a range from APCS-P to a summer or after school program to nothing and their last semester class with me was in my opinion a much lighter programming class than a year of APCS-A. I'm wondering if the current crop, having written fewer large programs will have a different appreciation for the topics we discussed during the code reviews.
All of this got me to thinking about some of the things I saw both at SIGCSE and on some of the posts that followed. Specifically about teacher vs researchers and also, although not mentioned, K12 teachers, teachers at the college level and researchers.
I was thinking about the fact that this is one of the ways I work to improve at my craft. I try something, evaluate and reflect on the results, then repeat, tweak etc. Not everything I try is a winner but overall I think I've made a pretty steady progression as a teacher.
I was also thinking that had I done this while in High School I would have taught the lessons two to five times to similar but different groups of students within a short period of days. I would also have been able to iterate, possibly with variations, each semester. It might not be instant but that's a lot of potential feedback. At college, I'm only teaching one section of each class and I'm guessing that most full time faculty members might only teach two of a particular class (although I could be very wrong - I just based this on looking up a few schedules). I also don't see my kids every day. This makes for a slower, less effective feedback loop. On the other hand, I'm not running pillar to post every day so can actually take the time to evaluate what's been happening in each class in arguably a more meaningful way.
All of this is to say that most teachers I know trust other teacher's experiences rather than "the research" and that was also what was born out in this University of Colorado survey. While there are plenty of bad teachers who know that "it's always been done this way and it's worked well enough" I'll always consider my most trusted education resource to be a thoughtful, reflective, experienced teacher who actively works on improving at their craft.
This is not to say that there isn't merit in research. I saw presentations at SIGCSE and on the one had said to myself "ok, so he discovered something that any moderately experienced K12 teacher already knows" and at the same time thinking "but it's great that they're now formalizing and documenting it." There are also things that can be researched that a single classroom teacher just can't approach and finally, to paraphrase a line from Mark Guzdial's talk where he specifically addressed other CS Ed researchers - we can build things and they need things built - a teacher / researcher partnership can open a lot of yet unexplored doors for educators.
It's all a reminder that we're all playing different roles. Researchers aren't teachers, college teachers aren't K12 teachers, K12 teachers subdivide further and of course the same holds for the reverse direction. Sure there are similarities in our goals and our roles but there are some important differences.
With that in mind, I'll leave this with a quote form one of the all time great screwball comedies:
<iframe width="560" height="315" src="https://www.youtube.com/embed/Hl9OzCY9fVE?start=116" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>