How I review PRs

1. Reason about potential bugs that could be in the code (as a more experienced developer you may catch some)

2. Find structural issues with code (bad abstractions)

3. Find clarity / readability issues (overly long functions, bad variable names)

4. Code style issues. In general these should be automated by a linter (prettier in javascript, for instance)

In a given review I find it most effective to stick to one level. Iterate until all concerns at that level are addressed. Iteration time / priority allowing, move at most one more level deep. Iterating through all four levels should be avoided unless the reviewee is a highly experienced developer who’s adapting to the team’s conventions.

Written by Brent Baumgartner. He lives and works in Charlottesville at TwinThread, building data-driven products. You should follow him on Twitter