Principle: Code review best practices

Code reviews are either rubber stamps (approving without reading), nitpick-fests (bikeshedding style), or bottlenecks (reviews take days).

Effective code review practices:

For AUTHORS:

1. Keep PRs small (< 400 lines changed)
2. Write a clear description explaining WHY, not just WHAT
3. Self-review before requesting others
4. Add comments on tricky parts explaining your reasoning
5. Separate refactoring from feature changes (different PRs)

For REVIEWERS:

1. Focus on (in priority order):

- Correctness: Does it work? Edge cases?
- Security: Injection, auth, data exposure?
- Architecture: Right abstraction level? Maintainable?
- Performance: O(n) issues? Missing indexes?
- Tests: Meaningful test coverage?
- LAST: Style and naming

1. Distinguish blocking from non-blocking feedback:

- 'nit:' = style preference, non-blocking
- 'suggestion:' = improvement idea, non-blocking
- (no prefix) = must fix before merge

1. Be kind: critique code, not the person

Bad: 'You should know better than to use any'
Good: 'Using a specific type here would catch bugs at compile time'

1. Respond within 24 hours (calendar, not business)

1. Approve with minor comments when appropriate

Don't block for style-only changes

Good code reviews catch bugs, share knowledge, and maintain quality. Bad reviews demoralize teams and slow delivery.