Pull requests (PRs) can be a touchy subject for developers. Even though they’re an essential part of the software development lifecycle, they can also lead to heated discussions, bruised egos, and at times, a tense work environment.
As a CTO (previously a tech team lead), I’ve navigated these turbulent waters numerous times. Today, I’ll share some wisdom on handling pull requests in a way that not only maintains code quality but also preserves team harmony.
Understand the Human Behind the Code
First and foremost, remember that every line of code has been written by a colleague who has poured their effort and creativity into it. This understanding sets the stage for a respectful code review. Instead of seeing PRs as opportunities to critique, view them as a dialogue about the code.
BM Insight: Saying that a human is always behind the code is not actually the whole truth anymore. The swift growth of AI-enhanced tools has also brought changes to the world of software development. For instance, GitHub is a powerful coding assistant that saves some time along the way. While people are still (and will stay for some time) at the helm of softdev projects, such tools come in handy in daily tasks. Read more about this specific AI-assistant in the blog post Streamline Your Coding with GitHub Copilot, written by Marko Krstanović.
Frame Feedback as Suggestions, Not Orders
Nobody likes to be ordered around, especially not software engineers. Rather than dictating changes, frame your feedback as suggestions. “This function could be broken down into smaller parts for better readability. What do you think?”, is much better received than “Break down this function.”
BM Insight: Employee-respective and effective internal communication definitely lays foundations for successfully executed in-house projects. It’s also a chance to simulate and improve your communication skills in a context in which mistakes are not that expensive. Client communication is a bit different playground, where poorly communicated feedback might put the entire collaboration at risk. Learn more about it in our blog post Mastering Client Communication: The Art of Productive Dialogue, by Dragana Ječmenica.
Make It About the Code, Not the Person
It’s crucial to separate the person from the code. When giving feedback, focus on the code rather than the individual. For instance, instead of saying, “You’ve written spaghetti code here,” you can say, “This piece of code could be a little confusing. How about we simplify it?” Make it ad codem, not ad hominem.
Be Constructive, Not Destructive
Positive and constructive feedback encourages growth, while negative feedback can be discouraging. Instead of highlighting what’s wrong, focus on how it can be corrected. For instance, saying “I see your point here, but it might be more efficient if we use a different approach” is more effective than simply saying, “This is wrong.”
Emphasize the ‘Why’
Help your peers understand the reasoning behind your feedback. Instead of just stating what needs to be changed, explain why it should be changed. This helps others learn and appreciate your input more.
Communicate in Real-Time
Sometimes, the written word can be misconstrued. If a PR chat discussion starts to heat up, it might be more efficient and less contentious to take the conversation offline or to a real-time communication channel. This is one perfect situation where a meeting could save the day.
Be Open to Learning
As a reviewer, don’t be so quick to assume that your way is the only or best path to finding a solution. Be open to learning from the PRs you review. You might encounter a new method or a different perspective, applicable to future endeavors.
Appreciate the Good Work
Lastly, remember to appreciate good work when you see it. A kind word can go a long way in fostering a positive atmosphere.
BM Insight: Pull requests are only one type of feedback developers get within a company, specific due to their technical nature. However, a software development company doesn’t consist only of tech staff. There are many different teams and professions that keep the softdev engine motor going. Each of these teams and individuals deserves valuable feedback and personal growth. Read our comprehensive guide to various business positions every tech company needs in order to thrive named The Entourage of IT Projects – The Binding Tissue of IT Software Development, by Pavle Bobić.
Brutally Honest Code Reviews by Industry Greats
One of the most famous programmers in the world, best known for the creation of Linux OS, Linus Torvalds, infamous for his toxic comments in PRs. There is even a Quora thread dedicated to his rants, [source], and you could probably find similar stuff on Reddit, as well. Since then, he seems to have changed as a person [source].
I must admit it was fun to read his “unchained” comments, and from time to time I wish to do the same. By the way, it is probably much easier just to eliminate empathy, especially when you are tired of repeating issues in PRs.
Anyway, this behavior could do some irreparable damage to relationships with your colleagues and team members, so do your best to keep professional and constructive feedback in your PR reviews.
Practicing Constructive Pull Requests at BrightMarbles
Nurturing a Culture of Inclusion and Excellence | BrightMarbles
At BrightMarbles Group, we’ve developed a culture that promotes respectful and constructive PR interactions. We recognize the value of PRs as a tool for collective code ownership, continuous learning, and team collaboration. As such, we’ve ingrained certain practices to ensure that the PR process adds value and positivity to our team dynamic:
- Every developer at BrightMarbles Group, regardless of their level of experience, is encouraged to participate in the PR process. This openness has cultivated an environment where everyone feels valued and part of the creative process. We believe that fresh eyes bring fresh perspectives and solutions.
- Feedback is always given in the spirit of continuous improvement and growth, and we ensure this by emphasizing ‘why’ in our PR comments. We’re not just pointing out issues but providing an explanation and learning opportunity.
- Most importantly, we never forget to acknowledge the good work. Positive reinforcement is powerful. It boosts morale, fosters a sense of accomplishment, and encourages team members to continue producing high-quality work.
The result of these practices is a robust, respectful, and dynamic PR process that strengthens our code, our product, and our team. It’s proof that with the right approach, you can handle pull requests without making enemies – but instead, by building stronger bonds and developing as a team.
Conclusion
PRs don’t have to be a battlefield. With a dash of empathy, a spoonful of tact, and a generous serving of respect, they can become a platform for learning, improving, and bonding. As engineers, we must ensure that the code we ship is of the highest quality. As team members, we must also ensure nurturing a supportive and friendly environment. When these two goals are in harmony, the result is a high-performing and happy team.
Finally, remember that as developers, we’re not just coding machines—we’re human beings working together to create something remarkable. Let’s honor that fact in every interaction.
About Author
Darko Kovač is our Chief Technical Officer and one of the company co-founders. A once-wunderkind, now-veteran software engineer with a demonstrated experience in the computer software industry, he is a difference-making biz-dev professional, specialized in full-stack development in various technology stacks.