Students (and people in general) respond well to having their achievements acknowledged through feedback (Pilcher, 2018, p. 59). Goodwin and Hubbell expand on this noting teachers should link their feedback to learning objectives and make it growth oriented (Goodwin & Hubbell, 2013, p. 90-104). They also begin the chapter noting one of the most extensive feedback engines ever to have been created: video games.
Players now instantly when they've done well and when they've done poorly. As a result, they can select restart and jump right back to it, something we as teachers so very desperately want of our students efforts. However, we aren't talking about a game, we are talking about the classroom! Well, Jane McGonigal highlights in her book, Reality Is Broken: Why Games Make Us Better and How They Can Change the World, that effective modern-day game mechanics and feedback require good game communities (2011, p. 230) and what is a classroom but a community? For anyone considering using gamification in the classroom, this is a definite must-read to add to your queue.
In terms of our classroom, John Hattie found feedback to be quite effective with a size of .70 (Visible Learning, 2018). While there of plenty of factors on his list with higher effective sizes, feedback is not one a teacher can do without, making it a critical component worth understanding.
Before getting into my feedback strategies, there are some important things to note regarding feedback. Possibly the most important: praise the effort, not the intellect! By praising a student for their smarts, we are issuing compliments on something we are perceiving them to be which leads to a host of issues including handling setbacks poorly, problems of motivation as they should just "get" the information, increased instances of cheating, and unintentionally belittling students who aren't told they are smart (Tenney School, 2017). Basically, because we are focusing on something a student "is" we are ignoring the most important aspect of what they can become. Essentially undermining a growth mindset in our students.
Another thing to be mindful of being intentional about the a student's work. We need to keep the feedback related to that work in particular and not compare the effort to other student work (Black & Wiliam, 2010). Otherwise we run the risk of marginalizing a student's effort and potentially effect how much of it they are willing to give going forward. Pilcher recommends we focus on performance in particular, which aligns with some of the other touchstones already covered (Pilcher, 2018, p.61).
There are two feedback methods I make heavy use of in my computer science courses. The first is direct feedback to student code with reviews using Loom, a freemium screen recording browser extension. Rather than print out the code and break out the red pen, I go through the code live and talk to them about their code. This makes for a highly personalized experience (see the last section on interacting meaningfully with my students) where I can talk almost directly to my students about their efforts, habits, and what they need to work on to improve their performance.
To be honest, this was a happy accident; I started recording my classroom lectures for student to review later so I had the recording tool at my disposal. Then one evening, a student was working on an assignment from home and she asked for help. There were many little issues that needed addressing that attempting to highlight or explain each one by email was, well, terribly inefficient. So rather than spin my wheels and only likely confuse my student, I took to the screen recording software. Her understanding skyrocketed with that feedback method, so I decided to try it out on a few other students. Huge successes with them as well, so I've been doing it since. Because this feedback is usually focusing on things gone wrong, I take extra care to being positive and supportive throughout the recording.
The second strategy is something Code.org calls paired programming (Code.org, 2019). Students are grouped in two's (or sometimes three's) and a driver is designated to take the seat the keyboard to do the coding. The other student(s) is the navigator making suggestions on things to try and how to problem-solve the issue at hand and then the roles periodically switch. This method provides students with the chance to give each other near real-time feedback increasing the achievement they both can accomplish (Tsompanoudi, Satratzemi, & Xinogalos, 2015).
Similarly, I will have students review peer review programs written by other students. Like teachers, students need some coaching on how to provide constructive feedback to be effective. While taking some time in class to this is certainly worthwhile, another way to tie this back to the learning objectives is to have students rate the work based on the provided rubrics. By doing so, students are forced to think more concretely about the performance objectives (assuming the rubric was designed as such, of course).
One last note, teachers need provide timely feedback and coding is no exception. If you have the pleasure of teaching a CS class, then you are likely already aware of how coding concepts only build as the course progresses. Timely feedback ensures we help students with the mistakes they are making now and increase the likely-hood of them not making them going forward. Goodwin and Hubbell note there are different levels of immediacy depending on the learning task at hand (2013, p. 99-102). For example, they recommend immediate feedback when learning a new process and after quizzes but no more than a few days after a test (because what is the use of reviewing a test weeks after it was given?)