By following the advice in this guide, you will become the most dreaded reviewer all around. You will consistently waste not only your own time, but also that of the author. You will learn to leave the most frustrating feedback on those pesky reviews for work that is subpar to your sublime craftsmanship.
Should you catch yourself applying a significant number of these anti-patterns during a review, STOP THE PROCESS IMMEDIATELY. Occupy yourself with whatever task you can tackle in a more satisfactory way. Come back when you are in the right mindset and start the process over. Delaying the feedback to improve its quality is worth the wait. There counter-intuitively will be less time wasted and less frustration felt on both sides.
You will have to spend your precious time looking at somebody else's crappy code again - time that you could spend doing your own superb work. Definitely start the process during the most busy time in your schedule. Review as much as possible in as little time as possible. Make it obvious that your feedback is rushed, that you rather not have to do it, and finally that you definitely looked at it with personal bias.
Since you didn't prepare, the easiest things to bring up in the review will be the ones that jump out at you on the screen. Is the code formatted using a different convention than what you use? Snipe about it. Do variable and function names give you dry heaves? Obviously, that's worth mentioning. This is all the more important in legacy code bases that do not have style guides and coding standards. Definitely do not use code linters and style checkers as pre-commit hooks.
Actually understanding the code would take time that you do not have. Focus your criticism on the visual aspect. Do not regard the intention behind structure. Focus on code bodies rather than clean interfaces. Encapsulation, control flow, invariants and interface contracts become less important when the code reads shakespearean (or like your own).
Assert that no creative process and subjective influences are present in your field of work. There is one singular truth you are aiming for. Preach it! Avoid discussions at all costs. Never ask for the intention behind decisions you disagree with.
Don’t cite documentation, formalized guidelines, and coding examples to back up any claim you make. Let the author firgure out why they are being asked to make a change. If you absolutely have to argue for your opinion, refer to your personal preference. This is most effective when reviewing the work of people with lower rank and autority.
State in very clear and short words what the author did wrong. Do not be gentle. Give no context as to why this is objectively the wrong thing to do. Provide your own and much better solution with no arguments to save time.
Make it your mission to have the author feel bad about themself for not using the perceived obvious solution. Hide your demands inside these obvious solutions. Having a discussion is always easier when the other person has to defend themself.
When requesting changes, do so with as little to go by as possible. Let the author figure out acceptance criteria by reading your mind. When referring to the work of the author, make it has hard as possible to understand which parts (if any) you approve of. Use as few characters as possible to save time and space.
Do not inform the author about parts of his work that you value. Do not reward them for their effort. Invest your energy soley into dissecting and gutting it. The author will be very glad you helped them recognize their faults. Dismiss any suggestions, ideas and topics for future discussions. They will only distract the author from implementing your changes.
Do not waste time re-reading the feedback before submission. Do not ask yourself if you would like to have your work reviewed in the same way. Don't worry about assigning blame, disappointing or frustrating. The author can take it.