Most code reviews degrade into style nits and rubber-stamp approvals. A useful review catches the bugs that tests miss and the design flaws that compound into tomorrow's tech debt. The trick is having a mental checklist ordered by what's expensive to fix later.

Review in this order — each layer is harder to fix than the next:

• Correctness: Off-by-ones, null cases, race conditions, error paths. Does the happy path work? What about the empty list, the timeout, the duplicate request?
• Security: SQL injection, missing authz checks, secrets in logs, untrusted input flowing into shell commands or HTML. Ask "where does user input enter, and what does it touch?"
• Design: Is this the right abstraction? Does it belong in this module? Will the next person who touches this curse the author?
• Readability: Naming, function length, comment quality. Cheap to fix but compounds over hundreds of reviews.
• Style: Let the linter handle it. If you're commenting on spacing, your CI is broken.

Concrete example. A teammate submits a PR adding a cancelOrder(orderId) endpoint. The tests pass. A weak review says "LGTM." A strong review asks: What if the order is already shipped? What if two clients call this simultaneously — do we double-refund? Is the caller authorized to cancel this specific order, or just any order? Is there an audit log? Those four questions catch the bugs that ship to production at 2am.

Rule of thumb — the 400-line ceiling. Reviews of PRs over ~400 lines find fewer defects per line than smaller ones. Reviewer attention degrades fast: by line 600 you're skimming. If a PR exceeds 400 lines of meaningful change, push back and ask for it to be split. This isn't bureaucracy — it's the difference between actually reviewing and pretending to.

Comment etiquette that keeps teams healthy:

• Prefix with intent: "nit:" for optional, "question:" when you don't know, "blocking:" for must-fix. Removes ambiguity.
• Critique the code, not the coder. "This function does too much" beats "you wrote a god function."
• Suggest, don't dictate. Offer a concrete alternative. "Could we extract X into Y?" invites discussion; "Refactor this" invites resentment.
• Approve generously when warranted. If the only issues are nits, approve with comments rather than blocking. Trust your teammates to address feedback.

Finally: review your own PR first. Read the diff before requesting review. You'll catch half the issues yourself, and your reviewers will trust that you respect their time.