A Software Engineer’s Guide to Giving Feedback that Actually Matters

Summary

The post presents feedback as a professional tool that can either support growth and collaboration or fuel ego-driven competition. It focuses first on pull request reviews, where engineers should prioritize critical code and logic over stylistic nitpicks, use linters or pre-commit hooks for uniform formatting, and frame comments to preserve a two-way educational dynamic. Recommended practices include discussing team review processes, explaining feedback goals, drafting messages before sending, reinforcing strengths, asking questions, separating behavior from identity, and making comments specific and timely. For broader workplace issues, the post advises asking whether feedback must be said, by the speaker, and immediately, then using considerate timing and SMART framing to improve the chance that it will be heard and produce change.

Context

Feedback can foster individual and company growth when it is productive, but feedback driven by ego can create unhealthy competition and prevent people from learning. For engineers, failing to raise issues in code or architecture can contribute to unstable systems and recurring bug fixes, while unresolved behavior problems can harm colleagues, teams, and the company.

Approach / What changed

The post offers concrete guidance for pull request reviews and workplace conversations: focus reviews on important code concerns rather than style nitpicks, automate opinionated formatting with a linter or pre-commit hook, establish team expectations, explain the purpose of feedback, draft messages before sending, acknowledge what works, ask questions, separate behavior from the person, and make feedback specific, measurable, achievable, realistic, and timely. It also recommends evaluating whether feedback should be delivered, by whom, and when.

Takeaways

• Style preferences such as brace usage and file formatting should not dominate pull request reviews; linters and pre-commit hooks can enforce these opinions instead.
• Asking questions, reinforcing positive work, and separating a person from their behavior can make critical feedback more collaborative and easier to accept.
• Before giving workplace feedback, consider whether it needs to be said, whether you are the right person to say it, and whether the timing will help it be heard.

Related reading