[r-s]

I have a hard time imagining that most code reviews take < 10 minutes.

* Understanding of the problem at hand, reading through the story, understanding the context of the the code change.

* Pulling down the code, reading through the commit log

* Reading the specs, possibly running coverage tools if not part of testing suite.

* Understanding the logic of the code, seeing if the tests cover the edge cases

* If dependencies change, they may need to be investigated too

* Thinking if there are better ways make code a bit more extensible or understandable

* Thinking of risk of the code (security, performance, deployment concerns)

* Reading through associated documentation and ensuring its accuracy

Doing all of this takes me longer then 10 minutes always.

[skybrian]

That sounds like a more thorough review than we're talking about here. It's more like following a link to a website, reading the diffs, and adding inline comments. And it's typically done by someone already somewhat familiar with the codebase.

Also, some code reviews are tiny changes, so it brings the average down.

[kerkeslager]

* We mostly understand the problem at hand already because we were in the same planning meeting.

* We do our code reviews on GitHub by looking at the diffs. No need to pull code.

* We review the code of the tests, but we don't run them. Our CI server runs tests and coverage tools.

* The code is usually a short MVP, <100 lines including tests, so understanding logic and edge cases doesn't take long.

* If dependencies change, it was a group discussion and we already investigated.

* Again, small commits make this quick.

* Small commits make this quick.

* Documentation is handled by our product manager.

I guess what I'm learning from reading your comment is that part of why our code reviews are fast compared to yours is that we mean drastically different things when we say "code review".