// Leadership
Stop reviewing semicolons. A practical checklist for reviewing design, correctness, security and operability — and giving feedback people learn from.
Md Nayeem HossainFeb 3, 20253 min readWhen I became a team lead, I realised my reviews were mostly about style: variable names, missing semicolons, the order of imports. Useful, but a linter does that better and faster. The reviews that actually prevented incidents and taught people something looked very different.
This is the mental checklist I use now, roughly in order of importance.
Before reading a single line, read the ticket and the pull request description. Then ask:
The most expensive mistakes are not bugs in the implementation. They are correct implementations of the wrong design. Catching those early saves days.
Happy paths usually work; the author tested them. I look for what happens when things go wrong:
1// Looks fine, but two concurrent requests can both pass the check2const count = await repo.count({ where: { userId } });3if (count >= MAX_PROJECTS) throw new ForbiddenException();4await repo.save(project);Pointing out a race like this, with a suggested fix such as a database constraint or a lock, is worth more than fifty style comments.
Every change that touches input, authentication or data access gets a security pass:
Broken access control is consistently at the top of the OWASP list for a reason: it is easy to miss in review because the code "works".
Will we be able to run this in production?
I check whether the tests would fail if the code were wrong. Tests that mirror the implementation line by line break on every refactor and catch nothing. Good tests describe behavior: given this input, the user sees this result.
Code is read many more times than it is written. I look for clear names, small functions with one responsibility, and comments that explain why, not what. If I needed to read a function three times to understand it, the next engineer will too.
The checklist matters, but how you deliver feedback decides whether people learn from it or resent it.
blocking:, suggestion: or nit:, so the author knows what must change and what is optional.The best predictor of review quality is pull request size. Under about 400 lines, reviewers find real problems. Above that, they skim and approve. Encourage small, incremental changes and stacked pull requests for larger features.
Leave formatting to tools and spend your review time on design, correctness, security and operability. Deliver feedback with clear severity and explanations. Done well, code review is not a gate — it is how a team shares knowledge and raises its standard together.