🔗 Your stubborn coding style is holding the team back

Software engineers can be fanatical about code style. Just ask anyone who's witnessed a tabs-vs-spaces flame war.

However, as teams grow and projects evolve, coding style becomes a key aspect for readability and maintaining consistency in the code bases.

When everybody on a team has a strong opinion and no middle ground is achieved, the team dynamics are affected, and the project delivery suffers.

I experienced it firsthand before.

Around 2014, I worked with a small software engineering team on an iOS app written in Objective-C. I strongly preferred a particular formatting style; everybody was on board.

But later that year, a new proficient iOS developer joined the team, bringing a different code formatting preference to the table.

For the next couple of months, whenever he touched a module I wrote, he reformatted it; whenever I opened a file he edited, I reformatted it.

There was no formal debate—just a low-grade formatting war that wasted hours of developer time and buried useful commits under noise.