What do you do if your colleague's code needs improvement?

1 Be respectful and empathetic

Before you criticize your colleague's code, try to understand their perspective and context. Maybe they had a tight deadline, a complex requirement, or a lack of resources. Maybe they are new to the technology, the project, or the team. Maybe they have a different background, experience, or education. Don't assume that they are lazy, incompetent, or careless. Instead, acknowledge their efforts, strengths, and challenges, and express your desire to help them improve.

2 Be specific and objective

When you give feedback, focus on the code, not the person. Avoid vague, subjective, or personal comments, such as "this code is bad", "you don't know what you're doing", or "you should learn how to code". Instead, use concrete, objective, and measurable criteria, such as "this code has a high cyclomatic complexity", "this code violates the SOLID principles", or "this code has a low test coverage". Provide examples, evidence, and data to support your feedback, and use the

tag to highlight the relevant code snippets.
###### Be positive and supportive
When you give feedback, balance the negative with the positive. Don't just point out the problems, but also praise the good aspects of the code, such as "this code is well-documented", "this code is modular", or "this code is performant". Also, don't just tell your colleague what to do, but also explain why and how. Provide suggestions, alternatives, and resources to help them improve their code, such as "you can refactor this code using this pattern", "you can use this tool to analyze this code", or "you can check out this article to learn more about this concept". Finally, offer your assistance, encouragement, and appreciation, such as "I'm happy to help you with this code", "I'm impressed by your progress", or "I value your contribution".
###### Be timely and consistent
When you give feedback, don't wait too long or too short. If you wait too long, your colleague may have forgotten the context, moved on to another task, or become attached to their code. If you give feedback too soon, your colleague may not have finished their work, tested their code, or solicited other opinions. Ideally, you should give feedback as soon as possible after the code is completed, reviewed, and committed. Also, be consistent in your feedback, and don't change your standards, expectations, or preferences without a valid reason.
###### Be open and receptive
When you give feedback, don't expect your colleague to accept it without question or resistance. They may have a different opinion, a valid justification, or a better solution. They may also have feedback for you, or questions for clarification. Be open and receptive to their input, and listen to their point of view. Don't argue, dismiss, or impose your feedback, but rather engage in a constructive dialogue, and seek to understand and resolve any disagreements. Be willing to compromise, learn, and improve together.
######Here’s what else to consider
This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?