What do you do if your code review feedback is not constructive?

If the feedback is vague or unclear, ask the reviewer for specific examples or more detailed explanations. Arrange a one-on-one meeting with the reviewer to discuss the feedback in detail. Bring the discussion back to your team’s coding standards or best practices. If you’re unsure about the feedback or feel it’s unjustified, consider asking another experienced colleague to review the same code. Sometimes, explaining the rationale behind your coding decisions can help the reviewer understand your approach. Use the opportunity to discuss different approaches and techniques with the reviewer. If the feedback consistently lacks constructiveness and affects your work or morale, consider discussing it with a supervisor.

Seek clarity with specification so that you can see areas of improvement. Also, what helps me to find out what I should do instead of what I should not do.

-Ask for specific examples or explanations to understand the reviewer's concerns better. -It's possible the reviewer might be pressed for time. Try to understand their intent and separate any negativity from the core points raised.

In my career, handling non-constructive code review feedback effectively has been key. It’s crucial to remain calm and objective. Initially, absorb the feedback, then respond by focusing on the code and project goals, not the personal. If feedback feels harsh, I advocate discussing the tone and pushing for communication that is both respectful and constructive. This approach not only maintains professional relationships but also fosters a more productive and positive working environment. Always steer the discussion back to improving the project, ensuring feedback is actionable and aligned with project objectives.

Maybe this mediator can help with the non- constructive comments being made. Being a senior person they might be able to see the issues in your code and translate them to a more constructive perspective.

I know in face of non-constructive criticism it very hard not to feel bad. But if you look at it this way, that it is better to get a criticism at the code review level rather than have your code go out into production and cause issues there which might draw further negative attention to you and your team.

Consider if you are in the right place or it is time to pack your bags and go. Find a team of 1(one) where you are free to do whatever you please however you please and YOU define how the project will be shaped (and bear full responsibility for the outcome along the way). If you are not ready to be a sole contributor maybe you'd consider that it's time to bend over and receive whatever feedback came your way.

Communication is usually a more important issue that we can recon nowadays. When such communication fails, it's time to see what can we do to improve it. If you're receiving a "non constructive" feedback, first analyze the feedback (content) and not just the way it was delivered. If the content is right, take it and learn from it. If the content is wrong, set the record straight by having a good conversation. If it's a matter of attitude (the way somebody trait you), have a conversation about that. Tell this person how the situation made you felt. If needed, find a mediator. Take this as an opportunity to grow (either in technical or soft skills). Remember, you need to learn from situations like this, but never let anyone mistreat you.

It is very important to have empathy in good code review. Code reviews should be unbiased and nonjudgmental, main goal of code review is to have bug free code and improvement of code quality.