Comment by saagarjha
1 month ago
No, I don't mean that. You assume that this is a logical conclusion but the problem is that "Bob would have to be pretty egregious to make it so Alice cannot work effectively" is not actually true. Bob, being the slightly better coder, could make Alice's life miserable without, like, doing a harassment that HR would be interested in. Constantly changing APIs that Alice relies on ("they're better now, why are you complaining?"), being overly nitpicky in reviews ("I'm not wrong, aren't I?"), or just outright taking the more interesting work ("I think I would do it faster than Alice") are all ways Bob could reduce Alice's productivity. If Alice is 0.9 of Bob, then instead of getting 1.9 Bobs you might get 1.2, while Alice plus Carl–who is just merely half a Bob–might be able to outperform that.
And if Bob doesn't get to do that he will leave. If Bob has to put up with low quality code because Alice can't get the basics right but he also isn't allowed to point out basic mistakes in code review, he will leave.
There is no such thing as being "overly nitpicky in reviews". This sentiment reminds me of an old coworker of mine that would basically throw a tantrum when I asked him not to add new lines to a file, which was indented consistently with tabs, with spaces. He needed to be reminded of this every commit. This is the sort of crap that distracts from the substantive code review, yes. But the solution is not to do what Alice wants and ignore minor details. It is for Alice to get the basics right the first time so that Bob can focus on more substantive things.
This isn't just true in software development either. In law, the first thing a new graduate joining the profession is told is that whatever you do, the work you produce should be spelt correctly and your grammar should be right. The formatting should be consistent too. Why? Because inconsistency and error in those aspects is distracting to someone reviewing the substance of the work, and the basics are so easy to get right.
To put it concisely: if you got the basics right the first time, which you should, then you wouldn't get nitpicky comments.
There are obviously many ways that people might be less productive in combination than the sum of their individual productivities, but in my experience some unfortunate people make no effort to adjust the way they work so that they combine well with others, and some people blend in very naturally with others' working styles. Some people are worth having even if they're difficult. Some people are only worth having if they play nicely. Either be a star or play nicely. Mediocre performers that are also difficult to work with don't ever last very long.
> And if Bob doesn't get to do that he will leave.
Maybe he should.
> If Bob has to put up with low quality code because Alice can't get the basics right but he also isn't allowed to point out basic mistakes in code review, he will leave.
There's a difference between nitpicks and "gets basic things wrong" or "doesn't format their code". Remember that Alice is 0.9 of Bob: she's not there fighting with him on formatting (everyone has CI do this anyway, lol) or getting basic things wrong. She's getting comments like "hmm, this API you use could be a bit better, could you also refactor that while you're at it?" or "can you make this more general to support this use case that we don't actually need right now, but could potentially need later?" I guarantee you, regardless of how smart you are, there are a multitude of ways I could tie up your review for a long time. And this happens all the time in projects with very smart people working on it.