4 ms·
I think their motivation still matters quite a bit. Just because someone has 20+ years of experience doesn't mean they're actually leveraging any of that for th
by nilkn 8y ago
I think their motivation still matters quite a bit. Just because someone has 20+ years of experience doesn't mean they're actually leveraging any of that for their review. If they're nitpicking something unimportant and they're only doing it for political reasons, then in that act they are contributing negative value to the team, regardless of experience.
- daveFNbuck 8y agoIf someone is that much more experienced than you are, it can be hard for you to tell the difference between nitpicking and something that experience has taught them is more important than you realize. Even if it is just nitpicking, that still means your code has nits to pick.
- starbugs 8y agoBe sure that I can come up with nitpicking on just about anything that you write, regardless how brilliant you think your piece of code is. This just costs money, burns people, and results in a bad culture. But I am sure as long as you're not the one who is in the weaker position that's totally ok for you, because you give considerably more fks about yourself than about your company's success.
- megaman22 8y agoUnless code review is a rubber-stamping process (in which case why bother? just party on production...), you're inviting criticism and improvement, so freaking out about receiving some and getting defensive or calling people toxic is... less than productive. One prolly shouldn't be a jackass as a reviewer, but if comments or questions on what you're doing get your back up, one should perhaps grow a thicker skin as a reviewee.
- majormajor 8y agoI don't believe this. Every time I've seen subtle problems that experience taught me were more important than first appeared, I've been able to explain why. And so I put that explanation in the review.
- daveFNbuck 8y agoUsually people complain to me about nitpicking for small things I thought should have been obvious and didn't require explanation. When you point out a word in a comment is misspelled, it shouldn't require an explanation about why proper spelling is important for readability and clear communication.
- nilkn 8y agoCode reviews are generally public and visible to the entire team and often even to other teams. While it's true that the reviewee may not be able to distinguish the two cases being considered, there may be other developers on the team or in the company who witness the review and can make the distinction. In fact, this can cause the "toxic reviewing" practice to spread to other experienced senior developers, who may see others with similar positions doing the same thing and then feel they must do it too in order to signal that they are, in fact, senior.
- Drdrdrq 8y agoInteresting - I thought you would end the argument differently. In my experience additional visibility helps curb the unwanted behaviour because other senior devs step in and help fight it - but I guess that depends on the general culture in the company. If that doesn't happen you have bigger problems anyway.
- nilkn 8y agoI do believe that code review culture ends up being a reflection of general company culture. In a healthy culture, visibility tends to spread the positive part of what's observable, whereas in a toxic culture visibility tends to spread the negative and political parts of what's observable. And there's definitely a circularity here. In a healthy culture, code reviews tend not to be overly political in the first place, so it would stand out like a sore thumb if someone was causing a lot of unnecessary drama with their reviews. Likewise, in a toxic culture, code reviews may go from healthy to toxic and dramatic because developers have been incentivized to compete with one another in counterproductive ways.
- KKKKkkkk1 8y agoAs an engineer, how do you address this sort of mutually-reinforcing jerkery? I expect that complaining to the manager will not be effective because the culprits are not explicitly hostile.
- 8y ago