A good code review process can be the fastest feedback loop for developers to receive actionable feedback from senior software engineers. PullRequest reviewer Dylan Drop also sees code review through the lens of mentorship, and emphasizes that developers and reviewers share a common goal of delivering high-quality code.

Our Code Reviewer Spotlight is an ongoing series of interviews so you can get to know our top reviewers. Learn more about Dylan’s drive for continuous learning through code review below:

1. What’s your background?

I’ve been doing web programming since 2011. I used to work a lot with Rails and Ruby, especially in my last role as a tech lead at Blue Apron. I helped scale the company from 12 engineers to 100+.

I’m currently a technical lead at Grubhub and I’m working more with Java now, but will always hold a spot in my heart for Ruby. In fact, I used to contribute to crystal-lang, which is a Ruby-like language that is compiled, statically type-checked, and has speeds similar to C.

2. Why is code quality important?

When you’re writing code, you usually just want to get the job done, but what’s even more important is making sure it behaves in a way that’s easy to understand, extensible, and side-effect free. If your code is high-quality, you’ll be sure that all those boxes are checked. You make your life easier for your future self (and your colleagues).

3. Why is a good code review process important?

Put simply, code review makes your code better. It’s a kind of mentoring process that makes your change being reviewed higher quality, and also helps you develop and grow as an engineer.

Reviews can sometimes feel frustrating if the reviewer finds mistakes or improvements you hadn’t considered. However, if the code review makes your change higher quality, you’ll thank yourself for it later. Both you and your reviewer are on the same side, working together to deliver high-quality software to the user.

4. Why do you review with PullRequest?

PullRequest allows me to get back into the Ruby world and keep myself up to speed. My work at Grubhub is in Java, so code review ensures my Ruby skills stay current. Also, I get to see code from all types of business applications outside my particular industry; it’s always interesting to see the inner workings of other tech companies.

5. What advantages have you found of being a third-party reviewer?

Oftentimes teams can get bogged down in their set ways. It’s good to have another party (like myself) come in and introduce them to possible improvements they wouldn’t have otherwise considered. Each person brings their own background and expertise to the table, and teams are then able to make better, more informed engineering decisions about their end product.

6. What are some common issues you see?

The number one thing I see is lack of understanding around database properties and how the application code will behave in those scenarios. Developers need to understand transactions, isolation, atomicity, and all the other properties the database gives you, and what will happen when things go wrong.

7. What advice do you have for developers?

Improve your understanding of the inner workings of whatever frameworks or technologies you’re working with. If you’re using an ORM, understand what the magic behind the curtain is doing. If you’re working with a message queue, understand if you’re guaranteed at-least-once delivery, and what happens when a message fails to be processed. Doing so will save you from a lot of headache down the road, and you’ll be all the better for it. I guarantee it will benefit your career.