[Ozzie_osman]

There's a pretty subtle pitfall that teams can fall into here.

Let's say a team has 2 developers. Josh is 20% "better" than the John, or simply started earlier and has more context on the code base. So initially, Josh is 20% faster, but now John has to spend an extra 20% of his time reviewing Josh's code in a pull request (or understanding Josh's code so he can make a change) instead of making forward progress. So now, actually John is even 20% less effective than he can be, and he has less time to actually code. And since he's even less productive, Josh has __more__ time to code, so he's even faster, which means he writes more code. It kind of compounds, and even an initial slight advantage in speed or context for one developer can amplify itself over time.

A good engineering manager or senior engineer can detect when that's happening and try to correct the balance. But often the team kind of settles into a mode where Josh is known to be better and more productive and everything is funneled to him.

[specialist]

Paraphrasing:

Josh has the initiative, forcing John to react.

--

In my experience, Josh is a firehose of chaos, doesn't test their own work, colors outside the lines. So in addition to John reviewing Josh's torrent of bs, John is always playing catchup, always has to do more rework.

Further, it's not a balanced relationship. Josh creates urgency to fast track approval for their own PRs. Then will goal tend John's work. Pedantry over everything. Let PRs get stale, so John has to remerge, reseting the whole process. Insist the commits are "too big", "hard to understand", and therefore need to be broken up.

Etc.

Individual agility and velocity are evil, rewards dysfunctional behavior.

If the whole team isn't committed to getting the whole team across the finish line, it's not a proper team.

PS- Additional dysfunction if John is constitutionally incapable of refactoring, removing dead code, and other good citizenry.

[datagram]

I've found myself in this sort of situation a lot, including on 2-person teams. While I'm pointing out all the bugs, maintability issues, etc. on their commit, they're busy writing a new commit full of the same types of issues. And on the flip size: because I self-review my code with the same attention, I rarely have any of those same sorts of issues in code that I make others review.

I'm lucky in that my company recognizes and appreciates the quality that provide with my work and encourage from others, but I'm not sure of how to actually address the imbalance. Many times I've thought of just asking engineers to put more effort into self-reviewing their code, but I always feel like it would just be too rude.