Code Review Meeting #
In many teams, there’s a habit that looks like good collaboration but actually hides a deeper problem: making meetings the primary way to do code review. Every complex PR immediately gets a joint review session scheduled. Technical discussions about approaches are always resolved in a call. Code review feels incomplete without everyone sitting together — virtual or physical.
The intention is good: ensuring everyone is aligned, providing space for rich discussion, and making sure nothing is missed. But the results often fall short of expectations: introverted engineers don’t say much, discussion is dominated by one or two voices, decisions made in the meeting aren’t documented, and a few days later nobody remembers exactly why a certain approach was chosen.
Conversely, the most productive teams that successfully build good codebase quality almost always use async review as the default — only holding meetings for code review in very specific situations, with clear agendas and limited durations.
This article covers why async is the correct default, when meetings are truly justified, and how to run genuinely effective review meetings when they’re needed.
The Real Cost of a Meeting #
Before deciding whether a discussion needs to become a meeting, there’s a simple calculation to do:
Meeting cost in engineering hours:
Number of participants × meeting duration = engineering hours consumed
Example 1: an inefficient daily standup
6 engineers × 30 minutes = 3 engineering hours / day
3 hours/day × 20 working days = 60 engineering hours / month
→ Equivalent to 1.5 weeks of one engineer's work, spent on standups alone
Example 2: a code review meeting replaceable with async
4 engineers × 1 hour = 4 engineering hours
If that review could finish via async comments in 45 total minutes:
→ You just spent 3 unnecessary engineering hours
This isn’t an argument for never holding meetings. It’s an argument for realizing that meetings aren’t free — they consume the most unrecoverable resource: engineers’ time and focus. Every decision to hold a meeting should pass through a simple question: “Does this really need to be synchronous, or could it be done more effectively async?”
Why Async Is the Correct Default #
Code review is fundamentally a thinking activity — not a real-time discussion activity. Reading code, understanding its context, detecting invisible problems, and formulating meaningful feedback are cognitive processes needing time and calm, not hour pressure and other people’s eyes.
Review quality comparison: async vs sync
Async review (PR comments):
→ Reviewers read at their best focus time
→ No time pressure — they can think before writing
→ Can check references, documentation, or related code before commenting
→ All feedback automatically documented
→ Introvert and extrovert reviewers have equal voices
→ Authors can consider feedback calmly before responding
Sync review (meeting):
→ Everyone reads code at the same time, often rushed
→ Feedback given on the spot — no time for deep thought
→ The loudest or most confident voice dominates
→ Decisions made are often undocumented
→ Introverted engineers tend to contribute less
→ The author is in a defensive position — must respond in place
There’s a principle that can be used as a guide: if feedback can be clearly delivered through written text, there’s no reason to make it a meeting.
flowchart TD
A[PR opened] --> B[Reviewer starts async review]
B --> C{"Can feedback be delivered\nvia written comments?"}
C -- Yes --> D["Write PR comments\nresolve async"]
D --> E{"Discussion stuck?\nMore than 3 rounds\nwithout resolution?"}
E -- No --> F["Merge after all\ncomments resolved"]
E -- Yes --> G{Stuck type?}
C -- No --> G
G -- High technical\ncomplexity --> H["Schedule a quick sync\n15-30 minutes"]
G -- Design/architecture\ndisagreement --> H
G -- High-risk change\nneeds alignment --> H
H --> I["Run the meeting\nwith a clear agenda"]
I --> J["Document results\nin a PR comment"]
J --> FWhen Meetings Are Truly Justified #
Meetings for code review aren’t an anti-pattern — they’re the right tool for the right situations. There are four situations where meetings genuinely provide more value than async review.
1. Complex Logic Hard to Explain Through Text #
There’s a class of technical problems where five paragraphs of written explanation still aren’t as clear as a three-minute verbal explanation with a diagram. Concurrency, complex state machines, event-driven flows with many side effects, or algorithms with many state transitions are examples where a whiteboard session or a short screen-share can cut through confusion that written comments can’t resolve.
Indicators that complexity needs a sync session:
✓ The reviewer has read the code 3x and still isn't sure they understand the flow
✓ Written comments are already long but author and reviewer still discuss
different things
✓ A diagram is needed to explain relationships between components
✓ More than 2 concurrency scenarios need thinking through together
✓ Business context is very specific and hard to convey without conversation
Important note: this meeting’s goal isn’t reviewing code line by line, but clarifying context and design so subsequent async review can run more effectively.
2. Genuine Design Disagreements #
When reviewer and author hold different views on an architectural approach — not about right or wrong, but about different trade-offs — written discussion can become very long and unproductive. Each party writes long paragraphs that don’t change the other’s position.
Example of a design disagreement better resolved sync:
Reviewer: "I think this abstraction is too early, violates YAGNI"
Author: "But we need this for extensibility in Q3"
Reviewer: "Q3 is far away, we don't know the requirements yet"
Author: "But if not now, refactoring later is more expensive"
[continues 10 comments without progress...]
→ This is a disagreement needing discussion about context,
product roadmap, and trade-offs — not debugging.
→ 15 minutes of sync can resolve this more effectively.
3. High-Risk Changes Needing Alignment #
Changes touching core security, payment processing, or fundamental architecture require more than one reviewer’s approval. All relevant technical stakeholders need to share the same understanding of what changed, why, and what the risks are.
This isn’t because async can’t convey the information — but because for changes this important, ensuring everyone truly understands (not just reads and approves) matters more than time efficiency.
4. Mentoring and Onboarding #
When a senior engineer reviews a PR from a junior engineer or someone newly onboarded, a meeting can become a very valuable mentoring session. Not for giving comments — written comments are more effective for that — but for building system context understanding that can’t be gained from reading comments alone.
Mentoring review vs regular review:
Regular review:
→ Goal: ensure code quality before merging
→ Best medium: async comments
→ Meeting: only if there's a blocker
Mentoring review:
→ Goal: help juniors understand the system and improve skills
→ Best medium: async comments + occasional sync walkthroughs
→ Meeting: more often justified, but still purposeful
How to Run an Effective Review Meeting #
When a meeting is truly needed, there’s a big difference between a meeting producing real decisions and one that just spends an hour with no clear output.
Preparation Before the Meeting #
An effective review meeting starts long before the call begins. All participants must have already read the code and PR description before the meeting — a meeting isn’t time for reading together.
What must be prepared before the meeting:
By the author:
→ Make sure the PR has a complete description
→ Identify 2-3 specific points to discuss
→ Send the PR link to all participants at least 30 minutes before the meeting
→ Prepare a short summary: "I want to discuss X, Y, and Z"
By reviewers:
→ Read the PR and description before the meeting
→ Note questions or concerns prepared before the call
→ Don't re-read from scratch during the meeting
Rule: if participants haven't read the PR before the meeting,
the meeting must be postponed, not filled with reading together.
The Effective Meeting Structure #
sequenceDiagram
participant A as Author
participant R as Reviewer(s)
Note over A,R: Before the meeting (async)
A->>R: Share PR + agenda 30 minutes beforehand
R->>R: Read the PR, prepare questions
Note over A,R: During the meeting (15-30 minutes)
A->>R: Brief context (3-5 minutes)
Note right of A: "This is change X because Y,\nour discussion focus is Z"
R->>A: Main questions / concerns
A->>R: Discussion and clarification
Note over A,R: Decide: approve / what to revise
A->>A: Record decisions (live notes)
Note over A,R: After the meeting (async)
A->>R: Post summary in a PR comment
A->>A: Implement the agreed changes
R->>A: Approve the PRAn effective review meeting agenda (15-30 minutes):
Minutes 0-3: Author gives brief context
Not re-reading the PR — everyone read it beforehand
Focus: "What do we want to decide today?"
Minutes 3-20: Discuss specific points
Maximum 2-3 main points
If new points arise → note them for PR comments, don't dig in here
Minutes 20-25: Decisions and action items
Who needs to change what?
Does it need follow-up or can it merge right after revisions?
Minutes 25-30: Buffer and summary
Who will write the summary in the PR comment?
When will the author push the changes?
NOT done in the meeting:
→ Reading code from the first line
→ Commenting on style, naming, or trivial things
→ Opening new issues not on the agenda
Document Meeting Results in the PR #
This is the most often missed step — and the most often causing decisions made in meetings to simply disappear. After the meeting ends, a summary must be written in the PR comment before the call closes or within 30 minutes after it finishes.
## Example meeting summary in a PR comment:
**[Meeting Summary — 2025-02-15]**
Attendees: Ali (author), Budi (reviewer), Citra (reviewer)
Duration: 20 minutes
**Points discussed:**
1. Retry approach: agreed to use exponential backoff rather than
fixed intervals. Reason: prevent a thundering herd if the gateway just recovered.
2. Redis vs in-memory counter: agreed to use Redis because there are multiple
app instances. In-memory isn't safe for a distributed environment.
3. 5x retry threshold: Citra suggested 3x only to avoid high
latency in the worst case. Agreed on 3x with a ~7 second max total wait.
**Action items:**
- Ali: update the retry count from 5 to 3, push today
- Ali: add a code comment about the Redis selection rationale
- Budi & Citra: approve after the changes are pushed
**Not decided, followed up via PR comments:**
- Do we need a retry count metric? → Budi will add a comment
after checking existing metrics
This summary becomes a permanent part of the PR history — an engineer onboarding six months later can read it and understand why certain decisions were made.
Signs of an Unhealthy Review Meeting #
Several patterns show that code review meetings in a team aren’t running as they should:
Signals of problematic review meetings:
✗ Every PR has a scheduled review meeting, regardless of complexity
→ Indicates a habit, not a real need
✗ Participants read the code for the first time during the meeting
→ The meeting becomes an inefficient reading-together session
✗ Decisions made aren't written down anywhere
→ Knowledge is lost, the same discussion can repeat
✗ One or two people dominate, the rest are passive
→ The "many perspectives" benefit isn't realized
✗ Meetings always exceed the planned duration
→ The agenda is unclear or scope isn't bounded
✗ After the meeting, many trivial comments still appear on the PR
→ The meeting didn't solve the real problem,
it only added a process layer
✗ The team uses meetings to avoid writing written comments
→ "We'll discuss it in the meeting" as a way to avoid
the responsibility of giving concrete feedback in writing
These patterns are usually symptoms of deeper problems: a lack of trust that async review can work effectively, PRs too large to review comfortably, or a culture valuing “attending meetings” above “giving meaningful feedback”.
Building an Async-First Culture #
The transition from a meeting-heavy culture to async-first doesn’t happen naturally — it must be consciously built. Several steps that help:
Steps for building an async-first culture:
1. Agree on a shared principle
"Meetings for code review are the exception, not the default."
Write this in the team agreement or engineering guidelines.
2. Invest in PR template quality
PRs with good templates are easier to review async.
A reviewer who can't understand a PR without asking likely
means the PR isn't descriptive enough, not that it needs a meeting.
3. Apply clear review SLAs
"Review within 1 working day" removes the justification
for "let's schedule a meeting so it goes faster."
4. Normalize long written comments
Teams unused to writing long feedback in writing
will tend to think "a meeting is just easier."
Leaders need to model substantive review comments.
5. Evaluate existing meetings
Every time a review meeting ends, ask: "Could this have been
handled via a PR comment?" If the answer is often yes,
something needs to change.
Anti-Patterns to Avoid #
✗ Anti-pattern 1: meetings as a replacement for written comments
"It's hard to comment, let's just discuss it directly."
This removes documentation, forces participants to sync,
and benefits the verbal over the written.
✓ Write comments first. Schedule a meeting only if the discussion is stuck.
────────────────────────────────────────────────────────────────────────────
✗ Anti-pattern 2: meetings without agenda and without output
A 45-minute call, much discussed, no explicit decisions,
nothing recorded. Everything continues on the PR as if the meeting never happened.
✓ Every meeting must have 2-3 agenda points and end with
a written summary in a PR comment.
────────────────────────────────────────────────────────────────────────────
✗ Anti-pattern 3: inviting everyone to review meetings
The more participants, the fewer who truly contribute.
An 8-person meeting to review one PR is a huge waste.
✓ Invite only people who need to be involved in the decisions to be made.
At most 3-4 people for an effective code review meeting.
────────────────────────────────────────────────────────────────────────────
✗ Anti-pattern 4: reading code from the start during meetings
If participants only read the PR during the meeting, the first 15 minutes
are filled with silence and scrolling. This isn't discussion — it's a reading session.
✓ Require all participants to read the PR before the meeting.
If not yet read, postpone the meeting 30 minutes.
────────────────────────────────────────────────────────────────────────────
✗ Anti-pattern 5: using meetings as an "approval safety net"
"Rather than wrongly approving, let's meet first so everyone agrees."
This signals a lack of confidence in individual reviewer ability,
not a real need for synchronous discussion.
✓ Build trust that individual reviewers can and must make
their own decisions. Meetings aren't for avoiding review responsibility.
Code Review Meeting Checklist #
BEFORE SCHEDULING A MEETING:
□ Were async comments already tried — discussion stuck after 3+ rounds?
□ Is there a genuine design/architecture question needing discussion?
□ Does the PR touch a high-risk area needing all-stakeholder alignment?
□ Is there a mentoring or knowledge transfer need better served sync?
□ If none of the four conditions above apply: don't schedule a meeting
IF A MEETING IS SCHEDULED:
□ Agenda sent with the PR link, at least 30 minutes before the call
□ Participants limited — only those needing to be involved in decisions
□ Duration bounded: 15-30 minutes, no more
□ All participants read the PR before the meeting starts
DURING THE MEETING:
□ Focus on 2-3 main points, not sprawling into other things
□ Someone records decisions live
□ Every point ends with an explicit decision
□ Action items clear: who does what, when
AFTER THE MEETING:
□ Summary written in a PR comment within 30 minutes of the meeting
□ Summary covers: points discussed, decisions, action items
□ Author pushes changes based on meeting decisions
□ Reviewer approves after the changes are pushed
Summary #
- Meetings aren’t free — every meeting consumes engineering hours from all participants. Calculate the cost before scheduling.
- Async is the correct default — code review is a thinking activity, not a real-time discussion activity. PR comments give time for deep thought and document reasoning automatically.
- Meetings are justified in four situations — very complex logic, genuine design disagreements, high-risk changes needing alignment, and mentoring/onboarding sessions.
- Async-first, not async-only — if written discussion is stuck after several rounds, schedule a short meeting to break the deadlock, not keep debating via comments.
- Preparation is the key to meeting effectiveness — all participants must read the PR before the call. A meeting isn’t a reading-together session. If participants haven’t read it, postpone.
- A clear agenda = a short meeting — 2-3 specific points needing decisions, not “discuss this PR generally”. A meeting without an agenda is an inefficient meeting.
- Document meeting results in a PR comment — decisions never written down never happened. The summary must exist on the PR before the call closes or within 30 minutes after.
- Limit participants — invite only those needed in the decisions. An 8-person review meeting can almost always be replaced by the right 3 people.
- Meetings aren’t a substitute for written feedback — “we’ll discuss it in the meeting” as a way to avoid writing written comments is an anti-pattern that damages documentation and favors certain communication styles.
- Evaluate periodically — after every review meeting, ask: “could this have been handled via a PR comment?” The answer determines whether the team culture is right or needs changing.