Top 7 Lessons Learned About Code Reviews in Data Science
By: Rose Day
Tags: Data Science, Data, Code Review, Lessons Learned, Code

Code Ownership

Let’s first discuss code ownership and how you can approach your code changes to someone else’s code.

Code belongs to the team and not one individual.

Code ownership can be a hard conversation to have. I believe in the idea of collective ownership in which the code belongs to the team, and they share ownership over that code. The Agile Alliance defines collective code ownership as

…the explicit convention that “every” team member is not only allowed, but in fact has a positive duty, to make changes to “any” code file as necessary: either to complete a development task, to repair a defect, or even to improve the code’s overall structure.

Under this code development model, you reduce the risk of a developer being absent, which can stall or slow work. Collective ownership encourages each developer to feel responsible for the quality of the code base as a whole and be able to participate in updating or adding to different parts of the codebase.

On my team, code can change hands often as people work on different code base aspects during various projects. Code ownership can often come up in a code review when one developer has altered the code that another developer previously wrote. I am not saying you cannot have a primary developer who works on that code more often than others, but others should feel that they can contribute to the work and have open discussions on how to improve it.

2. Code reviews are not about you; they are about the code.

In the code reviews I host, I invite a core group of reviewers alongside any developer whose PR we will be discussing. The critical thing to remember in these discussions is the comments are about your code, not you. Developers are trying to make sure the code is functionally doing as intended and that no issues enter the codebase. It is helpful to be open-minded when approaching these discussions as it can introduce some great learning opportunities.

As you are writing comments on a pull request, think to yourself:

Is this comment providing constructive criticism on a technique and why another may be better? Or is it pointing out a logical error? Does the comment teach the other developer something? Is this is a nit-picky comment based on style or preference, but not functionality?

If you answered yes to questions 1 or 2, then provide insight into how the developer can improve their code. If you answered yes to question 3, consider why you are making the suggestion and determine if the comment should be made or not. Personal preferences of coding style or techniques that do not improve the code’s functionality are ones I tend to leave out. The exception to this are changes that would improve readability.

3. Having review meetings with more than one other developer can ease tensions on code ownership.

Having multiple people in a code review group can also ease tensions between the original developer who created the code and the new developer who alerts the code. Our team has specifically called out working agreements for code reviews that detail how such reviews will be held and resolves any disputes. Since the introduction of the code review meetings and working agreements, there have been no significant disputes on code changes. These working agreements outline a coding standard the team follows, instructions for creating a pull request and holding a code review, and a detailed conflict management guide that explains what happens in the event of a dispute.

4. Understand the difference between a necessary change and a suggestion.

At these meetings, developers are open to discussing any changes in the code. Some changes are standards we have outlined in our working agreements, such as what libraries we use or naming conventions to follow. If it is not explicitly called out as a standard or explained, ask if it is a necessary change or a suggestion.

For these discussions, it is beneficial to distinguish between what requirements to meet for the code to pass a code review and what comments are suggestions for future thought or implementation. It is good to clarify your action items before leaving the meeting to understand your next steps. I find it best to mark some comments as Won’t Fix if they are suggestions or considerations for later.

What are your thoughts on code ownership? Does your team have a set of standards they follow for code changes?