In Praise of Styleguides

I’ve repeatedly jumped into Ruby on Rails codebases which I wouldn’t otherwise care to maintain save for a salary. The common theme in these is that the developers, over time, had varying degrees of comptence and different understanding of underlying features within the framework. Requirements of features change too, obviously, but there’s a fundamental theme within writing code inside the framework that remains the same.

Just like writing literature, documentation, or prose, we all have different inherent styles. It’s a part of who we are as developers. It’s a personality trait, it’s a preference, it’s a learned skill.

For all the grief that my friends and I give the front-end ecosystem, they have something I really wish was considered “cool” for the back-end: styleguides and storybooks. Shopify’s Polaris and Github’s Primer both come to mind as great open-source examples of structure on the front-end, along with principles, standards, and usage guidelines.

For some reason, the back-end doesn’t get the same treatment. Why?

Do we — developers who focus on the back-end — truly think that every feature we create will be unique in its construction? It’s naive to say yes. For 95% of my code, it does the same thing: I handle an HTTP request, I manipulate data, I give feedback to the user. Sometimes this means enqueueing a background job, persisting data to an in-memory store, or calling an API. Those are the things that fall into the remaining 5% of code I write, but not in its entirety.

Because of the large amount of moving pieces in compared to the front-end, why aren’t we actively promoting standards within our codebases? Why do we allow our fellow developers to choose their own adventure? Back-end development is hardly Breath of the Wild as much as it is Minecraft. There are templates we rely on — mental models of how we envision a feature to be created — but we’re very seldom to share these with other developers.

I’m not saying that we should force styles upon each other, but I bet you know a codebase that could have used a for each type of component in your app: from controllers to models, presenters to decorators, serializers, workers, and everything in between.

Invest in them and they’ll invest in you.