Stop Nitpicking in Code Reviews blog.danlew.net/2021/02/23/sto…
@joreilly The worst thing than NIT, is when a toxic leader in the team doesn't want to talk with teammates about potential solutions that will be accepted by everyone, and this "leader" is just waiting for the opening of a new PR to write 100 comments to show how he is smart.
@joreilly "you start a pull request and the first reviewer points out a dozen nits. Your natural response will not be zen-like acceptance; it will be to get upset" why? I really don't agree with this logic, why is being upset the default reaction?
@joreilly "thou shalt not take pr comments personally"
@joreilly Damn, this article feels like a direct attack on me.
@joreilly And if you really value the little stuff, on how your code looks like, etc, use a linter, in both your ci/cd and, preferably, in your IDEs as well. Then the linter, not a colleague, is the nit-picker. And you & your colleagues can focus on the bigger more important review issues
@joreilly I often work in teams where open MRs for a ticket are the only way to ever change certain things in code. With such a barrier, it's understandable people don't want to let a chance slip to make the code more like they want it to be when they are "responsible" for it in the Future