From my experience doing reviews and having my code reviewed the most important thing is to understand:

  - What the intention of change is (what is this trying to achieve)
  - What is the code actually doing

There are three levels of review I typically observe:

  1. Skim, find one or two comments to leave. LGTM!
  2. Review each line or method in isolation. Recognize style and
     formatting errors. Identify a couple local bugs.
  3. Understand the purpose and the code.

#3 takes time. It's what it takes however to find the issues where the implementation doesn't actually accomplish what was set out to do (at least in all cases). To recognize where the code is going to break when integrated with other modules. To suggest big simplifications.

#3 is also where you get one of the biggest review benefits - shared understanding of the code base.

In my experience developing software, it's easy to have a sense of ownership and care most about the code one personally writes. That is often reinforced by the development process - you are responsible for delivering an issue. However, we're much less likely to feel responsible for the code we are reviewing. We don't answer for that deadline. As a result, it's often seen as a favor to review someone's code (even when the policy is for all code to be reviewed). It's also often not time allotted or planned for. So the tendency is to rush them.

Do other people observe the same thing? Have people used a process which gives more incentive to invest time in code reviewing well?