Some argue that “code snobs” waste time on trivia. They are accused of myopia and pedantry, and their peers claim that the effort they spend in crafting every detail in their code is a bad investment. While this can occasionally be the case, I submit that their ideas and comments offer more benefit than cost in the long run.

I recently authored a change in our codebase that involved refactoring a few of our core JavaScript classes and adding a couple of new ones. Nothing too out of the ordinary. Our development workflow requires a different engineer to code review any commits before they go on to the master branch (and eventually out to production). I felt good about the solution that I had come up with for the particular task I was working on and was confident that it would pass the code review process with flying colors.

The engineer that I had requested for the code review—who had recently reworked our Selenium testing framework and is an active proponent of code quality for our team—left a comment on our pull request system for a particular area of the code I was submitting. He suggested a slight change, merely that some of the classes I had implemented were not using a pattern that some of their analogous counterparts were using, and that I should adjust them to better mirror that structure.

My knee-jerk reaction was to ignore the feedback because that would be the fastest way to being “done” and would gratify my laziness. I have more important work to get done before the end of this sprint, I mentally rationalized. (The downward pressure on code quality that the scrum methodology imposes is a topic for another day.) I was halfway through replying to the comment with reasons to just move forward and approve my pull request anyway when I realized that he was right. The classes really would be more semantic if they were consistent with their counterparts. My conscience got the best of me. I swallowed my pride and decided to take the additional 30 minutes to context-switch and make the change.

I realize that whether or not my two small JavaScript classes were implemented similarly to those around them probably has no real bearing on the reliability and performance of our large codebase. But small decisions like that add up, especially when they are made every day. Imagine how different your codebase would be if every engineer on your team pushed out the best quality code they could, every single commit, with unfaltering cleanliness and snobbery! Over the course of even a year, the difference would be significant.

The sum of those small code quality improvements then trickles to your users’ overall experience. And then back into your business. For a SaaS startup, the product’s code is the gift that keeps on giving, for the entire life of the company; the more effort that is put into quality, the more valuable that gift becomes.

Perhaps a “code snob,” then, is simply the term lazy programmers use to describe their more disciplined peers. If that’s the case, I want to be one.