5 ms·
Working there I tended to conduct code reviews each afternoon at the end of work. Sometimes after coming back from lunch as well. There isn't any "drop what the
by ummonk 4y ago
Working there I tended to conduct code reviews each afternoon at the end of work. Sometimes after coming back from lunch as well. There isn't any "drop what they're doing" involved.
- pavon 4y agoSure, I do reviews first thing every morning, and sometimes right after lunch (mostly just rereviews), but that would give a mean/median response time of 4 hours assuming work completion time is uniformly distributed. And if changes are requested, that would add another 2-4 hours, which brings the total review-in-wait time to a full day, which the post was saying was unacceptable. To get the numbers they claim they must be reviewing more frequently than that.
- disgruntledphd2 4y agoYou can use timezones to your advantage here. When California is finishing, Singapore is starting and when Singapore is finishing London is starting.
- gtirloni 4y agoWhy would you do that unless it's a hotfix or something really critical? Are the costs negligible?
- disgruntledphd2 4y agoSo, it depends. When I was at FB, we had one person in Europe (me), one in SF and one in Asia. Organising the diffs in this way made it much, much easier to collaborate. Given how much FB has grown since then, I suspect this would be even easier, and this is how the numbers noted above are what they are.
- ummonk 4y agoEvery team member doesn't do their review at the same time. You're likely to get a review within a few hours, which means total review time (they're only counting the time it's waiting for a review) is unlikely to be a whole day.
- comfypotato 4y agoWhich is what I expect. This doesn’t really agree with “a few hours” which is why I was confused.
- ummonk 4y agoIt's perfectly consistent with a few hours, given that different team members tend to review diffs at different time during the day.