Malicious code reviews: 11 tips to piss the whole team off
Disclaimer: Please do not take this post seriously, and happy Friday!
Your team has decided to adopt code review practice, and your perfect code now will be judged by someone else. Well, how dare they think they can find any issues with your brilliant code? On top of that, you need to spend your valuable time reviewing someone else’s code? That does it! Fight back the tyranny by following these simple rules:
If your code is about to be reviewed
- Commit all the features and bug-fixes you’ve worked on this week in one go, and ask for a review. Let them see how much work you’ve done.
- Invite the whole team to review your code. Everybody has to know how great your features are.
- Be original. Do not use spell checker, do not use static code analysis. Do, however, use ReSharper or IntelliJ IDEA to reformat code to your style, ignoring the company’s standards.
- Introduce a tricky bug on purpose. See if they’re smart enough to find it.
- Take your time. Got a code review assigned to you? Take your time, it’s not important. No, really, have a cup of tea, answer all unanswered emails, tweet something, see what you friends have been up to on facebook, go home. Why should reading someone’s code be more important than what you want to do? Feel free to ignore notifications for a week or two: you are busy.
- Take your time doing review. They wanted you to find issues? Don’t close the review until you find at least a dozen, even if it takes months.
- See a bug? Perfect! First, question the author’s intelligence, then, when your superiority is well established, demand a fix.
- Found an elegant solution to a problem? Don’t tell anyone, especially the code author, that you’re impressed. Keep it cool, act like you’ve always knew how to do things best.
- Embrace your inner grammar nazi: Focus on the spelling, it’s the most important thing! How can we misspell things and call ourselves professionals?
- Count all the spaces. Point out every bad indentation.
- Never compromise. Even if another solution offered by your teammate is better than yours. Stand your ground.
If you are reviewing someone else’s code