When it then inevitably fails during release testing or in production, better devs need to spend quite a bit of time to figure out what the hell the stupid dev messed up and the fix is then often just a few lines.

[–] doeknius_gloek@discuss.tchncs.de 10 points 2 weeks ago (1 children)

What are the reviewers of these PRs doing? Out-of-scope PRs can be rejected and closed, no?

[–] squaresinger@lemmy.world 10 points 2 weeks ago (2 children)

It's a really weird team mechanic.

We have two teams working on the same codebase. The teams are very far apart in terms of organization. We are in different departments.

That dude is in the other team. Each team does their own code review and is supposed to ask for cross-team review for stuff that affects the other team.

The guy built himself a reputation as an infallible master programmer in his team by bullying everyone else during PRs. You know, nitpicking tiny non-mistakes like variable names, blocking PRs for weeks by always finding some unnecessary detail, then waiting for a few days after that detail was adjusted to find another one and so on. So his team thinks he's the greatest. Or maybe they are afraid to be his next victim or something. Whatever the reason, they just greenlight everything he does. And he never asks for a cross-team review.

His boss also completely covers for him, so so far our escalations just went nowhere.

[–] doeknius_gloek@discuss.tchncs.de 3 points 2 weeks ago

Oof sorry, that sucks.

[–] luciferofastora@feddit.org 1 points 1 week ago (1 children)

Can you create a paper trail about an impending issue caused by his creation, then let it fail in prod and hopefully get the right people pissed at him? Or is that more likely to backfire on you instead?

[–] squaresinger@lemmy.world 2 points 6 days ago (1 children)

We are doing that post hoc. We have enough issues thanks to him that actually do go to production and now we are escalating again. Lets see what happens.

[–] luciferofastora@feddit.org 1 points 6 days ago

Good luck!