I want to know if there is a place to discuss/offer suggestions to help improve the code reviews workflow. I am having the challenge of finding the right solution for the workflow. I am having the problem that some students finish faster than others or students are absent in class. With small code review groups in a small class, there is often the case where someone isn’t getting their code reviewed. Then I must change the code review groups per class. Or I put them into a large group and then there is the risk of people not getting their code reviewed.
What I would like is just a general queue automatically to get assigned someone else’s work to review. This I think would work out well whereby the students who are most comfortable and are writing the most unique code, can get their code reviewed by someone else who finished quickly and can give deeper feedback.
This is just my thought. I love the idea and they are super important, and I don’t want to start abandoning them every lesson. But I just find them to be a bottleneck in the lesson. Especially because I am trying to do 2 lessons a day per my schedule.
Hi MJ,
Thanks for starting a discussion about how to manage code reviews! I have also had the experience of having the reviews create a bottleneck. I’m interested in hearing others ideas and solutions to this issue.
One thing I have done it to put all of my students into one big group when setting up the code reviews in the manage students area. I then see who is present that day in class, and as we are moving towards the time for the review, I write pairs of students on the board. Students are to review the person’s code who they are paired with on the board first, and then they can choose to review anyone else’s on the list after they do that first review.
I also found that if students clicked close review too soon, before the others in the process of writing feedback clicked submit, that the reviewer then got an error when they clicked submit. For the last code review I set a timer on the projector for 8 minutes and directed students not to click close review until the timer had gone off.
@mjlinane, thanks again for bringing this up. While code reviews are valuable, accommodating for students that move thru lessons at a different pace and absent students is always a challenge we teachers face.
I like @lindsay.davis 's suggestion of writing pairs on the board and then have the students pick someone else. My entire class is in one big code review group. I have just had students review their table mate’s work and then if there is a group of three have them work out who will review each others code.
I like following the curriculum as closely as I can but I wonder about having a code review day or half day. Maybe wait a few days to make sure a majority, if not all, of the students are done with a code review level and have the whole class flow back and do a code review. I have done done this and this is just a thought that I welcome feedback on.
Thank you for the suggestion. I am open to any ideas, and I have considered putting them in a large group on code.org and I like the idea of putting pairs on the board to streamline my matchmaking job class to class. Can I ask how many students you have and how long are your class periods? Just trying to get a sense if this would work for me.
Thank you, Sam, for offering your suggestion. I try to follow the curriculum as closely as I can because I know how well the course is designed. I just tried your suggestion, to wait a couple of days to ensure that everyone is completed with a stage before doing a code review. It worked out well and it carried the added benefit of ensuring that students are not just copy/pasting code that they see in a code review if theirs’ isn’t finished.
Alternatively, this week, I have also done a code review on the Background Painter activity even if students were not finished. That way, folks who were still working on the problem, could get a solution for that lesson and yet the problem wouldn’t compound when they tried to do the asphalt painter project. Personally, I feel like this option should be used rarely because it is a short-term solution. But it could be something I would reserve for a lesson that isn’t as important for the students to full code individually, like the BackgroundPainter. It is my feeling that if a student can code a child class with the PatternPainter, they can code the BackgroundPainter as well.
Time is always going to be our enemy and I feel like a strict, synchronous, code review every class is going to be impossible for me to adhere to.
I like the idea of giving more time to students before working on the code review. I have already finished unit 1, but/and I plan to think about how to do code reviews during the unit 2 project. I might start the project on day 1, and then do the FRQ day, and then come back to the project. This would allow another day of at home coding/ extra time after the FRQ for students to be more ready with their code for the review
