Five patterns that sneak past code review.
As an engineer who often ends up on the receiving end of "final" implementations, I've developed a pretty good radar for code that looks correct, sounds convincing, but is fundamentally flawed. Not because the person who wrote it was trying to cut corners, but because they were confident, loud, and wrong.
This isn't a gripe session. It's a pattern catalog. A short guide to the red flags I've learned to spot, and how I clean things up without making enemies. These aren't rare cases. They're recurring, subtle mistakes that sneak in when ego outruns experience.
The feature runs, the API returns data, the page doesn't crash. Check.
No attention to deployment context, latency, scaling, edge cases, or team consumption. What works on one machine isn't the same as what works in prod, across environments, or over time.
Treat local success as necessary but not sufficient. Ask: "What assumptions does this success rely on?" and "How does this scale?"
It technically explains why the client is seeing unordered data. It's a real observation.
It outsources responsibility for API contract integrity. Consumers shouldn't care how the DB behaves. If the order matters, it should be guaranteed at the API layer.
Sort where the contract lives. Define API response shape intentionally, and treat DB behavior as an implementation detail.
Fast patch. Easy diff. Problem "solved."
You've solved it twice and made it fragile. Business logic in the UI, duplicated across every client.
Fix it once, at the source. Every workaround increases future confusion.
You're using known defaults and libraries. Why reinvent?
Blind trust in framework magic often means giving up control. If you don't know how it works, you don't know what it breaks.
Use frameworks with curiosity, not faith. Know where the magic ends.
The code looks clean. The change seems small. The function already exists.
You're ignoring integration complexity, test coverage, performance, or all the unknowns buried in that assumption.
Assume friction, and validate it. "Should be easy" means "Let's verify it's actually easy."
Confidence isn't bad. But unexamined confidence is the root of so much rework. I've learned to read confident code not as wrong, but as unfinished. It hasn't yet been tested by time, teammates, and context.
The next time you feel the urge to patch around something that "mostly works," ask: Is this actually the right layer to solve this? Will this hold up under pressure? Or am I cleaning up someone else's shortcut with a shortcut of my own?
The more often you ask those questions, the fewer messes you leave behind.