Any time you ask your team members to “remember to do X”, at some point they’ll forget. Or they just didn’t understand you in the first place. Or they were out of office the day you brought it up. Or you’ll have new team members join who never heard your advice. You can almost guarantee that at some point somebody won’t do X. Here’s a few examples of X:
When somebody doesn’t do one of these things, it’s much more effective to blame (and improve) the tooling rather than the individual.
Tooling is much more effective than people at preventing mistakes, encouraging patterns, and discouraging anti-patterns. All of the items in the above list could all be caught by tooling.
Let me take a step back and explain what I mean by “tooling”. Tooling can include any of the following:
So let’s re-visit the items at the top of this post and try to apply tooling to them:
“Remember to run linting locally before you commit”
“Remember to run the tests before you merge”
“Remember to update the changelog”
“Remember to write tests”
“Remember to think about accessibility while you’re coding”
“Remember to rebase before you merge your PR”
“Remember to squash merge your PRs”
“Remember to update the lock file before you commit”
“Remember to read these docs before you make changes in this section of the code”
“Remember not to increase the bundle size”
With a little creativity, tooling can catch many problems. I believe tooling to be so important, that I’d wager the performance of any technology based organization is highly correlated with the quality of the tooling.
In short, blame the tooling, not the people.
Ben is an award-winning software developer specializing in frontend development. He builds delightful user experiences that are fast, accessible, responsive, and maintainable and helps others to do the same. He lives with his partner and dog in Kitchener, Ontario.More About Ben »Follow @benlorantfy on twitter »