When Developers Disagree

A couple of years into my second job after university, I was promoted from humble developer to project manager. As befitted my new status, I was allowed to hire a more junior developer to work with me on my project. If nothing else, the new role afforded me a great opportunity to discover how little I knew at the time about managing software projects and other engineers.

My team member was a Java developer fresh from academia whose passions were comically long variables names and overengineering so extreme that it almost seemed like a practical joke. I quickly became frustrated with his development style. Everything took forever because his software architectures needed to be fully prepared to accommodate any conceivable future requirement. His overuse of C++ templates and the way the compiler handled template expansion meant that the resulting DLLs were hugely bloated and painfully slow.

My endless speeches on the trade-offs inherent in any particular level of architectural abstraction did little to resolve the issue. Try as I might, I couldn't find common ground with my subordinate. Every effort to do so just made him more antagonistic, as I got into increasingly hot water with my own bosses over the project's schedule overruns and outsized footprint.

Over the years, managing larger teams and eventually my own software companies, I have had many opportunities to observe such geek-on-geek violence. Often they are surfaced by peer code reviews which, while hugely valuable, provide fertile ground for anodyne technical disagreements to blossom into fully fledged nerd warfare.

The engineers involved are typically well-meaning and driven primarily by a desire to do the right thing, albeit with a healthy dollop of ego thrown into the mix. The consequences of such disagreements, however, can be dire. It is hard to preserve the healthy spirit of collaboration necessary for productive teamwork when you are blinded by your incandescent hatred of your teammate's stance on strong typing, use of tabs for indentation or just the fact that they dared to criticize your impeccably crafted code.

To minimize debilitating developer conflicts, over time I have built up an arsenal of techniques for defusing these situations. Here they are.

Have clear policies and coding guidelines wherever possible

Software development, with its origins in the hacker culture of the 1960's, is often seen as an inherently anti-establishment activity. Official rules and policies, smacking as they do of corporate bureaucracy, are therefore deemed counter to the very essence of what it means to write code. Do not be fooled. The best software organizations have developed clear coding guidelines that are ruthlessly enforced.

The reason is simple: a large proportion of developer conflicts are over subjective questions of style that don't have a single correct answer (and probably aren't that important anyway). The best way to avoid them is to make a definitive choice one way or another at the organizational level. Your team may gripe about the "pointless" constraints imposed on them by their pointy-haired bosses. But they will get used the official policies soon enough and realize that maybe, just maybe, they won't end up slitting their wrists if required to use lower camel-case names or write JavaScript without semicolons.

Treat code review comments as suggestions not orders

Unfortunately, not all disagreements can be resolved by general coding guidelines. Ideally, there is a clear right answer ("your code leaks memory" or "you aren't sanitizing your database inputs") that any good engineer will accept. All too often, however, the situation is ambiguous and only one party can get their way.

In these cases I have found it best to let the person who wrote the code decide. Having spent hours laboring away at the keyboard to produce the code in the first place, they have more of a vested interest. If you need to make a fundamentally arbitrary decision about whose viewpoint to accept, it makes sense to treat review comments as constructive suggestions and let the author choose whether to accept them or not. The nature of peer reviews means that everyone will be reviewing about as often as they are reviewed, so no one will have reason to feel they are being treated unfairly.

Do pair code reviews when necessary to alleviate tension

Written communication can lead to misunderstandings that cause tempers to flare unnecessarily. The non-verbal cues that let our interlocutors know when we are being sarcastic, or just having a bad day, are missing in the sterile white box of a GitHub comment. Sometimes it can be huge help just to sit together and go through the review in person.

Educate developers on the importance of preserving political capital

Did you know that developers sometimes don't have the best social skills? I kid you not! In fact, this is a cliche mined for comedic value in popular culture from Revenge of the Nerds to The Social Network. Like most cliches, it has been taken to a hyperbolic extreme and ignores the many excellent engineers who get along just fine in social situations. Also like most cliches, there is a grain of truth to it (with your author being no exception). Sometimes it helps just to sit down with your team and explain to them the long-term social benefit of "choosing their battles" and preserving political capital, rather than digging in their heels whenever a technical disagreement does not yield exactly the result they were looking for.

Escalate important points to the whole team

When I was struggling to make peace with my first direct report (he of the 50 character-long variable names), at one point I turned in desperation to my boss, the company's head of engineering. He basically shrugged and told us that we should sort out the problem ourselves. If escalating to your boss might not be the best move, escalating to the broader development team (if you have one) can often be very helpful. With more people involved, a personal conflict magically transforms into a dispassionate (okay, maybe not that dispassionate) technical discussion among peers. Ties can be broken since there are more voices to be heard, and parties are more likely to accept the conclusions if they can see that the consensus is not in their favor.

Get rid of squeaky wheels

We all know the type. They have strong opinions, strongly held. In any discussion they are so confident of their rightness that any opposing view is rejected as either incomprehensible stupidity or willful trolling. A strong manager will sit down with these problem cases and explain patiently to them the importance of compromise to effective teamwork. If you have enough natural authority (it helps to be a talented engineer in your own right), and their case is not entirely hopeless, you may succeed in turning them around.

There are some software developers, however, whose intransigence borders on the pathological. No amount of rational argumentation seems to help. You may have heard them referred to as "brilliant jerks". They are great engineers making major contributions to the team's output, but their behavior saps the motivation and overall job satisfaction of their colleagues. It is hard to let a talented developer go, especially in today's job market, but let them go you must.