Before working at Google and Amazon, Fahad Zafar points to code review from senior software engineers as the key tool that helped him grow as a developer. Now, as one of the thousands of reviewers at PullRequest, Fahad seeks to pay it forward by helping development teams improve code quality through code review.

While PullRequest reviewers come from diverse backgrounds, some common themes across reviewers include a passion for improving code quality, and a strong desire to help developers build better software. We interviewed our top reviewers and asked them the following seven questions:

1. What’s your background?

Over nine years, I focused my education entirely on computer science, earning a BS, MS, and PhD in CS. On top of my education, I learned about efficient software design and programming best practices by working on the YouTube Video Editor, YouTube Data Warehouse, and the Amazon Fire Phone.

Throughout my career, I’ve worked on all types of software engineering projects, from backend database design, writing REST APIs and their deployment in a production environment, to user applications for desktop and mobile. I’ve also contributed to open source libraries used in 3D modeling applications.

2. Why is code quality important?

It’s very satisfying to help developers avoid mistakes I made in the past. Helping someone save time and energy through clean code is one of the best things you can do to help a team. It’s always my goal in code review to increase their programming efficiency.

Having more experienced engineers review my code has helped save me a lot of time and frustration. They’ve pointed out why certain abstractions were particularly good or particularly bad, and how a pitfall in my code could add unnecessary complexity. Through code review, I learned to simplify things and think clearly about my code.

3. Why is a good code review process important?

Large code bases cannot sustain quality unless they’re designed, implemented, tested, and reviewed properly. It’s always interesting when engineers try to use a script or system executable to work around a problem. They might hack together a quick solution that works for now, but doesn’t solve the problem and may even fail as the service scales. That’s a tricky balance to get right and it’s different for every team, but code that’s easier to maintain will pay off in the long run.

4. Why do you review with PullRequest?

I grow as a software engineer when I see high-quality code written by other professionals. Reviewing uncommon or less frequently used design pattern implementations is pretty cool. Also, I like that reviewing can be done from anywhere in the US and not just the Bay Area.

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

The best part about being a third party reviewer is that I can provide a purely objective review of the code’s design and implementation. Since I’ve never met the developer, I can focus my feedback on constructive opportunities such as avoiding certain pitfalls, identifying design flaws, and pointing out oversights while avoiding common biases that happen on teams.

6. What are some common issues you see?

The main things I help with are improving the scalability, maintainability, and stability of teams' source code. By doing code review for so many teams, it’s easier for me to identify code smells and bugs, as well as spot ways to reduce code duplication by creating better utility classes and functions.

7. What advice do you have for developers?

Make smaller pull requests, and do it more often. Submitting big features in a single CL that spans thousands of lines of code across multiple files takes time to unpack. If an issue is identified, it’s easier and faster to address if changes are smaller and more isolated.