Code Review taste

# Code Review taste of a staff engineer - Keep pull requests small enough to review in one sitting, ideally under 400 changed lines; split refactors from behavior changes. Confidence: 0.90 - Write a PR description that states the why, the approach, how it was tested and what is out of scope. Confidence: 0.90 - Self-review the diff before requesting review and leave comments on the non-obvious parts. Confidence: 0.85 - Let formatters, linters and type checkers settle style in CI; humans never comment on whitespace or import order. Confidence: 0.95 - Review for correctness, design and maintainability first, naming and readability second. Confidence: 0.85 - Prefix comments with their weight (nit:, suggestion:, question:, blocking:) so the author knows what must change. Confidence: 0.85 - Ask questions instead of issuing orders ("What happens if this list is empty?"). Confidence: 0.80 - Approve with minor nits rather than blocking; trust the author to address them before merge. Confidence: 0.80 - Respond to review requests within one working day; a stale PR costs more than an interrupted hour. Confidence: 0.85 - Require tests for every bug fix that would have failed before the fix. Confidence: 0.90 - Check error paths, timeouts, retries and logging, not just the happy path. Confidence: 0.85 - Flag any new dependency and ask whether it is maintained, licensed correctly and worth its size. Confidence: 0.80 - Treat database migrations, auth changes and public API changes as high-risk and require a second reviewer. Confidence: 0.85 - Pull the branch and run it locally for UI or behavior changes that screenshots cannot prove. Confidence: 0.70 - Suggest concrete code with the suggestion feature instead of describing the change in prose. Confidence: 0.75 - Resolve long back-and-forth threads in a short call, then write the outcome in the PR. Confidence: 0.80 - The author resolves conversations only after the reviewer's concern is addressed or explicitly waived. Confidence: 0.70 - Use CODEOWNERS for critical paths but avoid making one person a bottleneck for the whole repo. Confidence: 0.80 - Prefer squash merges with a clean conventional commit message for a linear history. Confidence: 0.75 - Praise good solutions explicitly; review is also how the team learns what good looks like. Confidence: 0.75 - Never merge your own PR without review on shared branches, except documented emergency hotfixes that get a follow-up review. Confidence: 0.85