How we do code review at Orbit (and how it’s making me a better developer)

As a junior software engineer, I'll admit that I was intimidated at first by the idea of reviewing my teammates' pull requests. 

For one thing, I definitely didn’t think that I could add any real value to a code review process because I didn’t yet have the experience or the necessary context to effectively identify edge cases and potential bugs that the new code might introduce.

It wasn’t until a few months ago that I started to get more and more comfortable with the idea of reviewing my teammates’ pull requests. Maybe not entirely coincidentally, this was also around the same time that we started tightening up our processes and systems as an engineering team at Orbit.

As a growing team, we are consistently striving to do our best to streamline processes in order to be as effective and efficient as we can in our day-to-day work. As part of this, we have a set of guidelines and overall values we try to adhere to when submitting pull requests and conducting code reviews.

In this blog post, I'll walk through a few of our guiding principles when it comes to code review, and our overall  work on the Engineering team at Orbit.

These are some of the key points that have helped me dive into the deep end with code review and ultimately become a better developer.
‍

Owning your code

While PR reviewers help me meet our code quality standards and prevent any issues, as the author of a PR opened for review, I’m the one ultimately responsible for my code.

On the Engineering team at Orbit, we have this great symbiosis between having autonomy on the projects we work on but also being able to lean on our teammates for help and support wherever necessary. 

The core idea that I am the main owner of whatever PR I’m working on is empowering, but it can also be a bit intimidating and overwhelming—especially at first. 

This idea, paired immediately with the reassurance that your teammates are there to help you improve your code, really illustrates our Engineering culture, and it has definitely helped me gain confidence in the code that I ship. 

The fact that I am ultimately responsible for the code I write and introduce into production means that it’s in my (and the team’s) best interest to try to write the best code that I can and to ask for help when necessary.
‍

Moving fast and fixing things

Orbit has a culture of shipping, not a culture of writing code. Everything that happens before and after writing code and pushing it to production is equally as important.

One of our major values at Orbit is moving fast and fixing things. We like to ship new features to our users consistently, and we move fast.

That being said, moving fast doesn’t cloud our view of the long game. We don’t push features only to later abandon them for the excitement of the next shiny new project. Whenever we ship something, we know we have a responsibility to maintain ownership of that feature and to ensure that the newly-implemented code works seamlessly with the pre-existing code.

Connecting this back to our PR and code review process at Orbit, we try to make sure that the code we’re about to ship won’t introduce any new bugs; but if it does, we know that we’ll be prepared to fix anything that upsets something else in production.

Aside from the actual code, we also have the responsibility to make sure that we add or update any necessary documentation, contact our users (or at least be a part of the conversation), and overall take on a more holistic approach to the code we introduce and the effect it will have on users, teammates, and the system in general.

Getting more comfortable with this holistic approach of shipping (and fixing, if necessary) helped to assuage some of the pressure I was initially putting on myself out of the fear of breaking something. 

But that’s also the nature of the game, and in my opinion it’s great to have a culture where it’s understood that sometimes things break, and that if they do, you’re ultimately trusted with the responsibility of fixing it in a timely manner.
‍

Getting review ready

I’m responsible for performing a self-review of my own code and trusting that it satisfies our team’s quality guidelines, before marking the PR as ready for review.

Diving into reviewing other teammates’ pull requests has helped me develop myself as a software engineer because it’s given me a first-hand perspective of the benefit of making sure that my code has been written to the best of my ability before asking a teammate to review it. 

Going through code review has given me a chance to get more and more comfortable with different parts of the codebase, and even when I may not have much (or any!) extensive background knowledge of certain aspects of the code, my team has always been clear that even a review to make sure that everything is working properly and as expected can provide value in its own way.

That being said, before I mark a PR as ready to be reviewed, I make sure to go through the review process as though I were seeing my code from someone else’s perspective, and I do my best to tie up any loose ends and to optimize any last items before requesting another review.

In fact, something I’ve found interesting while getting more experienced with reviewing my teammates’ pull requests is that code review is so much more meaningful when I really set aside a good amount of focused time for it. 

Making sure I understand why things are written the way they are and why things fit together the way they do has helped expand my overall understanding of the codebase (and of various principles of software engineering as well).
‍

You gotta start somewhere

The best engineers are often also great reviewers, but code review is a skill in itself. A junior engineer can also be a great reviewer. My feedback and comments on pull requests are welcomed and appreciated.

I think this was one of the key points that helped me jump fully into the code review game. Never reviewing code because I didn’t have enough experience was quickly becoming a self-fulfilling prophecy where I realized that I ultimately needed to start somewhere if I wanted to get anywhere.

The reassurance from my team and its guiding principles that any interaction with new code would be beneficial helped me break free from the idea that my contribution wouldn’t add any value. 

Today, there are certainly PRs that intimidate me and that I feel reluctant to check out because of my perceived lack of experience, but then I remind myself that simply taking that first step and checking out the branch locally is all I need to do to start the process of familiarizing myself with the code at hand.

‍

Wrapping up

Diving into code review has been an eye-opening experience for me as a junior software engineer. It’s challenging at times, but it’s also an extremely valuable experience that has allowed me to improve my own skills as a developer.

If you want to learn more about effective code review tips, here are some of the resources that helped me get clearer on best practices with submitting pull requests and conducting code reviews: 

• On Code Review by Glen Sanford
• Writing pull requests your coworkers might enjoy reading by Ryan Greenberg
• Reviewing Pull Requests by Chelsea Troy