Why does it sound horrible to have your code reviewed quickly? There is no reason for reviews to wait a long time. 4 hours is already a long time, it means you can wait to do it right before you go home or after lunch.
Why would I care if my code is reviewed quickly? If the answer is some variant of "I get punished if I don't have enough changes merged in fast enough," that's not helping. From the other side, it's having someone constantly breathe down your neck. Hope you don't get in a flow at the wrong time and need to break it so Mr. Lumbergh doesn't hit you up on Teams. It just reeks of a culture of "unlimited pto," rigid schedules, KPI hacking, and burnout.
You do a lot of small changes (<100 loc) that get reviewed often. If it doesn't get reviewed often then the whole idea of continuous development breaks down.
Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc? After that 100 loc or maybe 200 take a break and review other people's code.
Plus you also have random meetings and stuff so your day already fragments itself so adding a code review in the time before a meeting or after is "free" from a fragmentation standpoint.
Sounds kind of amazing to me. 4 hours is a bit ridiculous, but I wish we had some kind of automated system to poke people about reviews so I don't have to. It's doubly bad because a) I have to do it, and b) it makes me look annoying.
My ideal system (for work) would be something like: after 2 days, ask for a review if the reviewer hasn't given it. After a week, warn them the PR will be auto-approved. After 2 weeks, auto-approve it.
Well, there's a reason I'm no longer working there :)
But some people will put up with a lot for half a million dollars a year.
Ahh, that would do it. I don't think I have it in me, but I get it.
Why does it sound horrible to have your code reviewed quickly? There is no reason for reviews to wait a long time. 4 hours is already a long time, it means you can wait to do it right before you go home or after lunch.
Why would I care if my code is reviewed quickly? If the answer is some variant of "I get punished if I don't have enough changes merged in fast enough," that's not helping. From the other side, it's having someone constantly breathe down your neck. Hope you don't get in a flow at the wrong time and need to break it so Mr. Lumbergh doesn't hit you up on Teams. It just reeks of a culture of "unlimited pto," rigid schedules, KPI hacking, and burnout.
Because it's basically async pair-programming.
You do a lot of small changes (<100 loc) that get reviewed often. If it doesn't get reviewed often then the whole idea of continuous development breaks down.
Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc? After that 100 loc or maybe 200 take a break and review other people's code.
Plus you also have random meetings and stuff so your day already fragments itself so adding a code review in the time before a meeting or after is "free" from a fragmentation standpoint.
2 replies →
It sounds horrible to be interrupted constantly. I can't imagine they'd be particularly thorough reviews
Constantly? Some people can take a break in the morning and review a few PR’s and some in the afternoon. No one needs to drop what they’re doing.
Sounds kind of amazing to me. 4 hours is a bit ridiculous, but I wish we had some kind of automated system to poke people about reviews so I don't have to. It's doubly bad because a) I have to do it, and b) it makes me look annoying.
My ideal system (for work) would be something like: after 2 days, ask for a review if the reviewer hasn't given it. After a week, warn them the PR will be auto-approved. After 2 weeks, auto-approve it.