The interpersonal dynamics of group projects often present a challenge, whether the teammates are classmates or coworkers. Every collective decision that must be made represents an opportunity for discord, and the ability to amicably resolve differences of opinion becomes very important for the group’s harmony and productivity. Therefore, when it’s clear that the decision at hand is a subjective one, compromise is king. The best way to ensure the group’s success may be to go along with someone else’s idea even if it differs from my own, and I’ve made a conscious effort to do so several times while working on my capstone project.

However, it’s much harder to know how best to resolve a conflict when it revolves around a question that can be answered objectively. For instance, there are published, widely accepted standards for code quality that are applicable to any project. Here’s an example from Northrop Grumman software engineer Roberto Hernandez published on Medium, and here is another from aeronautics engineering firm Aversan. While there are differences between these two articles, common themes are clear. For instance, they both warn against hardcoding and stress the importance of clear comments and documentation. So what is a team member to do when another team member violates generally accepted best practices?

This is a question I’ve had to ask myself a couple times while working with my teammates on our capstone project. Most recently, I noticed that one of my teammates had hardcoded certain values in an HTML page rather than querying our database to get those values and passing them to the frontend to be rendered dynamically. The drawbacks to my teammate’s approach were clear to me – whenever the information in the database changes, it won’t be accurately reflected on the frontend unless changes are made there as well.

I thought carefully about how to address this situation without damaging the relationship between me and my teammate. Here are the steps I took and the lessons I learned along the way.

First, I assumed from the start that my teammate had the best of intentions. I had no reason to believe that they were uncommitted to the success of the team or the project.

However, I avoided making any assumptions about why they had chosen to hardcode values. Maybe they didn’t realize the pitfalls of hardcoding, or maybe they did but had weighed the drawbacks against the benefits that I wasn’t aware of and had made a rational decision. Or, maybe they had just hardcoded values for now and were already planning on refactoring the code later. The first step in resolving the issue was to find the answer to this question and use it to inform my next steps.

I asked this question of my teammate over Slack, and their response was that they thought that the values in the database were unlikely to change, so hardcoding was not problematic. I responded that our web application is designed to allow end users to conduct CRUD operations on our database, so even if no one in our project team is planning on making changes to the database, a user might. I then asked my teammate if they would like me to refactor their code to query the database, and they responded that I could since they were “still at work.”

Ultimately I did make the changes and my teammate and I still have a good relationship, but the curtness of my teammate’s responses indicates that I could have handled the situation slightly differently to avoid some temporary friction.

First, I should have requested a quick call with my teammate and specified that the issue was not urgent and could wait until whenever they were available. Discussing this issue over a voice call rather than through Slack would have made it easier for me to communicate that I appreciated all of the work my teammate had done thus far and valued their contributions.

Second, I should have asked my teammate if they wanted to make changes to their own code before I offered to refactor it for them. I may have unintentionally sent the message that I doubted my teammate’s ability to make the necessary changes or that I was in a big rush to see the changes made and wanted to put pressure on my teammate, none of which was true.

I will carry both of these lessons with me into the workplace, as group projects are even more common in a professional environment than they are in an academic one. In my experience, no one ever does anything in isolation at work. Understanding when to compromise and when to offer a counterargument, and how to do so respectfully, are key skills that can ultimately make or break a promotion or major initiative.