Please don’t practice any of the following “advice.” From junior developer to CTO of a Fortune 500, we’re all guilty of making mistakes within development. We’ve picked the worst examples we’ve seen around code review and pulled them together into one terrible, awful reviewer:
Look — I get it. You’ve done everything you could to ensure that no one would ever ask you to do a code review, but they’ve gone and promoted you anyhow. Now you have a whole team to bring down with you, down to the depths of a toxic code review culture.
This won’t be easy — making enemies never is — but if you follow these seven highly effective habits, no one on your team will even think about submitting a pull request. And less pushes means less work. Win-win.
1. Just the facts — opinions are for lesser developers
Don’t waste time leaving a comment that isn’t a straight fact. Remove softening language, like “I feel,” and never use “we” (unless you’re being passive aggressive). Adding, “Functional programming was passé last quarter, Brent” is sure to bring out the best in all of your teammates.
e.g.
2. Ask for architectural changes on styling pull requests
They’re already in there, right? Don’t let them be lazy, let’s tweak the database abstraction to handle an edge case you discovered on Klingon UTF support. Wait a minute… they aren’t adding tests for things that have nothing to do with the pull request? Better suggest those too.
e.g.
3. Remember ABA — always be attacking
Catchy acronyms about abusing others are no longer just for Sales. Any reasonable request can be improved by closing comments with “stupid” or “you moron” or “why did you write this?” Call out their apparent lack of knowledge. Bonus points for referencing that obscure, esoteric article about handling an adjacent but unrelated problem.
e.g.
4. All aboard the bandwagon
I got a fever, and the only prescription is using hacky, buzzworthy solutions I barely understand. Insist the author refactor to them. Because who knows? Maybe their implementation will help you with your side project that stalled.
e.g.
5. Tolstoy’s got nothing on you
Concise comments are overrated. What people admire and respect are loopy narratives that rival in length most Russian Realist epics. Try and sneak references to what you ate for breakfast and hope no one catches it. Bury valuable feedback under the dribble so you can point to it after the merge and complain bitterly that no one ever listens to you. Scrambled eggs.
e.g.
6. Aged like A Fine Wine
The best things in life take time, including your reviews. Make sure that developers and product sit blocked while you finish your much more valuable activities. Those memes aren’t going to share themselves.
e.g.
7. It looks good to me
Let’s face it. You’ve skipped the previous 6 items. Time to pull out the ol' classic — looks good to me. Why do we have QA if we aren’t going to keep them on their toes?
e.g.
Obviously, following even one of these habits can lead teams to certain doom, but we’ve seen shades of these traits in our own experience working with thousands of teams. We’re here to help developers form good habits that will improve code quality. Get in touch today.
Thanks to Adam Nemecek for reviewing an early draft of this post.
