GUIDE 2026

Code reviews: How I’d make them improve product quality

Josh Fechter
By
Josh Fechter
Josh Fechter
Josh Fechter
Josh Fechter is the co-founder of Product HQ, founder of Technical Writer HQ, and founder and head of product of Squibler. You…
More About Josh →
×

Review the change, not the person

I use code review to improve a change before it reaches users and to share understanding across the team. It is not a ceremony for proving who knows the most or a substitute for testing, design discussion, or good architecture.

I would make the purpose and risk of the change clear in the pull request. The description should explain what changed, why, how it was tested, and what reviewers should pay attention to. Smaller changes are generally easier to understand and discuss.

Use automation for repeatable checks

I would automate formatting, linting, type checks, security checks, and reliable tests where they provide value. Reviewers should spend their limited attention on behavior, design, failure modes, maintainability, accessibility, privacy, and product risk rather than arguing about machine-checkable style.

I would invite the right reviewers, avoid a single-person bottleneck, and set a response expectation that fits the team’s release needs. If a change needs a deeper design conversation, I would hold it before the review becomes a long comment thread.

Learn from the pattern

I would treat repeated review comments as signals for better examples, tooling, documentation, or pairing. I would also look at review age, rework, escaped defects, and developer experience without turning those measures into individual rankings.

A good review is specific, respectful, and timely. It improves the change, helps the team share context, and keeps quality responsibility distributed across the delivery process.

My bottom line

I use this approach to make the work clearer, not to add process for its own sake. Start with the problem, make the trade-offs visible, and revisit the decision when evidence changes.

If you are building the fundamentals behind this kind of work, the Product HQ technical product manager certification is a useful next step. I also share practical lessons in the Product HQ newsletter.

Josh Fechter
Josh Fechter
Josh Fechter is the co-founder of Product HQ, founder of Technical Writer HQ, and founder and head of product of Squibler. You can connect with him on LinkedIn here.