[meindnoch]

Well, it's either:

1. Your skills are >2 standard deviations above everyone else's.

2. You're fast at producing a lot of half-baked garbage, and your coworkers are too shy to confront you, so they just try to ignore it.

(one of these scenarios is much more likely)

[neogodless]

As someone who often submits significantly more PRs (without using AI) than teammates, it's not exactly a skill delta. Yes that helps but it's often only a piece of the puzzle. The other ingredients include motivations and culture. In such cases, something else is the driving force, such as posturing for promotion, stability, etc. My current team is massively low performing. Management pays some lip service to all the problems, but also runs things in a way that discourages high performance. It's not a good fit for me, as I want to tackle challenges head on, improve the environment, be productive, embrace change. I'm also very comfortable with the code base as well as the code review process, but I'm surrounded by "seniors" who do not know how to code review, and who are happy to drag their feet and spin their wheels for months before pushing out small PRs that hurt my brain. How can that little work be shown after months, barely functional at best?

We had better management for a few months, and many on the team were actually quickly closing the skill gap with me, but we had another shuffle and things are stupid once more.

So I'd offer that's option 3. (There's always a third option to any suggested either-or fallacy.)

[whstl]

It could also potentially be that GP is making atomic PRs, while everyone else is just making 5000-line PRs with multiple responsibilities that just gets merged with "LGTM".

But of course HN has to with the most uncharitable interpretation.

[swiftcoder]

Are PRs honestly helping with either case? Either you severely rate-limit your high-performers, or you drown everyone else in review, and both outcomes are bad for the overall team

[Tade0]

The latter has an easy fix: the perpetrator is not allowed to take new work while there are pending review comments left unaddressed.

[neogodless]

By perpetrator you mean the person postponing performing a code review?

Right? Right?!

Otherwise you place all burden on high performers to not only push PRs but babysit the rest of the team.

It's not an easy fix, especially with AI letting people cosplay as high performers.

[rightbyte]

> you place all burden on high performers

If their PRs don't get merged they don't perform. It is trivial to overload your coworkers with secondary tasks due to your "high performance".

[swiftcoder]

> If their PRs don't get merged they don't perform. It is trivial to overload your coworkers with secondary tasks due to your "high performance".

We're all aware that a huge portion of the busywork that makes a team successful is not actually reflected in their upwards-facing deliverables (increasing test coverage, improving infra, adopting new tools/methodologies, preemptive security patching, etc). Your actual high performers, if you have any, are doing all that stuff in addition to their regularly-scheduled duties.

If management weren't at least tacitly on board with this arrangement, your high performers would go work somewhere else. So my experience is that good managers don't tend to see this your way.

[rightbyte]

Yeah I agree. I was trying to makee the point that it is quite easy to make yourself blocked by others and it is a deep skill to get other stuff done while blocked anyway, like say cleanups and tests etc.

[Tade0]

To make myself clear:

Reviewers have comments which were not addressed by the PR author - author not allowed to do other work.

No such comments, especially no reviews - author can do other work.