While I share your frustration, I think leaving the industry because of it is an overreaction. It's fairly easy to just ignore the aesthetic discussions and focus on solving problems. Whenever someone brings up renaming a function from perfectly_good_name_1 to perfectly_good_name_2 in code review, I immediately agree without discussion and move on with my life.
>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.
> 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.
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.
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.
Maybe a more accurate phrasing would be, "Can't wait to retire and do literally anything else with my time, including writing programs with which I answer to no one about coding style.", Hah.
