← Back

What to Look for in Code Reviews

Franco Fernando Read Mar 13, 2026 Published Jul 25, 2025 blog post

Key Ideas

Design Review Comes First

Design problems are the most expensive to fix later, so I should check whether new code fits the existing architecture and lives in the right place before anything else. If a new developer couldn't find the code in six months, it's probably in the wrong spot.

Check Functionality Beyond Tests

Automated tests don't catch everything, so I need to manually think through edge cases, race conditions, and resource leaks like unclosed database connections. Sometimes I should ask for a demo or test the feature myself rather than just reading the code.

Complexity Is a Hidden Cost

Complex code takes longer to understand, is harder to change safely, and is more likely to contain bugs, so I should flag functions that do too many things at once. Over-engineering, like adding abstractions with only one implementation, is just as harmful as under-engineering.

Structure Reviews With Priority

Randomly scanning code changes leads to focusing on the wrong things, like style over bugs, so having a structured order starting from design down to details makes reviews more effective. The highest-impact issues should get the most attention first.

Actionable Insights

Prioritize design issues before style in code reviews

Start every code review by evaluating whether the change fits the existing architecture and belongs in the right layer. Design problems are the most expensive to fix later, so address them first before moving to functionality, complexity, or style.

Check for resource leaks and concurrency issues manually

Specifically look for unclosed files, database connections, or sockets, and trace paths where exceptions might skip cleanup code. Race conditions and deadlocks depend on timing and are rarely caught by automated tests, so reason through concurrent logic explicitly.

Ask whether a new developer could locate and change this code in six months

Use this question as a litmus test for code placement. If the answer is no, the code is likely in the wrong module or class, even if it technically works — for example, business logic hidden in utility classes or UI code inside a data access layer.

Evaluate function scope by checking for single responsibility violations

If a single function handles input validation, database access, and notifications simultaneously, flag it for decomposition. Functions that do too much are harder to test, harder to change safely, and disproportionately likely to contain bugs.

Related

Newport - How To Plan Better Simple Analog System
Both texts focus on structured, systematic approaches to professional work that improve efficiency and ensure important tasks receive proper attention.
Diamandis - AI Chief of Staff Who Never Sleeps
Both pieces touch on AI tools augmenting software and knowledge work workflows, with the code review article referencing AI-assisted review tooling like CodeRabbit.