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 software 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 fewer 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 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. Learn more about PullRequest’s today. code review as a service Thanks to Adam Nemecek for reviewing an early draft of this post. Originally published at www.pullrequest.com on August 17, 2018.
