What are good code review habits, as an author and as a reviewer?

Short answer: keep changes small, review for the things that matter, and keep comments kind and specific. Reviews exist to improve the code and share knowledge, not to prove who is right.

As an author

• Keep pull requests small. A few hundred changed lines at most is far easier to review than thousands.
• Describe the change. What and why, how you tested it, and what to look at. Link the issue.
• Review your own diff first. You will catch debug code and obvious mistakes.
• Let automation handle style. Formatters and linters in CI remove nitpicks.
• Respond to every comment, even if only to say it is done.

As a reviewer

• Review promptly. Waiting days blocks people and encourages huge batches.
• Check what matters first: correctness, edge cases, security, data handling, tests, readability, and whether the design fits the codebase.
• Be specific and kind. "This query runs per item; could we batch it?" is better than "this is slow".
• Separate must-fix from suggestions. A prefix such as "nit:" or "optional:" helps.
• Ask questions rather than issuing orders when you are unsure about intent.
• Say what is good. It shapes the culture.

Process agreements worth writing down

1. Target response time for reviews.
2. What needs one approval and what needs two.
3. What counts as blocking.
4. When it is fine to merge with follow-ups.

Pitfalls

• Arguing about taste instead of agreeing on a style guide.
• Rubber-stamping large pull requests.
• Letting a review thread turn into a design debate; move it to a call.

Review the code, not the person, and remember you will be on the other side next week.