As a team member at Treehouse, I do a lot of code review. In fact, I have reviewed over a thousand Techdegree student projects, I frequently review my coworker’s code, and I even occasionally make a pull request on a major open source project.
There’s a lot of different ways to review code and many systems built to facilitate the process, but ultimately all code review boils down to the act of checking and commenting on someone else’s code. You’re responsible for reading the source code and looking for maintainability and useful patterns, running the app and checking it against user stories, as well as trying to find any unexpected errors or input that might break the app. Then you report the things you find – both positive and negative – to the programmer to help them improve their code or to encourage them to keep coding that way.
I love reviewing code. It allows me to help our Techdegree students and my colleagues learn and succeed, contribute to huge projects like Angular, and has made me a better programmer. But when I first began to code review, there were a couple misunderstandings I had to let go of before I could fully reap the benefits.
Contents
1. Code review takes an expert
New programmers often believe they can only learn effectively from an “expert” who knows “the way” something should be done. That an expert supposedly knows all the ways a code base can fail. That an expert must determine when your code works and when it doesn‘t.
However, great, experienced programmers don’t approach problems as “experts”, and there are a number of downsides to doing so. “Experts” might cling to a proven solution to a problem and miss new methods that may work better or new issues in the code that they aren’t familiar with. An “expert” is also often more in danger of having preconceived notions of what the code should look like. The reality is that the “expert” mindset is bad for development. The best code reviewing is done by peers, as peers. It’s critical that we see ourselves as students during the code review process. Maintaining a student mindset helps us to become better programmers who ship quality, innovative code.
“The reality is that the “expert” mindset is bad for development. The best code reviewing is done by peers, as peers.”
2. Code review is about finding mistakes
Code review isn’t at all about finding mistakes. Linters are built for that, along with exception errors, debuggers, proper indentation, test suites, and user stories. Sure, we find mistakes all the time in code reviews, but code reviewing is just as much about promoting successful, efficient, and well-organized code as it is about finding bugs.
Not everyone on your team has the time to take every new class that comes out, go to every local meetup, and read every new blog post on the various best practices (like code review). In fact, no one does. Development teams are filled with knowledge debt, and no degree, education budget, or learning blog is going to fix that.
Code review is the single most effective way to fill in those knowledge gaps, because your team’s code base becomes a place where all that learning can be shared. Team members get ideas to improve their code based on skills another member has acquired. Reviewers see new solutions while reviewing code by programmers who have learned different techniques, and see those ideas implemented in a project larger than a code example.
With a single practice, a project team becomes a continuous classroom filled with vetted experiments from different areas of specialization. This combined learning experience ensures that no one member stays in the dark about any related technology or technique for very long.
“Code reviewing is just as much about promoting successful, efficient, and well-organized code as it is about finding bugs.”
3. Code review isn’t coding
Code review takes time, especially in the beginning. Some see code review as a chore that gets in the way of actual programming, but as someone that came to programming after life as a writer, I’m acutely aware that the key to building skill in writing is to read at least three times as much as you write. The same is true in building proficiency in a computer language. Reading source code and learning how to quickly assess its strengths and weaknesses will change the way you write code.
There’s often a steep learning curve involved with mastering the many frameworks, libraries, and best practices of programming languages. Trying to create a project from scratch to learn every technique you need to know in programming is impractical. Learning to jump into a existing project and contribute to its development is an effective way to kickstart the process of understanding how a system works in a fraction of the time it would take to build your own project from scratch.
Reading source code and learning how to quickly assess its strengths and weaknesses will change the way you write code.
Without all the gains from code review and collaboration, most modern software wouldn’t exist. The great open source revolution proves that fact. To a newer programmer, the tech sector looks like an intimidating, impenetrable city of experts. But the secret to creating technological advances, and the advances you’ll make tomorrow, is that software development works best when done by a city of students, all learning from each other through shared projects.
We don’t need experts here. They’d only slow us down.