How to review code changes that touch areas you don't know

You Don't Need to Know Everything to Review Well

Reviewers often skip or rubber-stamp code in areas they don't know. This creates false safety. You can add value as a reviewer even in unfamiliar territory — your job shifts from verifying correctness to asking clarifying questions and ensuring the tests document the expected behavior.

What You Can Always Review

• Tests — do they cover the happy path, error cases, and edge cases? You don't need to know the domain to check test completeness.
• Error handling — does every async call have error handling? Are errors propagated or swallowed?
• Naming — do the names make the intent clear to someone without domain knowledge?
• Documentation — is there a comment explaining anything non-obvious?

// Review comment when you don't understand a decision:
// "I'm not familiar with the HSM key rotation requirements — 
// can you add a comment explaining why we're using a 2-hour TTL here
// and link to the spec? Flagging @security-team for a second look."

Honest uncertainty in a review comment is more valuable than false confidence. "I don't know this area but this looks odd — can you explain?" protects the codebase better than silence or approval you don't mean.