A passion for contributing to open source projects is one of the most common traits we see in PullRequest code reviewers. Eli Perelman has dedicated his programming career to helping other developers through open source. Now, as a PullRequest code reviewer, Eli applies his commitment to improving the experience of other developers to reviewing code for other teams.

This Code Reviewer Spotlight is part of an ongoing series of interviews where we ask our top reviewers the following seven questions so you can get to know them. Below, discover how Eli sees being a reviewer as another a way to improve the experiences of other developers.

1. What’s your background?

Early on I became enthralled with the idea that I could control the actions of a computer by speaking a language it understood. I started off programming in JavaScript and haven’t stopped for over 14 years. These days I call myself a JavaScript and Node.js Obsessionalist.™

I prefer to do my work in the open for the benefit of myself and others. I’ve been contributing to open source for years and also get to open source my work as a senior engineer at Mozilla, including contributing to projects on Firefox OS and participating in the W3C Web Performance Working Group.

Currently, I’m working on Neutrino, which lets you build modern JavaScript applications with zero initial configuration. It has over 2 million downloads on NPM, check it out at neutrinojs.org.

2. Why is code quality important?

Code quality is an investment in the future — your future and the future of anyone looking at your code. As I see it, code quality is correlated with the ability for a developer who returns to their code in the future to be able to understand it and maintain it. If the person writing the code can’t understand and maintain their own code in the future, it’s unlikely that anyone else on their team will be able to.

Without taking the time to ensure an application meets an acceptable standard of excellence, you make an implicit tradeoff that leads to a higher cost of maintenance or technical debt down the line.

3. Why is a good code review process important?

I often break down all problems into an analysis of tradeoffs. On one side, having a good code review process has a number of rewards such as ensuring maintainability, error reduction, consistency, and knowledge improvement. On the converse, having a good code review process means having to spend time and mental energy above just writing the minimal code necessary to ship. In my opinion, this tradeoff is always worth it, and it is up to each project to do this same evaluation and determine if it works for them as well.

4. Why do you review with PullRequest?

I review for PullRequest for the ability to mentor and improve the experiences of other developers. I have always received satisfaction from helping others learn and grow, and reviewing for PullRequest gave me the opportunity to do that for developers that didn’t exist in my immediate work circle or open source projects.

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

A level of bias and preference is inherent when I review applications for which I am the owner. Doing code review for third parties gave me the chance to be more objective in my reviews, focusing on true code quality improvement and growth rather than enforcing my own subjective desires for how an application should be written.

6. What are some common issues you see?

Besides the obvious, the most common issues that I see are nuances and gotchas around error handling, and writing things efficiently.

7. What advice do you have for developers?

I encourage all developers to be active participants in the code review process. Take constructive criticism professionally and not personally, as code reviews are meant to be a learning experience for both the reviewer and reviewee. If you disagree with a comment or suggestion, don’t be afraid to question, push back, or engage in friendly debate to resolve the disagreement.