Skip to content

How to say it

How to defend your architectural decision in a PR

Explain technical trade-offs constructively without sounding defensive.

  • Feedback
  • Disagreement
How to defend your architectural decision in a PR

Direct Answer & Key Takeaway

Explain technical trade-offs constructively without sounding defensive. Validate the reviewer's reasoning first, then present the benchmarks or edge cases that drove your decision.

The moment

A reviewer left a comment on your pull request suggesting an alternative library or pattern. You considered that option earlier and found it inadequate for performance.

General advice

Validate the reviewer's reasoning first, then present the benchmarks or edge cases that drove your decision.

The full technique is in the app

Step by step, with practice in four formats and a review of your own answer by the AI coach.

Open the technique

Phrases that work

  • Good question! I tested that approach initially, but it caused memory spikes.

    Чудове питання! Я спочатку тестував цей підхід, але він викликав стрибки пам'яті.

    Shows you did due diligence before writing code.

  • The trade-off here is slightly more boilerplate for predictable O(1) lookups.

    Компроміс тут — трохи більше коду заради стабільного пошуку за O(1).

  • Happy to jump on a quick huddle if you want to walk through the benchmark.

    З радістю зідзвонюся на пару хвилин, якщо хочеш разом глянути бенчмарк.

  • Let me know if you see an edge case I might have overlooked.

    Дай знати, якщо помітиш граничний випадок, який я міг пропустити.

In a real conversation

ReviewerWhy not use the existing ORM helper instead of raw SQL queries here?

YouGood question! I tested the ORM helper initially, but it triggered an N+1 query loading thousands of rows. The raw query keeps the response under 50ms.

ReviewerMakes total sense. Thanks for clarifying—approved.

Common mistakes

  • Instead ofBecause my way is much better and cleaner.

    SayThe trade-off here is slightly more boilerplate for predictable O(1) lookups.

    Subjective arrogance creates friction in peer reviews.

  • Instead ofFine, whatever, I will rewrite it your way.

    SayGood question! I tested that approach initially, but it caused memory spikes.

    Passive aggression destroys code quality; explain your design rationale with data.

Code reviews are technical conversations, not personal scoreboards. Frame disagreements around measurable system constraints like latency, memory, and scalability.

Terms in this article