Code review is a good thing. It helps to improve code quality, establishes team collaboration, and encourages developers to get acquainted with the most remote corners of the source code they wouldn’t have visited without a code review. Of all things that programmers usually do, it is code review that best reflects the truth of the proverb “Two heads are better than one”.
But what about those programmers who work alone? How could they have an independent code review having only one head - unless they are mutants. It is exactly with this head they write code which then has to be reviewed. How can the author look at his code through another person’s eyes? It seems to be an impossible task, an unsolvable problem, a dead end!
But there is a solution! From biology we know the human brain has two fairly independent parts - brain hemispheres, each of which sees the world through its own eye connected crosswise: the left hemisphere through the right eye, and the right hemisphere respectively - through the left one.
This is exactly what makes independent code review possible for a single developer! Because when writing a program, we use our brain as a whole, both of its hemispheres work together and in principle represent a fundamentally different system than each brain part separately. Thus, if you could see your code from the single hemisphere point of view, it would be rough analog to an independent code analysis. To look at the code with only one hemisphere you can use a simple medical bandage or covering which covers one of your eyes while the other eye and its attached cerebral hemisphere review the code.
With this approach there are even more features you can use! Biologists believe that brain hemispheres have specializations: the left one is responsible for logic and the right one is in charge of creativity, intuition, and aesthetic perception. Therefore, code review with the right eye engages the left part of the brain which, in theory, should be better to find code logic issues. And code review with the left eye could, in theory, be better at discovering the aesthetic code flaws, like its style consistency and architectural solutions elegance.
Of course, your own code’s review shouldn’t be done immediately after writing it! Have a tiny rest that helps you abstract from the code, change your minds, enter a different mood. Even more efficient is switching to a different activity like doing physical exercises, watching a movie, reading a book or even drinking a small amount of alcohol - it helps you to completely change your mood and look at your code through the eyes of another identity. Keep in mind the amount of alcohol should not be too big, or your changed identity would become completely illogical. There are also a lot of other mind-changing approaches, but we’d prefer not to go into the details and leave it at that.
After a break and changing the state of your mind, you are ready to review the code. It is better to do this in rounds: first do the code review with first eye, then repeat with the second one. As with a regular review, the found issues should be immediately described in code-review comments.
When review is done, it is necessary to have a rest again. After which you can start to fix the found code flaws, this time - with both of your eyes. If there are controversial and debatable code review notes - discuss them in the comments. At the next code review round, the brain hemisphere that has written them will consider your answers and maybe continue the discussion. After several code-review rounds there are usually no questions left for the code and the code review could be considered complete.
Of course, you should make your comments as correct, inoffensive, and polite as possible, because you wouldn’t like to have a row with yourself! And remember to be careful with the mindset-changing stuff and personality splitting - otherwise you’ll give the neurologists and psychiatrists one more reason to tell funny stories about quirky IT people.