This is one of those topics where I had to do a deep dive myself because it's a new responsibility that's come up in my routine. Going from maintaining a code base myself to bringing on a full time front-end developer and multiple contractors was a tough but welcome challenge. That is what prompted me exploring Code Reviews as a topic for our latest episode of the HTML All The Things Podcast

If you prefer to listen rather then read then check out the episode here:
Code Reviews | HTML All The Things Podcast

Getting Your Code Reviewed

Code reviews can be stressful, and that is a normal reaction to putting yourself out there. There are ways to mitigate this.

To start, try to do your own code review before submitting. This usually catches the careless errors and makes your code look more professional and in turn gives you a better reputation.

When you get critical feedback it's sometimes difficult to separate the feedback of your code from a personal attack. It's essential to do this otherwise it will be tough to use the feedback to grow as a developer. The critiques are designed to make you a better developer. Showing that you've listened and implemented the feedback moving forward can also help you grow in a company. A developer is far more likely to be promoted if they are good at receiving and using feedback to better their code.

Use the tools that your team provides you for structuring code. Linters and Formatters are easy ways to conform your code to your companies rules. Even if you prefer spaces over tabs you can continue to use that as long as you have the proper eslinting configured for you IDE of choice.

Keep the code you are submitting for review as short as possible. Typically you don't want to submit a pull request that adds multiple features, it can overwhelm the reviewer and cause for them to either miss mistakes or delay the approval of your code.

And finally, this might seem like a obvious one but Test Your Code before you submit it for review.

Performing A Code Review

Code reviews are an essential part of any development team and with my research and experience here are some tips that can make you and your team better at performing code reviews.

Providing the proper formatting and linting tools will give your code base a more uniform look. This can help to quickly identify issues without getting bogged down in the syntax. Your team will benefit from a more organized and reusable code base while also learning how to use linting properly.

Something that seems to be less and less popular in the workplace is doing in person/screen share code reviews. I've found that sometimes going through a review on a call can help clarify and solidify some core concepts for new/junior developers. I don't think you need to do every code review in person but especially for new developers it can really accelerate their growth.

When you are performing a code review it can be really easy to forgot that you're essentially judging another persons work. This can lead to using harsh language. Saying "This is really bad" or "Very wrong" can bring a developers confidence severely down. Try to be mindful and use more constructive phrasing. "This can work, but we usually do it this way because..." or "The implementation you chose can be used in these other situations but currently it will lead to issues because of a, b, c...". These language adjustments shows respect for your coworkers instead of bringing them down.

Often in smaller teams the lead developers are the ones that are performing all the code reviews. This kind of hierarchy can lead to a lot of single minded errors. A better way to approach code reviews is for everyone to get involved as quickly as possible. A lead developer should have their code reviewed by someone else, not because they make a lot of mistakes (which can happen) but because the team will learn from a proper code review submission. Also it's important to encourage everyone on the team to give suggestions and ask questions during the process. No one on the team is infallible and having open communication will lead to better code.

I've thrown a lot of suggestions and ideas at you but it's important to put code reviews in perceptive. They are not the product that you company is working on. They should be supplementary and an aid to your developing process, not a hindrance. If you find they are taking up large portions of the day, or blocking other developers from doing their work, adjustments to the process need to be made.

With all this just keep in mind the goals of your code reviews:

• Create a more sustainable code base
• Help developers grow
• Avoid errors

Just a quick update

If you haven't seen any of my blogs before it's because they are far and few between. What I have been doing for the last year or so is co-hosting a Web Development Podcast called HTML All The Things. I've decided that since I'm doing research for episodes every week I should expand on them and write a more in depth blog post. So welcome to my experiment! If you've read this far let me know how I've done in the comments. Also check out our podcast!

HTML All The Things