A grizzled veteran chortles as he lays into the poorly written code of a fresh-faced and overconfident new grad with a particularly arrogant attitude. Each line is peppered with a dazzling array of comments, imploring the poor soul to make at least a halfhearted attempt at following the company style guide, common sense, and good software engineering practices. Even the tests do not escape the righteous fury of the reviewer. And to top it all off, a long comment describes, in the most excruciating detail, all of the deep architectural flaws, complete with a few links to Martin Fowler.
Essentially none of the code should be written as it is, in the eyes of the reviewer.
The review stings the novice, and his overconfidence slowly fades after a few of them. Soon he turns to doubt. And then after a few more reviews, the comments become fewer and fewer. Anti-patterns melt away, burned off by the flames of the review cycle. Quickly, the comments turn from criticism to praise.
Diff by diff, the engineer transitions from new grad into a full blown software engineer, pushing back against certain feedback and holding his own in certain discussions. Each review is no longer the learning exercise that it once was, and the reviewer’s watchful eye no longer treats each line as an intruder.
With time, the reviewer even learns a few tricks. A new standard library function. A neat pattern. The student has become the master.
That to me is what code reviews are for: that joyous moment when an engineer has graduated from the position of learning hard-fought lessons with each and every diff under your careful review and landed the role of reviewer himself.
The moment when the reviewee becomes a great reviewer is an amazing sight to behold, and one that makes the drudgery of pointing out that this method shouldn’t quite exist all the more worthwhile.
To keep these moments coming, let’s get out there and review some code!