5 Code Review Habits — That Make You the Engineer Everyone Trusts

You can write flawless code and still lose the trust of your team.

Because it is not only about the code you push. It is about how you review the code others push.

Code reviews are where reputations are built. Or destroyed.

If teammates feel safe, respected, and sharper after every review you leave, they will trust you. If they feel slowed down, judged, or dismissed, they will avoid you.

Not a Medium member? Drop a comment and you will get the free access link.

That is why the best engineers are rarely measured by lines of code. They are measured by the way they improve everyone else’s code.

Here are the five review habits that separate a teammate from a trusted engineer.

1. Read the Code as if You Own It

Lazy reviewers skim. Trusted reviewers dig.

When you open a pull request, do not glance at file names and sprinkle a few “LGTM” comments. That is not review. That is rubber-stamping.

Read it as if the code will run on your machine. As if you wrote it and must defend it in front of production logs at 2 AM.

Ask yourself:

• Would I merge this into my system today?
• Can I reason about its failure points?
• Does the naming make sense without context?

Pull requests are not checklists. They are commitments.

Example:

// Instead of vague variable names
int x = fetchData();
// Use intention-revealing names
int userCount = fetchActiveUserCount();

A trusted reviewer points out that “x” is not enough. They are not nitpicking style. They are saving future engineers from confusion during debugging.

Benchmark: A pull request once had a 120-line method with unclear loops. The developer defended it as “working fine”. After the review, they refactored it into 5 smaller methods, each with clear intent. Result? Readability improved, and the bug reproduction time dropped from 40 minutes to under 10.

Trust grows when you read code deeply, not quickly.

2. Comment Like You Pair-Program

A review is not an interrogation. It is a conversation.

Bad reviewers fire shots from a distance: “Bad naming.” “This is wrong.” “Why did you do this?”

Trusted reviewers write like they are coding beside you: “Would renaming x to userCount help make this loop clearer?” “I wonder if splitting these conditions might reduce complexity.”

One feels aggressive. The other feels collaborative.

Simple Example:

if (status == 1 || status == 2 || status == 3) {
    // process logic
}

Instead of saying, “This is ugly,” a trusted reviewer says: “Would an enumStatusType reduce magic numbers here? That way future contributors also avoid guessing what 1, 2, and 3 mean.”

Benchmark: After introducing enums in one service, the number of future change requests dropped by 45%. Team velocity increased because no one wasted cycles deciphering mysterious conditions.

When your comments sound like collaboration, developers listen.

3. Spot Design Leaks, Not Just Syntax

Reviewers who stop at brackets and spacing are replaceable by linters. Engineers who see design flaws become irreplaceable.

Trusted reviewers do not just say, “Your indentation is off.” They ask, “Will this function scale when 100K users hit it simultaneously?”

Architecture Example (Text Diagram)

┌──────────┐      ┌──────────┐
│  Client  │ ---> │  Service │ ---> Database
└──────────┘      └──────────┘

Current Issue:
All traffic funnels directly into DB writes.
At 100K requests/min, DB becomes bottleneck.

A trusted reviewer suggests a buffer:

┌──────────┐      ┌──────────┐      ┌──────────┐
│  Client  │ ---> │  Service │ ---> │  Queue   │ ---> Database
└──────────┘      └──────────┘      └──────────┘

Queue absorbs spikes, DB load is constant.

That single suggestion unlocks scaling without massive rewrites.

Benchmark: After adding a simple Kafka queue, DB write failures dropped from 12% at peak to nearly 0%. Those numbers get remembered.

4. Benchmark Small Fixes with Real Impact

Trusted reviewers understand that benchmarks speak louder than opinions.

Instead of saying, “This loop looks inefficient,” they run a quick test.

Example:

// Original loop
for (int i = 0; i < records.size(); i++) {
    process(records.get(i));
}

// Improved for-each
for (Record record : records) {
    process(record);
}

At first glance, both look fine. But on large lists, the first method incurs repeated .get(i) calls.

Running JMH microbenchmark:

• Indexed loop: ~420 ms for 1M records
• For-each loop: ~295 ms for 1M records

That is a 30% gain with one suggestion.

Benchmark Review Habit: Every time you back your review with numbers, not opinions, teammates stop debating and start trusting.

5. Do Not Just Review — Teach

The most trusted engineers leave reviews that elevate the entire team.

Instead of saying: “This query is inefficient”,

They say: “This query is inefficient. Here is why. Try using an indexed column, because it avoids full scans on large datasets.”

Then they point to a resource: a documentation link, a sample query, or a small benchmark.

Example refactor:

-- Original
SELECT * FROM users WHERE LOWER(name) = 'alex';

-- Improved with indexed column
CREATE INDEX idx_users_name_lower ON users((LOWER(name)));
SELECT * FROM users WHERE LOWER(name) = 'alex';

Query time dropped from 1.2 seconds to under 40 ms on a million rows. That is not just a fix. That is a lesson in indexing.

Engineers trust the person who helps them grow, not the one who only points out flaws.

Final Thought

Anyone can write comments. The trusted engineer writes reviews that shape the team.

• They read with ownership.
• They comment with collaboration.
• They spot design risks.
• They benchmark improvements.
• They teach through reviews.

That is how you become the engineer teammates wait for in their pull requests.

One careful review at a time.