Giving and Receiving Feedback Questions

Direct answer

I reply to every comment thread saying what I did (changed it, or did not and why), push the fixes, re-request review, and give the reviewer a short summary of what changed. This matters beyond courtesy because it saves the reviewer from re-reading the whole diff, shows their feedback was heard, and keeps reviewers willing to invest time in my PRs.

Steps

1. Answer each thread. "Done in a1b2c3" (the short ID of the commit, a saved set of changes, that contains the fix, so the reviewer can click straight to it) for a fix, or "I kept it as-is because X, happy to change if you disagree" for a pushback. Silence on a thread looks like it was missed.
2. Push, then re-request review. On most platforms a reviewer is not notified that you are ready again unless you re-request. (A PR is a pull request: a proposed change a teammate reviews before it merges.)
3. Write a summary if there were several comments: what changed, what did not, and anything new that came up while fixing.
4. Resolve threads per the team's convention. Some teams want the reviewer to resolve; others let the author. Follow whichever your team uses.
5. Thank them briefly where it helped, specifically ("good catch on the null case"), not generically.

Worked example

A reviewer left three comments on a PR: (1) rename a variable, (2) handle an empty list, (3) split a large function. I fix 1 and 2, and I decide to leave 3 for a follow-up PR. My reply: "Fixed 1 and 2 in a1b2c3. For 3, splitting now would bury the bug fix in a refactor, so I opened a follow-up ticket. OK with you?" Re-request review. The reviewer sees in seconds what to look at (only the diff, the changed lines, in that commit) and can approve.

Why it matters

• Cycle time: the reviewer does not have to hunt for changes, so the PR merges sooner.
• Trust and signal: a reviewer whose comments vanish into silence stops commenting carefully.
• A record: the thread documents why a decision was made, which helps whoever reads this code later.
• Catching misunderstandings: if I fixed the wrong thing, the reviewer can say so now rather than after merge.

Pitfall

Do not mark threads resolved without replying when you disagreed; that reads as dismissal.

Direct answer

I would comment on the claim, not the author, ask for the evidence as a question, say what would change my mind, and mark which comments block approval. I push back when the claim drives a costly or hard-to-undo decision, accept when it is cheap to reverse and the design includes a way to check it, and move to a call when the thread has gone two rounds without converging, when the tone is tightening, or when the disagreement is about meaning (what the claim or the goal actually is) rather than about facts a benchmark could settle.

Example

The design doc says: "The new cache will cut p99 latency (the time within which 99% of requests finish) in half." There is no benchmark.

Comment drafts

• Question about the evidence: "This claim is the main reason for adding the cache, so I want to be sure of it. What workload and data size was this measured on, and what is the baseline? If you have not measured yet, could we add a quick benchmark to the doc, or mark this as a hypothesis with a plan to test it?"
• Say what would settle it: "A comparison of cache-on vs cache-off on a replay of last week's traffic (recorded real requests sent through both versions) would convince me."
• Label severity: start with "Blocking:" for the claim, and "Nit:" or "Optional:" for minor edits, so the author knows what must change.
• Acknowledge what is good: "The invalidation section (how stale cached entries get removed) is clear, and the rollout plan is thoughtful."

Push back or accept

When to move to a call

1. After two rounds of replies that still disagree.
2. When the thread is getting longer or the tone is tightening, since text hides intent.
3. When the author is likely to be discouraged by a stack of comments.
4. When the disagreement is about meaning, such as what "latency" or "fast enough" refers to, not about a fact a measurement could settle. A call clears up definitions quickly, while more text rarely does.

Accepting an incidental claim without a check is safe only if the thread says it is unverified, so nobody later builds on it as if it were measured.

After the call, write the outcome back into the doc ("agreed to benchmark on replayed traffic, owner Sam, due Friday") so the decision is on record.

Written feedback on a research-style draft

The same structure fits a colleague's paper draft: a short summary of what you understood the claim to be, then strengths (specific), then concerns ordered by importance (for example: the baseline is weak, the claim is stronger than the experiment supports), each with a suggested check, in a respectful tone. A concern written out: "The comparison is against a model with default settings, so the gain may come from tuning, not the new method. Could you add a baseline that gets the same tuning effort? If the gap holds, the claim is much stronger." Starting with the summary shows the author whether you understood them, which often removes half the disagreement.

Direct answer

I'll tell this as an illustrative story skeleton. A senior engineer on my project proposed that three new services (separate programs, each owned by a different team) share one database table (one shared set of rows and columns that all of them read and write). I was convinced it would cause cross-team breakages, and he outranked me. I prepared evidence, asked permission to give feedback, framed it as impact and questions, and offered an alternative to try, so the power gap shaped how I spoke without silencing the message.

Situation

He was respected and had designed much of the system. Several teammates had doubts but kept quiet. I was mid-level, and the design review (a meeting where the team examines a proposed design before building it) was in two days.

Managing the power gap

