How to give and receive technical feedback: a guide for engineering teams

Giving and receiving technical feedback effectively

• Be specific and objective

  • Describe the behavior or artifact, not the person. For example: “The function takes 32ms on average for 1000 samples, which is higher than our 5% budget,” rather than “You’re slow.”
  • Cite concrete measurements, data, or reproduceable observations. Include before/after snippets or benchmarks when possible.

• Frame feedback around impact

  • Explain why it matters: correctness, maintainability, performance, security, or onboarding.
  • Tie suggestions to business or product goals: faster iteration, fewer bugs in production, clearer API surfaces.

• Separate personal from technical

  • Acknowledge intent: “I know you aimed for a robust solution, and here’s how we can improve it.”
  • Focus on the artifact, not the coder. Use language like “this approach” or “the current abstraction” instead of “you,” “your code,” or “you always.”

• Use a clear structure for code reviews

  • Start with praise for what works well to set a constructive tone.
  • State the issue: what is observed and where it occurs.
  • Explain the impact: why it matters in context.
  • Propose concrete, testable actions: refactor, add tests, rename, or extract a function.
  • Invite collaboration: ask for others’ perspectives or suggest pairing.

• Deliver feedback at the right level

  • Frontload high-leverage items: critical correctness, security, or API breaking changes.
  • Defer cosmetic or minor issues to a later pass or a separate PR where appropriate.
  • Align with the team’s agreed standards and style guides.

• Use a collaborative tone

  • Phrasing matters: “Have you considered X as an alternative?” rather than “X is wrong.”
  • Ask questions to surface assumptions: “What edge cases does this handle?” “What happens under load?”
  • Offer help: “I can draft a quick unit test or help implement the refactor.”

• Provide actionable alternatives

  • Include multiple options when appropriate: “Option A preserves behavior but adds more coupling; Option B decouples with a small API surface change.”
  • Include rough estimates of effort and risk to help decision-making.

• Encourage good testing culture

  • Require tests for behavior changes and document expected outcomes.
  • Review test quality as part of feedback: “These scenarios aren’t covered; can we add tests for them?”

• Distinguish correctness, style, and architecture

  • Correctness: ensure the code does what it’s supposed to.
  • Style and readability: naming, structure, and comments.
  • Architecture and design: module boundaries, coupling, and extensibility.
  • When suggesting architectural changes, present the long-term benefits and risks.

• Manage defensiveness in receiving feedback

  • Pause before replying; take time to digest, especially if emotionally charged.
  • Ask clarifying questions: “Can you show me an example where this fails?” or “What would you suggest as a measurable goal?”
  • Reflect and summarize back: “So you’re concerned about X; if we fix Y and add Z tests, we’ll have stronger robustness.”
  • Separate the identity from the critique: remind yourself that feedback targets the work, not you as a person.

• Handling criticism without defensiveness

  • View feedback as a learning signal, not a verdict on competence.
  • Identify one concrete takeaway you can act on in the next iteration.
  • If you disagree, propose a test or experiment: “Let’s run a small benchmark to compare approaches and decide.”

• Create a feedback-positive team culture

  • Normalize regular, lightweight feedback loops: weekly review mini-checkins, async comments, or “retrospective light” after major milestones.
  • Celebrate improvements and learning moments, not just flawless code.
  • Establish a shared glossary of terms and a decision-making framework (e.g., when to refactor now vs later).

• Practical workflow for architecture discussions

  • Define the decision scope: scope, constraints, and success criteria.
  • Edge-case mapping: list known edge cases and how each proposal handles them.
  • Pro/Con ranking: score proposals on clarity, risk, and long-term maintainability.
  • Document decisions: capture rationale and trade-offs in PR or design doc.

• Real-world examples

  • Example 1 (refactor for clarity): In a module with nested conditionals, propose extracting the decision logic into separate strategy objects. Rationale: simplifies testing, enables swapping strategies, reduces cognitive load.
  • Example 2 (API design): When a public API exposes a broad interface, suggest splitting into a focused, minimal surface with clear deprecations. Rationale: reduces client confusion and accelerates onboarding.
  • Example 3 (performance): If a hot path shows latency spikes under load, present a micro-benchmark, identify bottleneck, and propose a targeted optimization with a measurable impact (e.g., 20% faster on 95th percentile).

• Quick checklists

  • For giving feedback: Is it specific, data-driven, and tied to impact? Is it respectful and actionable? Does it offer alternatives or collaboration?
  • For receiving feedback: Have I identified the core issue, the impact, and a concrete next step? Did I ask clarifying questions?

• Example dialogue snippet

  • Reviewer: “I noticed the function averageResponseTime includes a try-catch that masks intermittent timeouts, which can hide real failures. This makes monitoring harder. Could we narrow the catch scope or surface the error so alerts still fire? An alternative is to move error handling to a centralized layer and add a targeted test for timeouts.”
  • Developer: “That makes sense. I’ll refactor to centralize error handling, add a timeout test, and share the proposed API change in a quick PR.”

• Build a habit that sticks

  • Schedule regular feedback rituals (peer reviews, design reviews, and retrospectives).
  • Keep a shared docs repository with style, testing, and architecture guidelines.
  • Rotate feedback buddies to diversify perspectives and reduce blind spots.

If you’d like, I can tailor this into a short, ready-to-post guide for your team, or create a one-page checklist you can print and keep near your workstation. Would you prefer a version focused on code reviews, or one that equally covers architecture discussions and team settings?

-

Rizwan Saleem | https://rizwansaleem.co