Hacker News Reader

Comment by 000ooo000 | Hacker News Reader

>It's fairly easy to just ignore the aesthetic discussions and focus on solving problems.

You probably know this but for discussion's sake: in many modern forges, your pull request can't be merged unless the comments have been resolved/closed. So you basically cannot ignore these "feedback" items; you have to engage the comment whether that means actioning it or refuting it.

I currently work with the worst pedant I've encountered in my career to date, and I can empathise with wanting to leave the industry.

View on HN

> I currently work with the worst pedant I've encountered in my career to date, and I can empathise with wanting to leave the industry.

I have one of these too, one of my PRs received a comment on the third round of review about correcting a minor typo in a comment that was made years ago by someone else.

FWIW, we started using https://conventionalcomments.org a while back and found it to be a useful tool for making it easy to communicate what is an issue that needs to be fixed, a suggestion to consider, or a nitpick to optionally ignore.

It is still just a tool and does require the team to buy-in and utilize it, but we've found it helpful.

If the comment was in code you touched, this seems right. Typos affect searchabilty. If the typo was outside (but close to) the block you modified you shouldn't be required, and the team ought to have rules of engagement to state this.

It would be better for all if the pedant left the industry, but they typically have too much self-worth invested in an inflated perception of their expertise within it.

What is a forge in this context? Is that a name for a code repository website? I'm unfamiliar.

Regardless, I think that's just a function of your team and your dynamics that you've built up.

On the current team I'm on we for example don't require this (at least on GitHub its configurable), there is an understanding of nits, how to declare them and what that means, as well as an understanding of using request changes vs approve and so on. We've built this up by having discussions about what the purpose of reviews are (eg making sure your code is understandable by someone other than you), having a common understanding that perfect should never get in the way of good, etc.

We regularly have retrospectives where, if we were having issues with really bad pedantry, I would hope it could be brought up.

Yep you got it. Forge, aka GitHub, GitLab, Bitbucket, etc

SourceForge being the prime example.

You're 100% right regarding the team and its dynamics. I came from (and led) a team that had strict PR, but the difference is that we had well-established 'rules of engagement' so to speak, and just being decent people meant tone was never a factor. Unfortunately the product was given the 'tools down' order.

It's.. quite different where I am now. Change requests for untouched/irrelevant code, tone problems, etc. I'd be inclined to try and 'raise the tide' but I'm just trying to leave instead for many other reasons.

I'd like to work for a team where if you have ab aesthetic suggestion like this, you're only allowed to leave a comment if you also submit a commit.

So the "actioning" part becomes their work.

I advise asking him to stop, and when he doesn't leave 75+ comments on any PR he has.

Wikipedia editing methodology transfered to code edits, hilarious.

These kinds of silly games become tedious when you're trying to get something done, not to mention potentially damaging to your reputation given that the audience is your colleagues.

Reply on news.ycombinator.com