Giving Feedback

A vital part of the Creative Components in this course is learning how to give and receive feedback. As such, we will provide some clarification here for how we will structure feedback exchange in this class! You will be assessed for giving considerate and actionable feedback, meaning that your comments will ideally be respectful and relevant to the component you are reviewing!

Feedback Framework

In CSE 163, we will use the I Like, I Wish, What If framework to structure how you exchange feedback with your peers. You will typically be asked to write two of each statement per assigned review.

I Like…

“I Like” statements are positive observations about what works well in your peer’s submission. These comments highlight strengths, effective choices, or other conceptual or coding aspects that stood out to you. Focus on specific elements rather than general praise, such as noting a clear coding task description, a creative approach to solving a problem, or well-organized code structure. They do not have to start with the words “I like” verbatim, but we find that this can be helpful for structuring your comments! Here are some examples of effective “I Like” statements:

  • “I like that your documentation for <function_name> clearly describes the keys and values in the returned dictionary.”
  • “I like that your local variables are well-named and descriptive, which makes it easier to follow what is happening to each value in your function.”
  • “I think your use of a helper function for this task was really cool because it breaks up the problem into more approachable steps and makes your code more readable.”

Here are some examples of less-effective “I Like” statements:

  • “Wow, this was a really cool problem!” (Not specific about what you think was cool!)
  • “I think your documentation was good.” (Also not very specific—what makes it good?)
  • “I like the solution that you wrote here, but I think it would have been better if you used a set instead of a list.” (Constructive feedback should go in an “I Wish” statement)
  • “Your solution is a lot better than mine!” (Focuses on comparison to yourself rather than focusing on your peer’s work)

I Wish…

“I Wish” statements are constructive suggestions for improvement. These comments identify areas where your peer could enhance their work, expressed in a respectful and supportive manner. Rather than simply pointing out what’s wrong, frame these as opportunities for growth. For example, you might wish for more detailed comments in the code, clearer variable names, or a more thorough explanation of their approach. Here are some examples of effective “I Wish” statements:

  • “I wish there were more comments explaining the purpose of each function, especially for the data processing steps.”
  • “I wish the edge cases were handled more explicitly. Like, what happens if the input list is empty?”
  • “It would have been cool if your explanation included more detail about why you chose this particular approach over alternatives.”

Here are some examples of less-effective “I Wish” statements:

  • “I wish you didn’t use this approach to your coding task because it’s not very efficient.” (Doesn’t offer specific feedback or where the inefficiency comes from)
  • “I wish your code wasn’t so messy.” (Not very constructive, and also not clear about what needs improvement)
  • “I wish you had actually finished the problem.” (Also not constructive; it is sometimes possible that you may see “works in progress”, but your feedback should focus on helping your peer grow and complete the task rather than putting them down for any perceived deficiencies)

What If…

“What If” statements are exploratory questions that encourage your peer to think differently or consider alternative approaches. These comments open up possibilities and invite creative thinking without being prescriptive. You might suggest different ways to structure their solution, alternative methods they could explore, or extensions they could consider for future work. It’s OK if your ideas are a bit wacky or half-baked, but try to keep it relevant to your peer’s work! Here are some examples of effective “What If” statements:

  • “What if you used a dictionary instead of nested lists to store this data? It might make lookups faster.”
  • “What if you added a case to return None for non-integer inputs? Then you could handle invalid inputs.”
  • “What if you visualized this data as a scatter plot instead of a bar chart? Would any patterns become clearer?”

Here are some examples of less-effective “What If” statements:

  • “What if you did a completely different task?” (Not relevant to the work your peer has done)
  • “What if you completed the problem by doing [very explicit instructions for completion]?” (Prescriptive rather than suggestive; these statements are meant to encourage exploration and/or revision, rather than you instructing your peer!)
  • “What if you did things the right way?” (Implies that your peer’s approach is wrong without offering alternatives)

Peer Review Grading

Typically, you will be responsible for reviewing 2 of your peers’ work per THA. Your review will be graded on thorough and thoughtful completion. The peer review is part of your own THA grade, which is why it’s important for you to turn these in on time! You will find the links to individual spreadsheets and Gradescope assignments in Canvas this quarter, and they will be released after the initial due date of their respective THAs.