undefined | Better HN

0 pointsagentultra3y ago0 comments

First, recognize what constructive feedback is. Not all feedback is created equal. Most developers aren't trained in nor understand what constructive feedback is. Recognizing poor feedback is the first step.

It's easier to accept constructive feedback because it's not directed in a personal way. Someone who leaves constructive feedback isn't questioning your intentions, motives, skills, or choices. They're not leaving snark, highlighting your mistakes, etc. You won't see much use of the words, I or you. Constructive feedback teaches you something and should leave you feeling better about the state of the code.

The difference between...

We should use a wrapper around this type so that...

and

Why did you pass this type without wrapping it?

Is that the former is suggesting a logical change to the code that will have a positive impact on its fitness for use. The latter is interrogating the author and has nothing to do with making the code better.

There's no need to doubt yourself so much. Don't let poor criticism gaslight you into thinking that there is something wrong with you. If you're responding to PR feedback in an emotional way it's a sign that you're trying to protect yourself and there's a reason for that reaction. If there's a problem with the magnitude of your emotional responses, that's a different problem (I've worked with people who were not getting therapy for their anger management issues). However anger, resentment, etc are normal feelings and are useful.

The next step to dealing with it is learning how to be polite and assertive. Once you can identify feedback that is not constructive you need to learn to tell people so and divert them away. In other words, how to tell people to take a walk without telling them to take a walk.

And you can be proactive in this too: talk with your team and team leads about feedback and develop a code review guideline to enshrine some simple rules that nudge people towards giving the kinds of constructive feedback you're looking for.

And if your team is encouraging the kind of environment where you feel bad about honest mistakes then you should consider looking for another team if such discussions don't change anything.

0 comments

3 comments · 1 top-level

ambicapter3y ago· 2 in thread

I write plenty of feedback where I ask questions of the code author because I'm seeking to understand why they did something a certain way because there's a possibility that they are doing it correctly, but that possibility is likely small (e.g. it looks like they've written something in reaction to a possibility that is exceedingly slim, but possible). In that case it's very difficult to word it without sounding accusatory, but there's no way to word it without addressing them personally.

agentultraOP3y ago

My usual response to this is: ask me in private or in a water cooler chat. I love to talk about programming. And I love learning how others approach things as well.

If the level of trust in a team is high enough that asking such questions is genuinely considered honest and useful then most people ought not to be feeling bad about honest mistakes or characterize feedback as, "snarky," and feeling anger, shame, etc after a code review. If people like these kinds of questions and it helps the team then maybe it should be in the code review guidelines.

For me, I have a hard enough time discerning the intentions of other people. Guidelines remove some of that ambiguity up front so that I can safely assume people are being genuine and it is obvious to everyone else, and me, when they're not.

However, the spirit of the idea is that code reviews shouldn't be leaving you feeling bad about yourself and the mistakes you've made. That could be a you problem but I think it's more common for us to self-doubt than to realize that perhaps the problem may lie with other people. Imposter syndrome, DK, etc, etc all seem to run rampant.

sidlls3y ago

"Please help me understand <interrogative>"

"I don't think I understand this completely, can you tell me <interrogative>"

j / k navigate · click thread line to collapse