With experience scaling development teams at companies like Clearbit, Envoy, ROLI, Dribbble, and Google, PullRequest reviewer Tristan Dunn’s resume spans many different creative industries. Looking across them all and his work with PullRequest, he sees how new hires or new developers provide a fresh perspective through code review, and how sometimes that’s exactly what’s needed to find code smells that teams may have become nose blind to.
1. Would you tell us a little about who you are and your background?
My name is Tristan Dunn, and I’m a full-stack developer from Louisiana. Despite being from the South, I’m an ice hockey fan, with the Boston Bruins being my team. I’m a remote engineer at Clearbit, mostly writing Ruby.
My first work on the web was a personal website about skateboarding on GeoCities. It started with some help from a friend and evolved into viewing the source of other websites I liked before trying to recreate the desired components myself.
Next, I learned Visual Basic to create a game, which landed me my first job as a student worker writing ASP. There was a brief period of PHP jobs followed by Ruby on Rails, with Ruby being my primary language today.
2. Why do you believe code quality is important?
Code quality doesn’t always stand out when first writing code, but when you’re returning to it a few weeks later, then it becomes obvious. After you run into that a couple of times, you start to pay more attention to it. A higher code quality can save a lot of time when reading or reviewing code as well.
3. Why do you think a good code review process important?
It’s important because no one is perfect, no matter how long you’ve been coding. And deploying code that a single person has seen is often asking for trouble. (I’m not sure how anything ever worked when I used to FTP updated PHP files to a production server.) And while helping find mistakes or edge cases is great, the best part of code review is the knowledge sharing that happens between the reviewer and developer.
4. Why do you review with PullRequest? What makes it rewarding?
Being able to explore code I would otherwise never see is the fun part, but knowing I’m asking questions and finding issues that might otherwise have been missed is incredibly rewarding. It’s nice to be able to provide a different perspective to another developer and talk with them about it.
5. What have you found are the main advantages of being a third-party reviewer for another team’s code?
Until I’m weeks into reviewing changes to a single code base, I’m essentially a new hire who’s coming in with fresh eyes, and that helps me question the decisions being made and see the code in a different way, free of preconceived thoughts or biases. Having someone less attached to the code reviewing the code is always a great way to find ways to improve it.
6. What are some common issues you see when doing code review?
As a strong believer in test-driven development, not updating or adding tests is a common comment from me. Tests are a great way to help explain what the code is supposed to do, especially from someone less familiar with it.
7. What advice do you have for developers?
Stop and think about the work you’re planning to do before starting. Even if you’ve talked about it before or have a task written up, thinking through the problem beforehand can help a lot. I find it helps surface edge cases more than following along with what the task already says.
Having a consistent code style, using a tool such as Rubocop or ESLint, can also help. Anything that reduces the load of the person reading or reviewing your code can help, and what better way to do that than have a consistent style.
