Why should you define best practices with other developers?
Tags: codereview, codequality, programming, productivity
Published: 2022-03-18 12:01:22

Working efficiently as a team on a software project requires **strong communication and definition of coding standards and best practices**. A best practice is a rule that should be applied in your project, and it might target any topic: a programming language, a framework, security, performance, architecture, etc. A best practice for you is probably not universal and may not be relevant to all software projects. Still, this is the best practice to apply in this particular project for many reasons (historical, context, etc.). 

Maybe you already did some brainstorming sessions with your team to leverage your best practices or started some technical documentation to record them. In any case, here are **five key points** on why you should definitively consider this. 

## 1. Ease code understanding

A source code will be more straightforward to maintain written with uniformity. We know developers waste around [40% of their time](https://stripe.com/fr/reports/developer-coefficient-2018) to understand and rework source code before starting to add value to the software. If they're not familiar with a part of the software, you can be sure they'll be more efficient if they quickly figure out what this code is doing, how it's been designed, and how to browse and navigate through the different files. 

Put in other words, optimizing code understanding can drastically reduce **maintenance costs** and help new developers in a project to get familiar with the codebase. 

## 2. Improve team throughput and velocity

Is your team familiar with [code review](https://www.packmind.com/save-time-during-your-code-reviews-on-github/)? If so, you've probably faced frustrations due to latency on pull/merge requests: you work for one day on a task, submit a review, and wait another day for someone to read it. And you'll likely have to rework it based on reviewer comments and suggestions. 

During code reviews, discussions between the author and the reviewer may go beyond the scope of the review since one may have some preferences, and the other is keen on an opposite approach. However, these choices impact the whole team and **should be discussed with other developers**. So what can you do in that context? Plan a meeting in an emergency to decide which practice to follow?

Possibly yes, but you'll realize this may not be the right time, which will add even more latency in the code review process. On the opposite, teams that have already invested time in defining and sharing best practices will be more efficient on code reviews and deliver value sooner to their customers.

## 3. Mitigate bug risks

Any team of software developers has this purpose in common: **avoid bugs in their software**. We want to make our customers and users satisfied as much as possible. Bugs can arise from many reasons, including bad requirements understanding, defect implementation, or deficient testing. They can thus come from an incorrect best practices application. 

Every developer has expertise in some domains and lacks skills in other domains, and you can't master all the technology space in software development. Still, if you work in fields where you feel less comfortable, there is a risk you **introduce defects simply because you're not aware of all the best practices in this field**. We need to control this risk, and we can use code review for that. Working collectively on best practices will optimize your team's knowledge transfer and lower the risk of introducing bugs in your software. 

## 4. Learn from other developers

There are multiple methodologies to define and discuss best coding practices in our team. Mob programming sessions are a concrete example. Whatever the framework you choose, keep in mind this craves communication among developers. Each will expose their point of view, listen to others’ arguments and proposals, and at some point will come a time for a decision. All these discussions are interesting because they share expertise and experience from previous projects, and that's an excellent opportunity to learn from each other. 

**These social interactions strengthen your team cohesion** because you feel yourself in a safe space where you can constantly learn new things and feel comfortable debating with each other. Developers always want to improve their skills and generally fancy spending time on that topic. 

## 5. Reduce turnover impact and onboarding costs

IT industry faces one of the **highest turnover rates,** so developers regularly leave teams and must persist and transfer their technical knowledge. This is often achieved in a hurry when it's not something part of the teams’ process. When someone quits, you have a clear deadline, and you might be stressed out as you believe you'll lack time to gather all the necessary knowledge. 

If your team regularly invests time in exchanging technical knowledge, and if you've successfully set up a [learning culture](https://dev.to/promyze/create-a-learning-culture-to-improve-code-quality-ici), you'll have better control over turnover risks. Moreover, welcoming new developers can take up to several weeks or months to be completed. When someone joins a team, they're eager to find technical documentation on your team's coding standards and best practices. We want to do a great job, so we need to know which methods to apply. If you have such a repository, you'll realize it'll reduce the onboarding costs. 

## Want to start defining best practices?

The [Packmind](https://packmind.com) platform has been precisely designed to reach that purpose. It helps developers for creating knowledge and make everyone in your team (and your organization) benefit from that and is fully integrated into their tools ecosystem.