---
marp: true
theme: default
paginate: false
---

# Rethinking Code Reviews
*Based on talk "Code Reviews: Building Better Code and Stronger Teams" @ MeetingC++*

---

# What is a code review to you?

---

# What is purpose of code reviews?
- **Quality assurance**
  - "The final human check after all automation"
  - Enforce standards, patterns, naming
  - Offers fresh perspective (author bias)
  
---

# What is purpose of code reviews?
- Quality assurance
- **Knowledge sharing**
  - Educate about language & tools
  - Share context and decisions
  - Leverage diverse insights
  
---

# What is purpose of code reviews?
- Quality assurance
- Knowledge sharing
- **Mentoring**
  - Elevate less experienced devs
  - Improve team communication
  
---

# How to do code reviews?
- **Syncronous:** Pair/Mob programming, review meetings
- **Asyncronous:** Pull requests

---

## Pair programming
  - Real-time collaboration
  - "Review is a by-product"
  - *Best for onboarding and complex problems*

---

## Mob programming
  - One types, others guide
  - Shared understanding
  - *Best for exploratory work and architecture*

---

## Review meetings
  - Pre-scheduled, multiple stakeholders
  - *Best for critical code/architecture*

---

## Pull requests
  - Written only: risk of misunderstanding
  - Enables flexibility (not real time)
  - *Best for day-to-day code changes*

---

# Pull Requests: Issues and learnings

---

# [REVIEWER] Common issues of pull request
- Late feedback
- *Tone in written feedback!*
- Comments lack explanaton or educational value
- Everything gets commented -> "pair programming"

---

# [REVIEWEE] Common issues of pull request
- Too big, mixed changes
- Shared too early (not green)
- No context/description on entry point
- No self-review


---

# The AIR Formula for Better Comments
- **A = Action:** What should be done
- **I = Information:** Why it matters
- **R = Reference:** Where to learn more

Example:
- "🔴[DESIGN] Tight-coupled dependency. Use DI. See docs"

---

# Call to Action
- Self reviews of PRs!
- Be kind and empathetic in reviews, (give kudos!)
- Discuss review culture within your team
- Start seeing reviews as mentoring opportunities
- Try incorporating asynchronous reviews
- Try **AIR** formula for comments, *and, or*
- Try out adding intent to the comments (blocker, nit, question, kudos).
- Avoid reviews which are just *"Looks Good To Me"*


---

# Thank you!

---

# Points of discussion
- How are code reviews done in your team?
- What challenges have you faced?
- What practices worked well for you?
- Have you tried any asynchronous review methods?