You Need a Code Review
On many of my projects, I have the pleasure of working with a team of highly skilled developers and designers to deliver a working, finished application. Many of these developers are shocked when I often ask for code reviews, or use a pull-request on github to deliver a feature, instead of just pushing it into master. It seems that I’m regarded as a senior developer, that should be above such formalities that prevent junior developers from making a build-breaking change, and as such, I should resent the idea of someone else auditing my changes.
I don’t resent it. I need it. I need a code review, on every significant commit.
Code Reviews Create Quality
Knowing that you’re writing code that someone else is going to read - not just down the line, but later this afternoon is the best driver of quality I’ve ever found - better even than automated test cases. You stop asking the question “Does the code just work”, and you start asking the other, more subtle questions: “Does this code scream its intent?” “Is there a better way I could be doing this?” “Is this clean?” “Can this be changed without fear of breaking it?” Code reviews create accoutability, and accountability is good! In addition, it forces you to practice what you preach, and write good test cases, use dependency injection, and all the other things that come with experience.
Code Reviews Prevent Mistakes
I view mistakes and bugs in a different bucket than quality. Quality code can have bugs, and bug-free code can be low-quality. Bugs are more often than not either the result of simple mistakes: forgetting that a certain method is destructive in nature, or of faulty assumptions of how the system is supposed to work. Code reviews mitigate both of these risks - opening up what is written to be checked against someone else who can examine the assumptions being made and validate them.
Code Reviews Transfer Knowledge
Having a low bus-factor is bad. Having a high bus-factor is good. Sharing what has been done across the team shares all the knowledge that led up to that code being written. Code is cheap. Ideas and execution are expensive. Sharing those ideas and the “why” of “what” backs up those intangibles the same way that a version control system backs up code. You wouldn’t develop without a version control system, would you? Then why are you developing without communicating the underlying ideas behind the system?
Code Reviews Teach
This is the biggest reason that senior developers should be getting code reviews from junior developers, and vice-versa. Code reviews provide an egoless way to teach correct patterns that have been learned from experience. Seeing an example of the elegance of the null-object-pattern and Hash#fetch at work is far better than any amount of lecture on the topic. Junior developers learn from this modelling, and senior developers can offer suggestions on better ways to do things, so there’s no time wasted later.
As leblaireau on reddit pointed out, this is not a unidirectional event. Often, new developers will join the team with expertise in areas that senior developers haven’t gotten a chance to learn yet. Code reviews are the perfect place for this kind of dialogue.
If you don’t need a code review, your team needs your code review. Put your ego aside and get one.