Code Reviews: A Vast Subject

Code review is a significant part of the software development lifecycle and is a crucial piece to get proficient at quickly to advance as a software engineer.

Let's explore a few aspects of code review to keep in mind:

Fixating on Style in Code Reviews

Code style in reviews is a subject fraught with disagreements. Like the rest of software engineering, though, the answer to how much it matters is "it depends." Style requires that each team member quickly understand the code, make changes to it, and build on top of it. There are fewer people to satisfy in a small team, so code style isn't all that important. In contrast, large organizations need a consistent style to enable quick changes and have engineers flex into other codebase areas. 

An orthogonal aspect, though, is linters. Linting can automate code style, but setting up those rules and automation takes its own set of skills, which a small team often doesn't have. If you're in a small team, don't let style create massive debates that distract you from the actual problems. If you're in a big organization and code style is an issue, find someone who can automate it, allowing the team to focus on what's important. Code style is not the goal; it's a means to an end.

Creating a Positive Code Review Culture

How do you instill a positive code review culture in your team? Lead by example. It's most straightforward in a startup, where the leader is usually technical and codes alongside their reports. By setting the tone and jumping onto reviews quickly, using questions instead of declarative statements, and focusing on the things that matter without getting hung up on small style details, the team will notice. Furthermore, if this person is also the manager and they have 1:1s, they can further reinforce these patterns and encourage their use. 

For this to work, though, engineers need to understand the core purpose of code review. Since it can often seem like a way for them to exert power and show off knowledge, it needs to be clear that only through positive, constructive reviewing will they advance within their role. Everyone wants to grow; whether it's purely increasing their salary or a more altruistic growth of knowledge, engineers always want more. The key is to clarify to non-constructive reviewers that the best way for them to grow is by adopting this effective style of review. It will take extreme patience for some, but by framing every conversation asking for improvement in their code reviews, they will have no choice. 

Speed, Speed, Speed

A significant factor in a positive code review culture is the speed with which reviews are picked up. Do code reviews quickly! Reading code is a skill, and as you improve, you get faster. In addition to getting faster at reading code, starting a review quickly also has crucial benefits. In the middle of something? So are your coworkers! Getting good at rapid context switching is a significant skill in and of itself. If you are good at reading code, a review should not take you entirely out of your previous context. 

Please jump on reviews quickly, use your code reading skills to review it efficiently, and then jump right back into what you were doing. Doing so lets you practice context switching and helps speed up your colleague's work. It also creates an expectation for your colleague to do the same for you! 

Waiting for a review is one of the most frustrating aspects of being a software engineer, while an instant review is one of the most satisfying. Give your peers quick feedback; they will appreciate you for it. 

Reading Code

Continuing on the topic of reading code, the more senior you get as a software engineer, the more code you'll be reading. The most senior engineers are not just writing code all day! They are reading much, much more code than they are writing. That's not to say they aren't excellent programmers, but that's how the role evolves, especially in big companies. 

Reading code is a skill. Writing code is a skill. They are not the same, and reading is arguably more challenging! A great time to practice reading code is through reviews, as it's your chance to verify things are written according to your team's style guidelines and function as expected. This context helps you read, as skimming through some random code samples you have no vested interest in won't be nearly as effective at fully understanding what you are reading.

The faster you can read code, the better, too! Speedy reviews are always appreciated, but balance speed with thoroughness. Striking that balance well is an invaluable skill for a software engineer, and the more you do it, the better you'll get at it! Don't shy away from code reviews; embrace the fear of missing issues. When you discover you missed something, learn from the miss. Make it a point not to miss that same issue again. Keep doing this, and you will develop a strong sense of what to look for in reviews, problems you naturally are good at finding, and issues you need extra focus to find. Always be asking yourself when creating review comments, though: "does this matter?".

Onboarding New Teammates

Don't frighten new engineers on your team with code reviews. If you have a high bar to meet, help them get there! It's one thing for a code submission to have fundamental flaws in how the problem was solved, which indicates you haven't done your job explaining this problem to your new teammate, but it's another if the submission has a bunch of style issues. Reality is, though, 20 open issues are 20 open issues — even if they are all minor styling, the new engineer on your team likely won't fully appreciate that. Make it clear what you are commenting about; if it's so fundamental that the problem isn't even addressed, set up a meeting, and talk it through. If it's just style, tell them!

"Overall, this solution looks great! Just have some minor style things, you'll get the hang of these in no time :)"

Compassion in your reviews will make your new teammate productive so much faster, which will, in turn, make you and your team more productive.

Conclusion

There are so many aspects of code review; the above points only cover a fraction of the process. The top three things to take away, though, are:

• Does it matter? Review comments should materially improve the product or developer experience.
• Keep the process positive and compassionate.
• Speed matters.