The worst case is when someone requires changes, you address them, but then they disappear/go on a leave.
If the repository rules require all conversations to be resolved before merging and only the original reviewer can mark them as solved, the PR is stuck forever even if the rest of the team approves it.
That sounds like something you bring up in the retro
When the person came back from the leave I made some passive aggressive remark, hope this is enough 🤣
At that point, you get your team lead to go in the repo settings and unblock it.
Also me waiting for the junior dev to address review comments satisfactorily.
It’s a game where they try to make you impatient enough that you do it for them.
This always happens to me when I’ve written some genius code. Takes so long to review it, because my caveman colleagues don’t understand it.
It is amazing how many cavemen didn’t understand the sarcasm of my comment, and in their rage had to downvote it to hell. 😂
If you wrote good code, even a caveman would understand it.
Are you sure your code isn’t just overly convoluted?
I’m pretty sure that’s what they just said.
Caveman no understand
A 15000 line PR landing on a Friday evening for the lucky random reviewer to open on Monday. “Please approve it fast so we avoid too many conflicts.”
I’d be pulled up at my job for any PR exceeding a few hundred lines. I don’t even know what they’d do if I just dropped a 15000 line stinker.
Just a few hundred?
That’s seems awfully short no? We’re talking a couple hours of good flow state, that may not even be a full feature at that point 🤔
We have folks who can push out 600-1k loc covering multiple features/PRs in a day if they’re having a great day and are working somewhere they are proficient.
Never mind important refactors that might touch a thousand or a few thousand lines that might be pushed out on a daily basis, and need relatively fast turnarounds.
Essentially half of the job of writing code is also reviewing code, it really should be thought of that way.
(No, loc is not a unit of performance measurement, but it can correlate)
To be honest, I agree they should be able to be larger at times.
I had a lot of disagreements when I was on a new codebase, knew what I was doing and I was able to push a lot of code out each day.
The idea is to have them small, easily readable with a tight feedback loop. I argued that bootstrapping a project will have a lot of new code at once to lay the foundations and my communication with the team was enough feedback. If I split it up, each PR would have been an incomplete idea and would have garnered a bunch of unnecessary questions.
That said, I think it’s generally pretty easy to put out multiple PRs in a day, keeping them small and specific. As you say, half of the job is reading code and it’s nicer to give my coworkers a set of PRs broken down into bite sized pieces.
Yeah, this is my colleagues waiting for me, poor bastards
