Leadership through Reviews

Code reviews are not for finding typos. They are the primary Mentorship Channel for a tech lead. A bad review culture kills productivity; a great one builds an elite team.

1. The "Why," not just the "Change"

Don't just say "Use a switch here." Say: "A switch expression would be more readable here and allow the compiler to check for exhaustiveness, which prevents bugs if we add new types later." Teaching the **First Principle** behind the comment makes the engineer smarter for the next PR.

2. Subjectivity vs Standards

Never argue about style. Use a Linter for that. Only comment on:

• **Correctness:** Will this break in production?
• **Architecture:** Does this follow our design patterns?
• **Security:** Are there SQL injection or PII leaks?

3. Kind but Clear

Use "Request for Changes" sparingly. For minor things, leave "Nitpick" comments but approve the PR. This shows you trust your team and respect their time. For major issues, schedule a 5-minute call instead of an endless comment thread. One conversation saves 20 emails.

4. Career Mastery

Q: "How do I review a Senior who thinks they know more than me?"

Architect Answer: "Use the **Inquiry Pattern**. Instead of: 'This is wrong', use: 'I'm curious why you chose this over X? Help me understand the trade-offs.' This forces them to justify their decision. If they are right, you learn something. If they are wrong, they realize it themselves while explaining it to you. It's a win-win that preserves their ego and your authority."