Problem
Every engineer contributing to our projects came with a wealth of experience which informed their preferences around code style and formatting. Each arrived at their preferences through trial, error, success, and failure. Unfortunately each arrived at slightly different conclusions. This was not a sustainable long term approach for a growing team.
The organizational problem with allowing divergent style preferences within a team is that it results in less productivity and a lot of avoidable low-level conflict. People change code unrelated to their work, nitpick pull requests, and expend energy on minutia instead of improving the product.
The technical problem is that this behavior introduces avoidable bugs as code is unnecessarily churned while pull requests become difficult to review as much of the patch has no bearing on the feature being built.
The emotional problem is that people get attached to their own ways and don't want to be forced to follow arbitrary rules which they don't agree with.
Solution
In order to support a large number of engineers contributing to a shared set of projects while maintaining consistent style and formatting we had to lean on automation. But before we could lean on automation we had to agree about the problem.
I opened an issue to discuss the problem, laying out the challenge as I saw them. I proposed that we adopt ESLint configured with an extended1 version of AirBnB's ESLint configuration (the extensions would be made to bring it inline with the team's general preferences). The proposal explicitly stated that there was no de facto "rule decider"2, but that anybody could propose modifications. Whether or not to adopt the proposed rule changes would be up to consensus.
There are trade offs. People would have to ensure their code is linted before it can be merged, which is a potential point of frustration. This is an understandable fear: nobody wants errors coming out of nowhere keeping them form getting their work done. The trade off is that what they get out of this compromise is that nobody will nitpick their code – if it passes the linter then style and formatting critique is off the table. A big upside to this is that we can automate the linting work away through editor integration and auto-formatting.
The team agreed. I helped people get their editors configured to automatically surface (and often fix) lint issues. I published @simple/eslint-config, and integrated it into all of our web applications (no small task).
Outcome
The outcome has been overwhelmingly positive. Pull Requests no longer get stuck in review for days. There is no back and forth churn of style and formatting as different people work on a file. When linting issues make it into a Pull Request (which is rare, given the widespread use of editor tooling), our CI reports those failures back to the Pull Request before it even gets into peer review.
Addendum
The Prettier auto-formatting tool has come along in the time since we adopted ESLint. I believe we would have used Prettier for much of what we use ESLint for today. We may yet do that, but our current ESLint setup has addressed all of the productivity issues so there's no pressing need to change tooling yet.
Notes
- We couldn't go with the stock version of AirBnB's configuration for two reasons. The first was that just didn't agree with some of them. The second was that some rules would have required a level of refactoring which would have had a significant chance of introducing bugs, and in doing so hurting user experience while taking engineering resources away from product development. If the some of the stated goals were increased productivity and happiness, then adopting the default configuration wholesale would have worked against those goals.
- Why no de facto rule decider? My experience in every organization has been that when someone assumes this role they abuse it and end up holding back the entire team. People get caught up in the dogma of their craft and use their clout to push back on changes which make their rule set irrelevant, such as shifts in the industry away from the technology associated with their expertise.
