The results from the team survey come back, and one comment is about you. It is two sentences. Sometimes dismissive in code review, especially with newer people. You read it four times. Then you start going through the team in your head, trying to work out who wrote it.
Almost everyone does this. It feels like the obvious next step, because if you knew who wrote it you could understand it, or explain yourself, or decide it was unfair.
Stop the guessing early. You will probably guess wrong, and even if you guess right you cannot say so. The comment was anonymous because the writer did not feel safe saying it to you directly. Hunting for them, even privately, quietly changes how you treat everyone you suspect.
Treat the comment as one data point and ask what it would mean if it were true. Not whether it is fair, but whether there is any version of it you recognise. Go back through your recent review comments and read them as a new joiner would. Short, blunt notes that you meant as efficient can read as impatience to someone in their first month.
Look for patterns elsewhere. Has anyone said something similar in a different form? Do newer people ask you fewer questions than they ask others? Small signals like that can confirm or soften what one comment says.
If you want more, ask the whole team openly, without trying to find the writer. I saw a comment about how I review code, and I want to do it better. If anything I have written has felt dismissive, I would welcome hearing about it, here or privately. That tells the writer their comment landed, which is what they hoped for.
Then change something visible. Start review comments with what works. Offer a quick call instead of a long thread for someone new. The person who wrote it will notice, even if you never learn who they are.
That is the real response to anonymous feedback. Not finding the author, but making them glad they wrote it.
– Asael Shinder
