How I review my own code (and why you should too)
The cheapest code review available: you, twenty minutes later, with a checklist and no ego. It catches more than you'd think.
By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer
Working mostly solo means no teammate reviews my pull requests. For a while I shipped unchecked, and my bug rate told the story. Now I review my own work — properly, not the fake skim where you approve your own genius.
The mechanics
I open the diff in a fresh view — different context from where I wrote it — and walk it line by line with a checklist. The twenty-minute gap between writing and reviewing matters more than any tool. The code is still fresh enough to explain, old enough to look strange.
The checklist
- Does the diff do what the commit message claims? Nothing more, nothing less.
- Would a stranger understand this in six months? Names, comments on the why, no cleverness that needs a footnote.
- What did I forget to handle? Errors, empty states, loading, permissions.
- What did I copy that I don't need? Unused imports, half-adopted patterns, AI boilerplate.
- Is there a test that would have caught today's fear?
The honest result
Self-review catches embarrassing things: dead code, secrets almost committed, that one console.log in the payment flow. Solo doesn't have to mean unreviewed. The reviewer is me, slightly later, slightly colder.
Keep reading
- Software engineering
Naming things is the whole job, sometimes
Most codebases don't have a naming problem — they have a thinking problem that shows up in their identifiers.
- Software engineering
Your README is your first interview
Before anyone judges your code, they judge your README. What a good one actually contains, from someone who reads a lot of them.
- Software engineering
The bug that taught me to read error messages properly
A three-line error sat in my logs for a week. It told me exactly what was wrong. I just never read past the first line.