How to run a miserable code review

Code reviews are a performance nobody paid for

Programmers need to check their work for errors. There are always small things that can get missed in testing. Many times having a second person look it over helps. Code should also be consistent, following a house style that makes it easy for everyone to work on any part of the system.

For these reasons, you should set up a Code Review Process that grounds all work to an absolute halt. Your goals for this process are to:

• show everybody how smart you are

• make sure that new people don’t get too confident

• play favorites

• have something to do with your day

• create a process that appears to detect and resolve errors, in a way that is unprovable

First, create the house-style document. You might not realize it while writing it, but this is likely the most lasting thing you will do in your life outside of having children. It is a great way to codify your views on how software Should be Done, while not working on software. You were chosen for this task for a reason (you either wanted to do it and chose yourself, or everybody hates you) and you should take the responsibility seriously.

Second, file the house-style document in a drawer.

Third, establish a process in which new developers have to attend a meeting with two senior members of staff (you and your best friend OR you and your nemesis) to get their code reviewed. They should start off talking about what the change is, while everyone looks over their code projected against a wall three times larger than necessary. While they are speaking, one of you nods your head and looks at them while the other looks at their laptop and mutters things like “oh no” and “this again” and “please god no”.

Once the overview is complete, bring the code up in your local environment, which has all warnings enabled, uses a custom linter that you wrote while drunk, and a font that you created while high. Your local setup should use neither light nor dark mode, but a combination in which each line of the code independently alternates between them on a randomized timer. Go through each warning and explain why it is a Big Problem and needs to be addressed, telling a 20-minute story of how each warning mattered in a previous version of the programming language. Frequently refer to the house-style document (point towards the drawer), which the programmer has never seen.

If your best friend is present, they should fall asleep about now.

If your nemesis is present, an argument begins on the validity of the warnings, or on the accuracy of your use of the term orthogonal earlier in the session.

Now focus in on more practical matters. Spend 15 minutes addressing a nit so small the programmer has to physically restrain themselves from rolling their eyes. The use of a null handling operator is a great candidate, as are whitespace conventions which devolve into a Unicode discussion, or local method variable names.

Ask unanswerable questions like:

• but how will the compiler view this in the future within a multi-verse scenario?

• is now the time to change our house-style document and have you rewrite all of this code with a new convention that we can’t agree on in this meeting right now?

• do you think we are living in a simulation, and if so is this code running in a separate runtime or could it crash everything?

• do we think that a future programmer, who was just in a serious car crash but still came into work, will understand this one-line change without proper context?

Tell them that their code is REJECTED until further notice (it helps if you have a sound effect), but that they can return later with corrections. If the developer has the audacity to make the changes live while you are speaking - wake up your friend and tell them to pull the fire alarm.