Hacker News Reader

Comment by titanomachy | Hacker News Reader

My last FAANG team had a soft 4-hour review SLA, but if it was a complicated change then that might just mean someone acknowledging it and committing to reviewing it by a certain date/time. IIRC, if someone requested a review and you hadn't gotten to it by around the 3-hour mark you'd get an automated chat message "so-and-so has been waiting a while for your review".

Everyone was very highly paid, managers measured everything (including code review turnaround), and they frequently fired bottom performers. So, tradeoffs.

View on HN

That sounds horrible. I don't know how people stand to work in those conditions.

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.

> Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc?

I have an issue at work that will likely be solved by a single line change. But figuring out which line it is is going to take awhile.

IMO code reviews are not pair programming. By the time I've raised an MR, it's already perfect. I've had multiple client calls, talked to my team about design, unit tested it, tested it on a container environment, thought about it.

So it really doesn't matter when the review gets done. I mean, even a week and it's fine.

Tight feedback loops feel good.

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.

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.

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.

Reply on news.ycombinator.com