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.
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.
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.