Lately, I've been struggling with how to best balance code reviews and doing my own work, especially when my work is thinking-intensive. When I have some difficult proof-of-concept or research to do, it can be tough to get in the zone if I have to do a lot of back-and-forth with someone when reviewing their code.<p>I tried to batch this work into certain time frames, but that was bad for both me and the author of the PR - if there was a large amount of discussion, I'd be slow to respond if I had passed my pre-determined time to do that work, and this problem would compound as PR reviews started to gather in my inbox.<p>Today, I tried something totally different - attack every review as soon as possible, and look at each new commit submitted to each review as soon as possible, and respond as soon as possible to threads, which was good in that my queue stayed clear and I didn't have to reload the context of the PR into my brain.<p>This was possible today because I was doing some work where I'd already figured out the tough parts, so I'm just gliding through the implementation.<p>I'm curious how other people think about this problem, and if anyone has some suggestion for a middle ground here, and maybe for different kinds of schedules depending on the nature of the work I'm doing at the time. Thanks!
At a previous client, we'd use a Scrum board. All tasks are written on post-it notes, and divided in columns: design, implement, review and test.<p>Thus, one could pick up code reviews whenever appropriate.