Ask HN: How do you review code?
We had a similar problem and have made a lot of progress by reducing the size of changes submitted for review.  We used to  submit code only when we thought a feature was complete, and the median review was probably 1000 lines.  Now we're closer to 100-200.<p>This has a ton of positive effects:<p><pre><code>  - Reviewing code is much less daunting
  - Reviewers give more detailed feedback
  - Developers get feedback on lower layers (such as model definition) before writing a ton of code that depends on it
  - Reviews come quickly enough that developers don't need to switch to another project before continuing
</code></pre>
It was a bit difficult to make this transition.  We started out by explaining what we wanted to do (submit shorter diffs) and why, and people generally were on board.  But most people didn't know how to do it.  It's not as simple as submitting a diff whenever you write 100 lines of code, since the diffs need to be coherent.  Here are some techniques we used:<p><pre><code>  - Use feature flags to commit unfinished features to master/trunk without exposing them
  - Submit model changes as their own diffs, then API changes, then UI changes
  - As you work on a feature, pick out parts that seem ready for review, stage and commit them, send for review, then branch again from that point and continue working.  This takes a decent amount of git-fu, so train folks accordingly.
</code></pre>
Another thing to note is that our reviews are not at all evenly distributed around the team.  We have a team of 13 engineers, and it's probably an 80-20 split—80% of reviews are done by 20% of reviewers