Imagine you're a surgeon, preparing for a delicate cardiac procedure on a challenging case. You've prepared thoroughly, sterilized your instruments, and reviewed the patient's history. The operation is critical.
Or perhaps you're standing as the veteran consulting surgeon. Your job is to provide guidance, spot potential issues, and ultimately ensure the procedure meets the highest standards.
No matter which role you're in, you're responsible for making sure the patient leaves the hospital alive and kicking.
There's only one problem (or perhaps many) … you're both making some questionable decisions.
Welcome to code review anti-patterns, surgery edition.
The Mega Incision
You've planned a focused bypass procedure. But you've decided to also insert a stent, clean some arteries, and install a pacemaker while you're at it.
What's the problem: You've changed too much at once. Review becomes impossible. Nobody can follow what changed or why. Subtle issues slip through.
What to do instead: Smaller, focused requests. One clear purpose per PR.
Patient Chart? What Patient Chart?
You've completed hours of delicate work, potentially saving the patient's life. But on the chart, all you wrote was "Fixed stuff. Surgeon out!"
What's the problem: You left no useful PR description. The reviewer is left guessing what changed, why it changed, and what to look for.
What to do instead: Summarise what you did, include the why, and anything else the reviewer needs to know. Screenshots and annotated diffs help.
Instruments Left Behind
The patient came in for a bypass but received a pacemaker too. You've always wanted to install one and decided you knew best.
What's the problem: Unrelated changes make the PR noisy and risk side effects.
What to do instead: Stick to the ticket. Raise new ones for linting or unrelated fixes.
Post-op Modifications
After the senior surgeon made suggestions, you waited until they left, reopened the procedure, and made significant changes without telling anyone.
What's the problem: You force-pushed unreviewed changes. The reviewer has no idea what's different and takes the blame when complications arise.
What to do instead: Highlight all post-comment changes. Ask for a follow-up review. Don't bypass the process or force-push to dodge review.
Defensive Medicine
The consultant suggests using a different surgical approach. You respond, "If you think you can do it better, then do it yourself!"
What's the problem: Taking feedback personally wastes energy. It blocks learning and makes collaboration harder.
What to do instead: Treat comments as collaboration. You're on the same team.
Vital Signs You Say?
You rush through the procedure without following proper protocols. No vitals checked. No tests. No documentation.
What's the problem: Without a checklist, things get missed. The process becomes inconsistent.
What to do instead: Agree on a standard PR checklist and complete it every time. It should cover test coverage, screenshots, naming, style, and more.
The Absent Consultant
On the other hand, maybe you aren't the operating surgeon. Maybe you are the experienced consulting surgeon reviewing the procedure. You were asked to attend surgery. You took four days to respond, and when you finally showed up, the patient was in critical condition.
What's the problem: You've put the sprint at risk. No time remains for fixes or review cycles.
What to do instead: Make time. PR reviews are part of the job, not an interruption.
The Nitpicker
You spend 90% of your time critiquing instrument grip. You debate suture styles while overlooking several critical medical issues.
What's the problem: Nitpicking wastes time and goodwill. It adds no value and looks pedantic.
What to do instead: Focus on logic, accuracy, risk, testability, and design. Let the small stuff go.
The Drive-By Commenter
The surgeon struggled, and your only input was "why?" or "wrong!" No guidance. No explanations. Just frustration.
What's the problem: One-liners are useless, or worse, disrespectful. Developers need clarity to learn and improve.
What to do instead: Be specific and kind. Explain the concern. Suggest alternatives.
Rubber Gloves, Rubber Stamps
You don't want to get involved. You skim the procedure notes, miss the problems, and stamp "LGTM" on the chart. Looks good to me.
What's the problem: You're not paying attention. You gloss over the code without any comments and then hit approve without any real understanding of the PR.
What to do instead: Take it seriously. The quality of the team's work reflects on all of you. Dig into the detail.
Hijacking the Operation
You've taken control and pushed the surgeon aside. You've made so many suggestions that the surgeon doesn't know where to start. There's so much rework required that it will take days. Time the patient doesn't have.
What's the problem: You've turned the review into a control exercise. You're undermining the developer and worse, you are probably enjoying the power a little too much.
What to do instead: Guide, don’t dictate. Politely explain why something is wrong and offer reasonable options.
The Oblivious Diagnostician
You are so focussed on the technical procedure that you haven't considered why the patient even needed it. You've missed that the intervention might negatively impact the patient's quality of life.
What's the problem: Reviewing code in isolation ignores its impact and implications.
What to do instead: Understand the broader context and consequences of changes.
The Autopsy Report
You were silent during the procedure but had all the answers after complications arose.
What's the problem: Feedback after deployment is too late.
What to do instead: Treat the PR as your last chance to improve the code.
Postmortem
Never forget that both parties want the same thing: a stable, healthy, working codebase. Reviews should be timely, focused, respectful, and collaborative. Avoiding these anti-patterns makes everything smoother, reduces conflict, and improves outcomes.
Now where did I leave that scalpel?
By Ryan Mulholland - Solutions Architect
