My friend and I have a game where we talk about what we'd do if we were rich. Not rich like 'paid off the mortgage' rich. Rich like a man who owns a submarine he's never been inside. Rich like a man whose third wife has a skincare
Well, that’s a bit of a “How long is a piece of string” question. I’m not saying there is a clear delineation, just that most programmers could see that changing one line with little practical impact is wholly different than a patch with many restructured components. Where between those two a team draws the line is a fair question but there is a line, and assuming all changes, regardless of impact, are on one side of it does waste time.
Sure, maybe 2 minutes. But not only does each 2 minute interruption actually cause a full break in current work; context switching is notoriously costly for programmers, but they also add up. If I get many of these in one day, that just isn’t productive. Imagine a teammate decides we’re going to upgrade a library dependency for a patch version. We validate this. Then, we simply need to change this version id in each of 50 services. Opening a PR for each of these is craziness.
Sure, maybe 2 minutes. But not only does each 2 minute interruption actually cause a full break in current work; context switching is notoriously costly for programmers
small Code Reviews should not warrant an interruption of your work, because not reviewing them should not block anyone. they should be done when someone is actually idling or at a planned time. most of the time i’ll review small changes directly after a daily if someone mentions a small open pr before starting with my actual work, i definitely prefer this to people just merging things and losing the chance to ask questions.
when is a change complex enough to warant a review and how do you ensure that no complex change is merged without a review?
Sounds the real issue is that work is poorly defined if it comes to a standstill if no one is available for a 2 minute review.
those 2 minutes reviews are noise at the end of the day, if you ask me, they don’t have a noticeable impact on the reviewers daily performance.
Well, that’s a bit of a “How long is a piece of string” question. I’m not saying there is a clear delineation, just that most programmers could see that changing one line with little practical impact is wholly different than a patch with many restructured components. Where between those two a team draws the line is a fair question but there is a line, and assuming all changes, regardless of impact, are on one side of it does waste time.
Sure, maybe 2 minutes. But not only does each 2 minute interruption actually cause a full break in current work; context switching is notoriously costly for programmers, but they also add up. If I get many of these in one day, that just isn’t productive. Imagine a teammate decides we’re going to upgrade a library dependency for a patch version. We validate this. Then, we simply need to change this version id in each of 50 services. Opening a PR for each of these is craziness.
small Code Reviews should not warrant an interruption of your work, because not reviewing them should not block anyone. they should be done when someone is actually idling or at a planned time. most of the time i’ll review small changes directly after a daily if someone mentions a small open pr before starting with my actual work, i definitely prefer this to people just merging things and losing the chance to ask questions.