Here's one guiding principle I've thought a lot (and learned a lot about) during the past few years: learn to draw the line between how you allocate communicati

Here's one guiding principle I've thought a lot (and learned a lot about) during the past few years: learn to draw the line between how you allocate communications on the pull request and communications over chat -- don't be afraid to have a bias towards the latter. PR comments should be fairly light on a per line basis, and you may want to bring up architectural concerns if there are any, so that they're recorded there for posterity's sake. But you want to look at it like an artifact that you'll later on refer to. Don't be a pedant and ding based on style. If there are substantial design flaws, politely note your concerns, and then hash it out over chat or in person. Your goal is constructive collaboration, and it's really important to use the right collaboration tool for the right job. Often times, what happens in code reviews is that we find up front design that we neglected to do, or which was done in a way that has structural problems. That's fine -- in fact, the ability to do that incrementally is part of why lean works well. But that means that you've got to then do a proper design session (formal or informal) to get to a better ending place. If you really want to be cooking with gas, figure out a lightweight way to structure and record the results of these design sessions so that people will use and refer to them. I've seen teams grind to a screeching halt over poor usage of these processes, and not because any of the engineers were poor individual contributors!