Nguyen Le PhongNguyen Le Phong

Giving Constructive Feedback

A calm reflection on constructive feedback: how specific observations, timing, care, accountability, and follow-up help people improve without turning feedback into blame or performance theater.

I once spent ten minutes rewriting one code review comment while my coffee went from warm to almost forgotten. The technical point was simple: the change mixed a data migration with a UI adjustment, and it would be safer to separate them. The human point was harder. I did not want the comment to sound like a verdict on the person who wrote it.

Constructive feedback is not just negative feedback with softer words. It is information given with enough care, context, and clarity that another person can use it. If the person leaves only feeling judged, the feedback may have been accurate, but it was not very useful. If they leave feeling comfortable but with no idea what to change, the kindness was incomplete. The balance is practical, not decorative.

The first discipline is to describe behavior before interpretation. “This PR changes the schema, API response, and dashboard copy in one release” is easier to work with than “this is messy.” “The meeting ended without an owner for the incident action item” is clearer than “we are not accountable.” Specific observations lower the emotional temperature because both people can look at the same event instead of debating character.

Impact comes next. A piece of feedback becomes easier to receive when the person understands why it matters. A large PR may slow review and increase rollback risk. A vague ticket may make QA guess acceptance criteria. A sharp message in Slack may cause someone to stop asking early questions. Impact connects behavior to system consequences. It also protects feedback from becoming personal preference disguised as principle.

Then comes a concrete request. “Can we split the migration from the UI change?” is more useful than “be more careful.” “Please include one example input and expected output in the ticket” gives the next step. “In incident review, let’s assign one owner before we leave the room” creates a behavior the team can practice. Constructive feedback should make tomorrow a little clearer.

Timing matters more than people admit. Feedback given in the heat of frustration often carries extra weight that does not belong to the actual issue. Feedback delayed for months turns into a surprise performance review. The healthier rhythm is closer to the work, but not careless. A private note after a tense meeting, a review comment attached to the exact code, or a short one-on-one conversation can keep the moment small enough to learn from.

Good feedback also respects power. A senior engineer, manager, tech lead, or staff engineer may think they are “just being direct,” but their words land with more force. The same sentence from a peer and from a promotion reviewer can feel very different. This does not mean avoiding hard feedback. It means being precise, checking assumptions, and leaving room for the other person’s context before deciding the whole story is already known.

Receiving feedback is part of the culture too. If every correction becomes a debate, people stop offering useful signals. If every piece of feedback is accepted without thinking, people learn to perform agreement instead of judgment. A calm response can be simple: ask for an example, restate what you heard, decide what you will change, and explain what you see differently if needed. Feedback is a conversation, not a court ruling.

Follow-up is where trust accumulates. A manager who gives feedback and never checks whether support is needed is only transferring pressure. A teammate who points out a review problem but helps define a smaller PR shape is building a better system. A person who says “I noticed this was better in the next release” turns feedback from a painful moment into a visible path of improvement.

I still rewrite comments sometimes. Not because every sentence must be perfect, but because feedback is one of the places where engineering culture becomes real. The goal is not to sound gentle while avoiding truth, or to sound strong while ignoring people. The goal is to help someone see the work more clearly and still feel invited to keep growing. If you have received feedback that stayed with you for the right reasons, it may be worth noticing what made it usable.

What did you think?