3 ms·

I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours. I agree with him anyway: if every dev fel

I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours. I agree with him anyway: if every dev felt comfortable hitting a stop button to fix a bug then reviewing might not be needed. The reality is that any individual dev will get dinged for not meeting a release objective.

jannyfer 8mo ago
At the bottom of the page it says he is CEO of Tailscale.
devmor 8mo ago
I’ve worked on teams like you describe and it’s been terrible. My current team’s SDLC is more along the 5-hour line - if someone hasn’t reviewed your code by the end of today, you bring it up in standup and have someone commit to doing it.
usr1106 8mo ago
I worked in a company where reviews took days. The CTO complained a lot about the speed, but we had decent code quality. Now I work at a company where reviews take minutes. We have 5 lines of technical debt per 3 lines of code written. We spend months to work on complicated bugs that have made it to production.
ivanjermakov 8mo ago
I'm yet to see a project where reviews are handled seriously. Both business and developers couldn't care less.
- eterm 8mo ago
  I worked somewhere that actually had a great way to deal with this. It only works in small teams though. We had a "support rota", i.e. one day a week you'd be essentially excused from doing product delivery. Instead, you were the dev to deal with big triage, any code reviews, questions about the product, etc. Any spare time was spent looking for bugs in the backlog to further investigate / squash. Then when you were done with your support day you were back to sprint work. This meant there was no ambiguity of who to ask for code review, and limited / eliminated siloing of skills since everyone had to be able to review anyone else's work. That obviously doesn't scale to large teams, but it worked wonders for a small team.
- ratmeadow 8mo ago
  Bonus points: reviews are not taken seriously in the legitimate sense, but a facade of seriousness consisting of picky complaints is put forth to reinforce hierarchy and gatekeeping
- krilcebre 8mo ago
  I have, and in each sprint we always had tickets for reviewing the implementation, which could take anywhere from an hour to 2 days. The code quality was much better than in my current workplace where the reviews are done in minutes, although the software was also orders of magnitude more complex.
titanomachy 8mo ago
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.
- duskdozer 8mo ago
  That sounds horrible. I don't know how people stand to work in those conditions.
  - Jensson 8mo ago
    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.
    - duskdozer 8mo ago
      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.
      - lesuorac 8mo ago
        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.
nine_k 8mo ago
> days, not hours At some moment I realized that reviews are holding things back most of all. I started to jump to review my team's code ASAP. I started to encourage others to go review things ASAP. It works even in relatively large companies, as long as your team has a reasonable size. This can be learned, taught, and instilled.

jannyfer 8mo ago

At the bottom of the page it says he is CEO of Tailscale.

devmor 8mo ago

I’ve worked on teams like you describe and it’s been terrible. My current team’s SDLC is more along the 5-hour line - if someone hasn’t reviewed your code by the end of today, you bring it up in standup and have someone commit to doing it.

usr1106 8mo ago

I worked in a company where reviews took days. The CTO complained a lot about the speed, but we had decent code quality. Now I work at a company where reviews take minutes. We have 5 lines of technical debt per 3 lines of code written. We spend months to work on complicated bugs that have made it to production.

ivanjermakov 8mo ago

I'm yet to see a project where reviews are handled seriously. Both business and developers couldn't care less.

eterm 8mo ago
I worked somewhere that actually had a great way to deal with this. It only works in small teams though. We had a "support rota", i.e. one day a week you'd be essentially excused from doing product delivery. Instead, you were the dev to deal with big triage, any code reviews, questions about the product, etc. Any spare time was spent looking for bugs in the backlog to further investigate / squash. Then when you were done with your support day you were back to sprint work. This meant there was no ambiguity of who to ask for code review, and limited / eliminated siloing of skills since everyone had to be able to review anyone else's work. That obviously doesn't scale to large teams, but it worked wonders for a small team.
ratmeadow 8mo ago
Bonus points: reviews are not taken seriously in the legitimate sense, but a facade of seriousness consisting of picky complaints is put forth to reinforce hierarchy and gatekeeping
krilcebre 8mo ago
I have, and in each sprint we always had tickets for reviewing the implementation, which could take anywhere from an hour to 2 days. The code quality was much better than in my current workplace where the reviews are done in minutes, although the software was also orders of magnitude more complex.

titanomachy 8mo ago

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.

duskdozer 8mo ago
That sounds horrible. I don't know how people stand to work in those conditions.
- Jensson 8mo ago
  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.
  - duskdozer 8mo ago
    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.
    - lesuorac 8mo ago
      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.

nine_k 8mo ago

> days, not hours At some moment I realized that reviews are holding things back most of all. I started to jump to review my team's code ASAP. I started to encourage others to go review things ASAP. It works even in relatively large companies, as long as your team has a reasonable size. This can be learned, taught, and instilled.