Looking for a chance to stick it to your colleagues? What better place than a Code Review? Aside from boring stuff like quality assurance, knowledge transfer, or bug prevention, there is so much more to get out of it.
In reality, Pull/Merge Requests are the perfect arena to assert dominance, settle old scores, and ensure that absolutely no one wants to grab lunch with you ever again.
Here is the ultimate guide for the Reviewer from Hell:
1. The "Whitespace Warrior"
Ignore the business logic. Ignore critical security flaws. Scroll straight to the bottom and hunt for trailing spaces or incorrect indentation. Comment on every single blank line with "Please remove."
Pro-Tip: If the colleague uses tabs, demand spaces. If they use spaces, demand tabs. Claim that the team's IDE settings "just changed."
2. The Mysterious Oracle
Write comments that say absolutely nothing but sound profound. Classics include:
- "Is this really the right approach?" (without suggesting another one)
- "Ugly."
- "Refactor this."
Let your colleague guess what exactly is bothering you. If they ask for clarification, wait until the next day to reply with a link to the programming language's entire documentation.
3. The Character Critic
Factual criticism is for beginners. Pros get personal! Instead of pointing out logical errors, question your colleague's life choices.
- "Did you write this in your sleep?"
- "That looks really... 'creative', if you're into spaghetti."
- "Brave to commit something like this. Respect."
Important: Never offer a solution. Your only goal is emotional destabilization, not better code.
4. The Architecture Astronaut
Your colleague wrote a simple function to join two strings? Too simple! Demand that they create an AbstractFactorySingletonProxyBean for it.
Complain that the code isn't "future-proof" otherwise, and insist on design patterns that no one understands and that make the problem three times as complex.
5. Passive Aggression (Nitpicking Edition)
Use variable names to subtly question the author's intelligence.
- "I thought we agreed last week to use camelCase?" (You didn't).
- "Interesting choice. A Senior Developer would probably solve it like this, though..."
- "It works, sure, but my 12-year-old nephew writes cleaner code in Scratch."
Conclusion:
If you follow these 5 points consistently, I guarantee you an absolutely conflict-free time at the office – mainly because no one will talk to you anymore. Happy Reviewing!
