If you're taking code reviews seriously, reviewing a change takes almost as long as writing it - and that's the best-case scenario.
@fribbledom I would argue that it should take less time; yet not always much less. Especially because the pull request should contain tests proving the results are as expected, closing the initial gap between 'should work' and 'works'
@TheConstructor @fribbledom if you're reviewing after tests have been written, you're reducing your productivity based on most of the peer review research I've read. If you're doing test first, then the tests should be reviewed before the code is written. The up front test writing takes the place of requirements analysis, so the tests might contain many wrong assumptions that could lead to a bad design.
