Code is rarely written in isolation; we often work with people to bring projects to life. Clean code, therefore, depends on both your approach and the approach of the entire team. A team that owns a code base continuously decides the tools, conventions, and abstractions that they'll use to achieve their goals. As such, members of the team must be able to communicate well and share perspectives, molding these perspectives into a clear outcome. Sometimes, compromise is necessary. And compromise can often hit the ego.

JavaScript and its tools are susceptible to strong opinions. Over time, we each gain experience in working with different approaches and, often through toil and pain, end up having a set of beliefs about which approaches we think are best. These beliefs may not always match those of our colleagues, though. When there is disagreement, the path to resolution is unclear. Without resolution, the team and the code base can splinter, causing more damage.

Imagine the following scenario between Adam and Susan:

There are likely many different ways this disagreement could be resolved. We could suggest, for example, that both individuals build their case and continue to debate the various merits of each testing framework. That may resolve the issue. But equally, it may not. The argument may persist, drawing a wedge between the individuals and leaving the code base in a state of flux without a firmly chosen testing framework. The paths to resolution are not always clear in cases like this, but what is clear is that resolution is less likely if uncompromising egos are involved. If both Adam and Susan can start to see each other's perspectives, broadening their view and un-entrenching themselves from their own opinions, then the path to resolution becomes much clearer.