• Be sure I was right to speak: I had seen two schema changes (edits to a table's structure, such as renaming or removing a column) in the previous quarter break other teams' downstream jobs (scheduled programs that read that table and fail when a column they expect disappears). Picture one team renaming a column on Monday and another team's nightly report failing on Tuesday. That was observable, not opinion.
• Prepare and structure: I wrote a half-page: the two incidents, the risk if three services shared one table, and one alternative (each service owns its table and exposes data through an interface, a defined set of calls, instead of direct reads).
• Private first, with permission: "Could I give you a concern about the shared-table design before the review? I'd rather bring it to you than surprise you."
• Questions, not verdicts: "What happens to the other services when the orders table changes? I saw two cases last quarter where that broke downstream jobs."
• Own my uncertainty: "I may be missing a constraint."
• Offer a small test: "Could we try the owned-table approach for the first service and compare?"

What happened

He was quiet, then said I was right about the incidents but that separate tables would cost extra migration work (the effort of moving existing data and code onto the new layout). We agreed to a compromise: shared table only for read-only data (data services look at but never change), with owned tables for anything written. He credited the concern in the review. The relationship stayed good, and he later asked for my review earlier.

Do differently: I'd have raised it a week sooner, not two days before the review.

Pitfalls

Going over his head first, raising it for the first time in a public meeting, or arguing about whose opinion should count for more instead of pointing at observable impact. If the person is your manager, the same method applies, but state the impact on shared goals and what you need.

Direct answer

I would talk to them privately, use SBI (Situation, Behavior, Impact: one concrete moment, what they actually wrote, and what it caused), then show a rewrite and offer to help. Vague wording is usually a habit or a way to avoid being wrong, so I ask a question before I prescribe.

Short script (about a minute)

1. Ask permission and set the tone: "Can I give you some feedback on your status updates? I think it will make you look more reliable, and I want your read on it."
2. Situation and behavior: "In Tuesday's update to the launch group you wrote 'should be done soon'."
3. Impact (a fact, not a guess): "Dana asked what soon meant, then scheduled an extra sync to find out, and the partner team could not plan around it."
4. Ask: "What makes it hard to commit to a date in those updates?" Listen. Often the answer is fear of being held to a date, and that deserves a real response.
5. Offer the pattern: "Try three parts: current state, a date or range with your confidence, and what could move it."
6. Close: "Want to draft the next one together, and I'll read it before it goes out?"

Before and after

• Before: "Migration should be done soon, just a few things left."
• After: "Migration status: 4 of 6 tables are moved. The two remaining tables are the largest. Expected finish: Thursday noon, medium confidence. Risk: backfill speed on the big tables. I will post Wednesday end of day with a firm date or flag a slip."

The after version gives a state (4 of 6), a date (Thursday noon), a confidence (medium), a risk, and the next check-in. The reader can plan, and the writer is protected because the uncertainty is stated rather than hidden.

Trade-offs and pitfalls

• A date they cannot hit is worse than a range. Give a range such as "Wednesday to Friday" when the work is truly uncertain, and say why.
• Do not say "you are always vague"; use the single example. One example is observable, a label is an argument.
• If they push back that precision invites blame, agree that status updates should be safe for honest slips, and say you will back them when a flagged risk happens.

Direct answer

I'd first decide whether this is a pattern or just legitimate technical disagreement, then have a private conversation grounded in specific review threads and their impact, ask what is driving the resistance, agree on how disagreements will be settled, and follow up after a defined period. I'd keep "this is how decisions are being made" separate from "you are difficult."

Step 1: Check yourself and gather evidence

• Is the senior engineer sometimes right? Resistance can be valuable. I'd look at the last four or so reviews: did they push back with reasons, or block with no engagement?
• Write down 2 to 3 concrete threads: what was proposed, what they said, what happened (a change stalled for a week, the author gave up).

Step 2: Private conversation, impact-focused

"I want to talk about design review. In the retry-logic pull request (PR, a proposed code change sent for review), three comments asked for the same approach without a reason, and the author stopped replying. The change sat a week. I value your judgement on this system. How do you see those reviews?"

Listen. They may hold context you lack (an earlier outage), or feel their standards are being eroded. If so, ask them to write that context down, which helps everyone.

Step 3: Agree a working rule

For example: "If we disagree, the author and reviewer each write the trade-off in two lines and we pick by the criteria in the design doc (the written proposal for the system, which lists goals and constraints)." That moves the argument from personality to criteria.

If the dispute is technical, and if the resistance happens in a public thread

• ML modeling approach: if they resist a different model type, propose a small offline comparison (testing both models on saved historical data, with no live users involved) using the same data and the same metric, with the decision rule agreed beforehand. For example: "We run both on last quarter's data and measure recall at 90% precision. If the new model improves recall by at least 2 points, we adopt it; otherwise we keep the current one." Evidence replaces authority.
• Public forums: if resistance happens in a meeting thread, reply briefly on substance there ("good point, let's compare options") and move the personal part offline. Do not critique them in front of others; it damages morale and makes them dig in harder.

Step 4: Follow up

Two weeks later, re-read the new review threads and say what improved. For example: "Of the five design reviews since we talked, four had a written reason for each requested change and none sat longer than two days, down from a week. Thanks, that unblocked the team." If it persists, involve their manager after telling them.

Pitfalls

Do not frame it as "your attitude," do not skip listening, and do not assume rank equals being right or wrong.