How to Destroy Code Review Processes?
Edit: Folks, this article is written in a sarcastic way. All of the advice below of course lists red flags of code review processes. There are already lots of Best-Practice articles about the topic. Please use this one to check if you match any of the items and fix yourself.
Tired of your team’s quality software development bullshit?
Want to eliminate this unnecessary process? Do you want your authority to be unquestioned and your technical methods (which are already 100% correct) to be adopted? Are you uncomfortable with members of your team having their own opinions?
This job will be easier than you think. Here are ways to quickly undermine the Code Review process!
Set your tone in your feedbacks.
Spotted a bug or performance issue? Immediately match this situation with the personality traits of the person who wrote the code. If you can be so tough that you question how they make money doing this job, you won’t even believe the results you get!
Focus only on what matters.
And what matters is that the mistakes made are not repeated. So focus only on mistakes in your reviews, don’t waste time praising good things done. Have you seen a best practice? Or a good use of patterns? Anything to be appreciated? Remind yourself right away that this is what these people do, and that’s what they should do. So they expect a thank you for a job they’re paid for?
Humans are hierarchical creatures.
And there’s a reason you’re a leader, and that’s because you’re better at technical and managerial than any of them. So if you accidentally hear your decisions being questioned, your code being criticized, or talking about the possibility that you may have made a mistake, remember, what is being questioned is your authority. For this very reason, never admit that you made a mistake. If there is to be a code review process, it should be top-down.
Do your reviews at the right time.
Do code reviews as late as possible. Remember, the human mind can always focus on work in a limited capacity. So the bigger the job, the less chance your team has to focus. This will naturally reduce the time allocated to this process. The later the better. Remember 10 lines of code, 10 issues. 1000 lines of code, LGTM .
Measure what matters.
And there is only one thing that matters, the speed of the work done. Achieving short-term goals is important to you, while the long-term culture is for the company. So focus only on short-term successes. And the only thing you can brag about is how fast your team works and never makes mistakes. That way, if a mistake has been made, they start blaming each other, and boom! You are no longer alone in applying advice number two.
Use the tools according to your problems.
Disagreements among team members? Let them be reflected in the Code Review processes instead of speaking out. You can close the discussions caused by the lack of soft skills with hard skills in this way. Let technical knowledge be used as a hammer. In this way, the weak will be eliminated and you will have a team of only the best engineers, believe me.
Remove the obstacles.
Not having a reference point is critical for the above advice to work well. If you have a list of clear rules, the weak may also try to use it as a weapon against others. So remove the clarity, so that there is no obstacle in your way while behaving in a way that works for you in every situation. In this case, it is critical that you destroy a document full of best practices. Make it unusable. Also, make fun of reference points found on the internet and claim that they don’t know the ‘real’ business.
When you follow these recommendations, you will clearly see that your team will give up on this process and decide that it is unnecessary.
Good luck!
