Giving feedback well (and receiving it) is an important part of working in any team. Good communication is something you can work on. Giving good feedback is important for your colleagues or if you are a mentor or teacher in the future. Many teacher training programs (and HR) include strategies to do this. The literature is extensive on this topic so here are a few of the main strategies.
Sandwiching
Say something nice first. It’s a lot easier for them to take criticism if you meet them halfway. Say what they’ve done well or why their contribution is a step in the right direction. You won’t come across as so negative or excessively critical.
Thanks for your hard working this. I think it’ll be great when it works. We’re almost there. Here’s a few minor problems we need to touch up...
Give clear actionable feedback
Vague criticism is not helpful for anyone. If you see a problem, point out specifically what it is and why it needs to be addressed. If you can, suggest possible directions that could be taken to fix or improve it.
Code is a great example for this as you can point out exactly which lines are problematic. Then you won’t waste anyone’s time looking for the problem. Tools such as GitLab also allow you to edit each other’s code before you merge. It is expected that pull requests will be discussed and problems will be addressed before merging the code. You don’t submit a pull request when it’s ready to merge, you submit it when you’re ready to get help and feedback on it.
You’re a much more friendly reviewer if you offer to help, even in small ways. You should encourage others to submit their work for review early, rather than later. Getting feedback from the team is an important part of the project and giving harsh criticism will delay the project. If team members try to get things perfect on their own, it will take longer than if you troubleshoot issues together.
Give the Benefit of the Doubt
You might not know the whole situation so try not to assume why there’s a mistake. It could be an honest mistake. They could be out of their area of expertise. Whatever the reason, it doesn’t matter. You can ask if they had any problems they need help with or let them volunteer that information if they’re ready to. However, don’t assume that they’re out their depth just because they made a mistake. These happen to all of us.
Don’t dwell on why there’s an error. Point it out and move forward. Discuss how to solve it together.
Explain the error politely and respectfully. Don’t question their expertise or criticise them personally.
They likely have no idea that there’s an error in their code. They could well know how to fix it on their own if you draw attention to it. In this regard, if you do it kindly, you are helping them simply by drawing attention to a problem they didn’t know needed to be solved (these sorts of things are often discussed in the Issues of a GitHub repo).
Use it as a Teachable Moment
This is an opportunity to learn from each other. If you explain the problem clearly, they may be able to avoid making similar mistakes in the future because they know understand why what they did was problematic. If you ask them why they did it the way they did, you could also learn about their coding style and what they were attempting to do with it.
You can also suggest ways to improve their workflow to avoid problems like this in the future or so they can identify them themselves. You can suggest things like 1) commit more often so you can revert changes 2) track changes in a dedicated branch 3) write functions to avoid copy-paste or human errors 4) write unit tests to ensure functions are doing what you expect 5) document functions and comment code do others can understand what it does (and why).
There is a lot of literature on best practices for writing code. You can share such resources to help them improve. You can also discuss coding practices with your team as you may have different skills and experiences. If you can agree on shared conventions then it will be easier to work together. It’s also an opportunity to learn from others in the group who may have more experience with different tools.
Means of Communication
Forums such as GitLab and Slack are designed to give feedback to the entire team. I would encourage this. Many teams even do this completely public on GitHub. This lets the entire team know the situation and they can step in to help if they understand the problem better.
If you are worried that it’s a simple mistake, you can contact them directly and point it out so that they can address it without the rest of the team knowing. It depends a lot on the situation. If you do it respectfully, it shouldn’t be a problem for the whole team to know. We all make mistakes and a team with good communication will be understanding that it’s a work in progress. If your feedback it too cruel or unkind that you don’t want other members of the team to see it, you probably shouldn’t send it at all or think about how to give more constructive feedback.
I would recommend to give public feedback to the entire team unless there’s a good reason not to. Communicating privately should be the exception.
Be aware if power differences, even small ones. As a reviewer (or mentor), you’re in a position where your opinion is respected. They need your approval to merge their contribution. Be kind, patient, and understanding. Be aware that they may be shy to admit mistakes around someone they may perceive as more skilled and doesn’t make such mistakes. You can share some of your similar mistakes and experiences to show that you’ve done similar things to them before. Explain why you know it’s a mistake.
You should take another look at that part there. I did a similar thing and it lead to problems later on when we tried to do other things.
A good team member or mentor is someone you feel open to communicate with freely and whose advice and criticism is valued. As a reviewer, you should aspire to do this. It’s an opportunity to develop skills useful in your career.
