Ask HN: Code Reviewers Asserting Dominance | Hacker News Reader

Ask HN: Code Reviewers Asserting Dominance

2 pointsmatt32107 comments

Hello HN!

I recent started a new role about a month ago. I have a boss and a lead, both who love my work and only add helpful code review comments on my PRs. Great people and I am learning a lot from them in areas where I didn't expect. The lead will even approve my PR before comments are addressed.

I have a coworker who is sideways from me on the team (not a superior, not an underling). This coworker consistently makes unhelpful review comments which hold up the merge (example: "this comment should be worded differently" and "rename 'sock' to 'socket' "). The company policy is code-by-democracy, and I have to get this person's approval on the review.

How do I deal with this? I've never seen this is all my 10+ years of dev-ing. Before anyone suggest, I am not willing to act the same way on his PR because it's a waste of time.

I resist these things because if I too readily do them, I will have it more frequently, as do some of my coworkers (from the same reviewer).

Boss and lead are unhelpful on the matter. The only thing I can think of is to just leave the RP sitting there unmerged until it causes issues downstream.

I talked to the person and he said essentially that we should all be doing what he's doing.

Am I in the wrong on this? How do I deal with this?

Generally, reviews should be helpful and move the project forward. Sometimes a discussion is required because disagreements do occur. The appropriate way to handle it is to respond to the comment, explaining your case (rationally and without emotion), allowing the record to reflect the result of the discussion. This is important because it sets a standard and minimizes the opportunity for someone to jerk you around later because the standard was set in an earlier discussion.

That said, it's important to pick your battles and be right on issues that are important to you. I've worked on a lot of different projects. The people who set up the project pick the standards and sometimes that's me. If I arrive on the project later, I typically take the stand of "When in Rome...". Watching the existing team's standards and adapting to that is a good approach most of the time because I'm doing my part to moving the team forward with consistency - and you'll often hear about the value of consistency.

Often, no one is wrong on these things and you just disagree. If you lose, disagree and commit. However, by having these discussions in a healthy way helps you and other learn and can be fun.

I admit that in times I sometimes nitpicked the phraseology/terminology of names and wording of comments in MRs. I usually preface the comment with “nitpick:”.

In my team nitpicks can be ignored and by no means block an PR. Perhaps you could adopt that with your team. Also are you sure this person has the power to block your PR? I’d just merge it in anyway.

Look for a new job.

Your choice not to play his game is like forfeiting a game of chess on the very first move.

In case you're inclined to think rationally about it: suppose there are three of you, you have three times the ability to bury him with paperwork and he has 1/3 the ability to dig out. With a factor of nine he just can't win.

I know you don't want to waste time, so don't waste time with trivial problems that are easy to fix, instead look for race conditions, problems with key structures, and other things that will require major rework. Need skills for you next job? Learn how to use a tool like

https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer)

to knock holes in his code.

I like it! Thank you sooo much! Jebus I love this answer. The result is better code and time well spent!

It is hard to say from one example, but I have no issue with someone suggesting/demanding more meaningful names. Is sock vs socket a deal breaker, no of course not but the latter is more than "just two exte letters" in my opinion. It also seems like such a trivial thing to correct in any reasonable editor. Now that you know or as you continue to learn what is important to the team this should happen less.

If vou've never experienced nitpicking over a 10+y career, perhaps your experiences could have been more diverse.

It's seems healthy to open your mind to the possibility that you're getting valuable feedback for no other reason than increasing maintainability.

> Boss and lead are unhelpful on the matter.

In what ways? What have you told them and what did they say?

Reply on news.ycombinator.com