this post was submitted on 24 Jun 2026
16 points (76.7% liked)
Programming
27486 readers
197 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.