Hacker News Reader

Comment by omar_a1 | Hacker News Reader

So, I have a related question: What do you do when the comments aren't being made in good faith?

In other words, incessant, aggressive, and unsolicited, with the reviewer not backing down even after you've implemented their changes? (e.g. Their previously implimented suggestion now are the wrong approach according to their next round of comments.)

I've tried simply going along with it, recognizing my own technical inexperience compared to theirs, but end up getting nothing done because of the capriciously-set goalposts.

This has been a recurring problem for me. Any tips?

View on HN

The 'perfect scenario' I work on is to try working from inside to out. The first question is "Do I understand?" - maybe the goalposts aren't shifting and there is something going on that you haven't picked up.

Checking that you understand involves finding evidence; so now you should have some evidence to go to someone else and ask "Do I understand?". They can help review the evidence and provide a check that it is convincing or at least realistic.

Having been thorough and made sure that there isn't something to fix up on the easy side, the next step is going to the reviewer and (gently, slowly but directly) raising concerns they are giving unhelpful feedback. An easy trap here is having evidence while they are going in blind which is a rather threatening imbalance, so give them time (maybe a few days) to think before expecting a response or there might be fireworks.

That exhausts the social work, so if the situation is still unresolved consider if it is reasonable to formally escalate the evidence to someone somewhere in the command chain so that they are aware the reviewer needs some coaching.

That covers everything that can be done short of quitting.

My suggestion is to ask them to fully explain the reasoning behind their comments, rather than just lobbing change requests into your code submissions. You can frame it as wanting to learn, grow, and understand the processes necessary to create good code. They have to either shut you down and be unhelpful, or have contradictory explanations that they give forward.

Hopefully it actually is a good-faith interaction and just a breakdown in communication. If not, though, putting someone on the spot to explain their actions is a good way to generate documentation that they're acting in bad faith.

This works with mean jokes, too, fwiw

Tips:

Relax. Detach. It’s just code. You just finished it and you want to be done and be victorious and move to the next thing. That’s understandable. But this is a long game.

Never reject advice immediately. “So, I’m not sure I like this, yet. I’m probably missing something. Let me think it over and play with it tonight, and let’s discuss this again tomorrow.”

Assume good faith. Try to give them the benefit of the doubt. Can you explain back to them why they want the changes, in a way that they agree with? Try it. Even if you disagree, they will see that you have heard them and understand their perspective.

If you disagree with their perspective, you can ask them about it, and why they value this over that. Keep an open mind. Later, a good question is, “Do you think we need to worry about <counterpoint>?

If you are sure they are wrong, consider using priorities or authority to deflect. “I could make these changes. Do you think that I should do them before or after ___?” Make sure you know exactly what goes in the blank, i.e., what are your organization’s priorities anyway? Or, “I think I will need to talk to my manager before I spend more time on this, he really wants me to focus on ___.”

If it is dysfunctional, get help. Tell your manager what you think is happening and ask them for advice. Can they see a way to make this less stressful? If it is really bothering you, your manager should care a lot and should help you work resolve this. If they don’t, you have a crap manager and should make a change.

Reply on news.ycombinator.com