When Optiver first launched over 30 years ago, the business started as a single trader on the floor of Amsterdam’s European Options Exchange. Their traders and software engineers design proprietary systems and execute strategies that provide liquidity and increase market efficiencies.
In order to stay ahead in a highly competitive industry, Optiver trusts its engineers to develop quality software. Enter code reviews — the process of peer editing code before software gets deployed. Code reviews allow engineers to find and fix errors, saving companies time and money.
Additionally, engineers who engage in code reviews gain professional development. Just as writers get better by reading other writers’ work, engineers get better by reading other engineers’ code. For Software Engineer Parker Brown, code reviews are a team effort; no one developer “owns” their code. At Optiver, Brown said they operate code reviews with approved reviewers, which ensures at least two people are familiar with every commit message before the code enters the master branch.
Brown shared how Optiver developed its best practices for fostering a positive code review culture, as well as how his team manages feedback when differences arise.
What best practices does your team follow when doing code reviews?
One of the most important protocols we have in regards to code review is approved reviewers. All merges are blocked unless approved by someone from the approved list, usually a domain expert. This ensures there is only one entry point into the master branch and at least two people are familiar with every commit, which prevents surprises and fosters a culture of shared ownership of the code.
When there’s a difference in opinions about how to write certain code, how does your team handle it?
Never be afraid to take things offline. If a reply chain is longer than two replies, the problem is probably large enough that it’s more expedient to discuss in person. This often ends in bringing in multiple people with different viewpoints and almost always generates a better and quicker solution than having a 20-reply thread of comments. Don’t forget to put the resolution in the review though. The code review is a diary of what changes were made and why, and can be an indispensable resource when looking back at a previous change several months or years later.
Never be afraid to take things offline.”
What advice do you have for fostering a positive code review culture?
Embrace the criticism. Use it as a chance to improve your code and help others improve theirs. I am infinitely more scared when my review gets zero comments compared to when it gets 100. I think a lot of people wrongly see a lot of comments on their code review as a sign that they failed. They should see it as a sign that someone really took the time to thoroughly analyze their changes and that everyone’s code will be better for it.
