A style guide is the set of rules for how your team writes software.
Style guides at small companies are great. At a small company, a style guide generates the feeling of relief.
“Aaaah, this settles it” 😌
As a developer, you might be in the middle of a question about the right way to do something, or there could be a disagreement about syntax or library use.
It’s already been decided. With a lovely, simple rule that resolves the question. The rule applies to you perfectly because it was written for your use of the technology. You trust the rule because it’s written by people you work with closely, every day. You might even have been in the room when it was decided.
Incentives and Hard-Won time
At a small company, typically all the people involved in the style guide decisions are directly connected to the day-to-day software development work that the company is doing.
Usually the style guide conversation is started by the individual developers. They say:
Are we doing spaces or tabs?
Should we standardize our import style?
We’re not using
eval, right?
Or it could come from a Scrum Master as part of a Working Agreements 1 initiative. But, at a small company it’s always led by the core developers. Once they decide a style guide is needed, they have a couple meetings, hammer things out, and one of the blessed holy texts of the team is born.
This process has a nice way of aligning incentives. If you’re at an app company, the “style guide committee” is made up of people whose main job is to build the app. The incentive is to create value for customers. Any time spent on the style guide is wrestled away from the PM, or the CEO, or the founder as necessary “chore” time.
Hard-won time isn’t wasted. It tends to get spent on the most important problems and leaves the rest for later. In the case of a style guide, that’s “just right”.
If this was useful to you, please let me know @SimplGy.
If you liked this post, share it on Twitter
« Previous: Book Summary - Debugging Teams • Next: JavaScript Bitwise Hacks - My Favorites »