Points for Style
It’s been years, but I can still remember my lab partner’s frustrated exclamation clearly. “It’s not a rule. It doesn’t matter!”, let out in response to seeing the results of our automatically graded submission of a program in a mid-level Computer Science course. Our work was functionally perfect, but the grading tool had subtracted several points over incorrect indentation size and other various style errors. He was right, technically, as we had adhered to the implementation requirements and using our program would produce indistinguishable results from our classmates’, but the faculty had chosen to take a stand. They chose to force us to care about style, or at least notice it. They chose to enforce a few basic style guidelines at a time when it seemed irrelevant, a time when we did the vast majority of our programming as a single developer in a vacuum. I’m not going to say I saw the light immediately, and I don’t remember a single student arguing in the system’s favor early on. I did, however, adopt good habits that I would later come to be thankful for when I learned what is a shocking truth for many young devs:
Style is not extra credit. Style matters.
Now the vacuum is gone and there is no auto-grader, just a group of incredibly smart fellow developers whose time is valuable and sanity should be protected. I’ve been a strong advocate of vigilant style practices for quite a while, but Shockoe turned out to be a place where justification for that is omnipresent. Due to the nature of our business, every developer makes contributions to a wide array of codebases, and has a hand in reviewing even more. We’ll wrap up a project and deliver it to the client, who then shows it off to the rest of the company and stakeholders. Soon we get feedback… management loved it! And guess what, they want a bigger, better phase 2! This is fantastic news, but it’s time to start planning, and “bigger and better” usually means additional resources. That means bringing new developers onto the project. Getting up to speed on a project quickly is a crucial skill for us, and we want to make that transition as smooth as possible. A little extra time considering style and writing cleaner code up front could make the difference between the next developer brought on grasping it instantly or spending an entire afternoon pulling their hair out.
Every new developer at Shockoe, usually on their very first day, is invited to a repository where an internal fork of the Idiomatic.js style guide lives and asked to study it. We have eyes on each others code constantly. Every user story is a pull request that gets reviewed, critiqued, and signed off on by a coworker.
I’ve known a lot of developers to be hesitant to request stylistic changes to another’s code, and I shared those feelings once too. It can feel like you are pointing out insubstantial issues, or that style is a personal choice and you might offend them. What we need to remember is that we are all trying to improve. If another developer reviews my work and thinks “I would write this differently” then I want to hear how. Several times, seemingly minor comments or questions have sparked a discussion that roped in multiple colleagues and left us all writing better code.
So don’t be satisfied with code that gets the job done. Strive for code that actively helps the next dev down the line, that they will thank you for, because when that time comes, you could be on another project, thanking someone else in kind.