👀 Code Review Habits That Separate Good Tech Leads from Great Ones
Every tech lead reviews code. Not every tech lead reviews it well.
Reviews are one of the most frequent, most visible interactions you have with your team — which means small habits compound fast, for better or worse.
How you review code teaches your team more than any onboarding doc ever will.
Here’s what separates reviews that build engineers up from reviews that just slow everyone down.
🚨 The Default Failure Mode
Most tech leads review code the way they’d write it themselves — flagging every stylistic difference as if it were a bug.
The result: PRs with 40 comments, most of them opinion, none of them prioritised.
⚠️ If every comment carries the same weight, your team can’t tell which ones actually matter.
1️⃣ Separate “Must Fix” From “Just a Thought” 🏷️
Failing habit: Every comment reads like a blocker.
Better habit: Label your comments — blocking, suggestion, nit — so the author knows what actually needs addressing before merge.
Real-world example
A junior dev stops submitting draft PRs for early feedback because every comment, even tiny ones, felt like a failure. Once the lead starts explicitly marking nits as optional, the same dev starts asking for review earlier — because it’s safe to be imperfect.
🔑 Unlabelled feedback trains people to fear review, not seek it.
2️⃣ Review the Approach Before the Syntax 🧭
Failing habit: Commenting on variable names before asking if the approach is right.
Better habit: Skim for architecture and correctness first. If the approach is wrong, syntax nits are wasted effort.
Real-world example
A PR gets 20 minor comments before anyone notices it solves the wrong problem. The author has already spent a day polishing code that gets thrown away. A five-minute skim at the start would have caught it.
🧠 Nitpicking a flawed approach just makes the flaw better formatted.
3️⃣ Ask Questions Instead of Issuing Verdicts ❓
Failing habit: “This is wrong, do it this way.”
Better habit: “What made you choose this approach? Curious if you considered X.”
Real-world example
Framed as a question, the same technical disagreement becomes a conversation instead of a correction — and sometimes reveals a constraint the reviewer didn’t know about.
📣 A question invites context. A verdict just invites compliance.
4️⃣ Close the Loop Fast ⏱️
Slow reviews are their own kind of feedback — they tell your team that shipping isn’t actually a priority.
🔄 A 48-hour review turnaround teaches your team to context-switch away from finished work. A same-day one keeps momentum.
🔚 Final Thought
Great code review isn’t about catching every issue. It’s about leaving the author — and the codebase — better than you found them, without making review something people dread.
Get my 3 free e-books by signing up to my newsletter and see more blogs on my site — or check out videos on the Imran Codes YouTube Channel!