The Art of Giving Useful Feedback on Pull Requests

From Picky to Productive: Mastering Feedback on Pull Requests

While providing feedback on pull requests can be an important part of improving code quality and promoting collaboration, there are also some potential pitfalls to be aware of. Here are some of the most common ones:

Being too critical or negative: When giving feedback, it’s important to strike a balance between being honest and constructive, and being overly critical or negative. If you come across as too harsh, you risk demotivating the person who submitted the pull request, and may discourage them from participating in future projects.

Not being specific enough: Vague or unclear feedback can be frustrating for the person receiving it, as they may not understand what they need to do to improve the code. Always be as specific as possible when giving feedback, and provide concrete examples of what needs to be changed.

Not providing context: Providing context for your feedback is important, as it can help the person understand why certain changes are necessary. If you don’t provide enough context, the person may be confused or frustrated by your feedback.

Focusing too much on personal preferences: While everyone has their own coding style and preferences, it’s important to focus on the overall quality of the code, rather than on personal preferences. If you focus too much on personal preferences, you may miss important issues with the code that need to be addressed.

Not considering the bigger picture: When reviewing pull requests, it’s important to consider the bigger picture of the project, and to understand how the code fits into the overall architecture. Focusing too narrowly on specific issues with the code may lead to missed opportunities for improving the project as a whole.

Not following up: After providing feedback, it’s important to follow up with the person and to ensure that they understand your suggestions. Not following up can lead to confusion or misunderstandings, and may prevent the person from making necessary changes to the code.

By being aware of these potential pitfalls and taking steps to avoid them, you can ensure that your feedback is constructive, effective, and helps to improve code quality and promote collaboration.

What are some example of bad PR feedback?

Here are some examples of bad PR feedback:

Vague comments: Comments like “This code doesn’t look right” or “I don’t like this” are not helpful as they don’t provide any specific information on what’s wrong or how it can be improved.

Insults or personal attacks: Using language that is insulting or disrespectful is never appropriate and can be hurtful to the person who submitted the PR.

Overgeneralizations: Statements like “This is all wrong” or “This code is terrible” are not helpful as they don’t provide any specific feedback on what needs to be improved.

Demands without explanation: Simply demanding changes without explaining why they are needed can come across as aggressive and can discourage the person from making any improvements.

Making assumptions: Making assumptions about the person’s coding ability or intentions can be unfair and may lead to misunderstandings. It’s always best to ask questions and clarify before making any assumptions.

Not offering alternatives: If you suggest changes, but don’t offer any alternatives or options for the person to consider, they may feel stuck and unsure of what to do next.

Remember that the goal of providing feedback is to help improve the code and the overall project. Being respectful, specific, and offering constructive feedback can go a long way in achieving this goal.

What are some examples of good PR feedback?

Here are some examples of good PR feedback:

Clear and specific comments: Point out specific parts of the code that need improvement and explain why they need to be changed. For example, “Line 15: the variable name is confusing, please use a more descriptive name to make the code more readable.”

Positive reinforcement: Highlight what the person has done well, such as “I really like the way you’ve structured the code, it’s very easy to follow.”

Providing context: If there are any project-specific considerations or design decisions that the person may not be aware of, provide them with this context to help them understand why certain changes are needed.

Collaborative tone: Use a friendly and collaborative tone to encourage the person to work with you in improving the code. For example, “I think we can make this function more efficient, what do you think?”

Suggesting alternatives: If you suggest changes, offer alternative solutions that the person can consider. For example, “Instead of using a for loop here, have you considered using a map function? This could simplify the code.”

Asking questions: If you are unsure about something, ask questions to clarify. For example, “I’m not sure why you decided to structure the code this way, can you explain your reasoning to me?” This can help to foster a productive discussion and lead to a better understanding of the code.

How do you politely disagree with PR comments?

When you receive feedback on a pull request that you disagree with, it’s important to respond in a polite and professional manner. Here are some tips for how to do this:

Thank the person for their feedback: Even if you disagree with the feedback, it’s important to show appreciation for the time and effort the person took to review your code. Thank them for their feedback and for taking the time to review your pull request.

Explain your reasoning: Clearly and concisely explain your thought process behind the code in question. Provide any relevant information or context that the person may not be aware of. This can help the person to understand your perspective and why you made certain decisions.

Be respectful: Maintain a respectful and professional tone throughout the conversation. Avoid using language that is dismissive or condescending, even if you strongly disagree with the feedback.

Offer alternatives: If you disagree with the feedback, offer alternatives or solutions that you believe are better. This can help to move the conversation forward and lead to a more productive outcome.

Ask for clarification: If you’re unsure about the feedback or why the person made a certain suggestion, ask for clarification. This can help to ensure that you understand the feedback correctly and can respond appropriately.

Seek a compromise: If you and the person giving feedback are unable to agree on a particular issue, seek a compromise that you can both live with. Look for a solution that meets both of your needs and achieves the desired outcome for the code.

Remember, the goal of receiving feedback on a pull request is to improve the code and the overall project. By responding politely and professionally, you can help to ensure that the feedback is constructive and leads to meaningful improvements.

What are some strategies for not taking negative or hostile PR comments personally?

It can be challenging to receive negative or hostile PR comments without taking them personally. Here are some strategies that can help:

Recognize that the feedback is about the code, not you: Remember that the person giving the feedback is commenting on the code, not on you as a person. They may be providing feedback on something they believe can be improved, and it doesn’t necessarily reflect on your skills or abilities.

Take a break: If you find yourself becoming upset or emotional after receiving negative feedback, take a break. Step away from the computer and do something else for a while. This can help you to gain perspective and approach the feedback in a more objective way.

Seek out a different perspective: If you’re struggling with negative feedback, seek out the opinion of someone you trust who can provide a different perspective. They may be able to offer some insight into the feedback and help you to respond in a constructive way.

Remember that feedback is an opportunity to learn: Even if the feedback is negative, try to see it as an opportunity to learn and grow. Feedback can help you to identify areas for improvement and become a better developer.

Don’t take it personally: Finally, remember that not everyone will like your code or agree with your approach. Everyone has their own opinions and preferences, and it’s impossible to please everyone all the time. Don’t take negative feedback personally, and instead focus on the constructive elements of the feedback that can help you improve your code.

Summary

In summary, providing useful feedback on pull requests is an important part of improving code quality and promoting collaboration within development teams. By following the tips and strategies outlined in this article, developers can learn how to provide constructive feedback that helps to identify areas for improvement, while maintaining a positive and collaborative environment. Whether you are giving or receiving feedback on pull requests, it’s important to keep in mind that the goal is to improve the quality of the code and the overall project. By working together and embracing a culture of constructive feedback, developers can create high-quality code that meets the needs of their users and stakeholders.