Do your team a favour: start writing a styleguide
Tags: teamwork
Published: 2018-05-07 17:02:40

---
title: Do your team a favour: start writing a styleguide
published: true
description: What is the best way to code? (Spoiler alert; It's "together")
tags: teamwork
cover_image: https://thepracticaldev.s3.amazonaws.com/i/y16n2xj27zgk3tvec53j.png
---

My job has many positive aspects, but if you were to ask me what the best part of it was, I wouldn't hesitate to tell you that it's my team. I am fortunate enough to work with a group of individuals who are all, frankly, awesome. 

We're made up of people who have differing levels of experience, and have a good balance of people who focus on _what_ we build and people who focus on _how_ we build it, but what strikes me most often is our ability to say "I've got an idea...", and know that it'll be _considered_. 

This has left us in the _very_ fortunate position of having the psychological safety to be able to ask "What do you think of [_insert some idea here_]?". 

To begin with these ideas came when a member of the team had a specific preference for something (by way of a basic example, let's say, formatting of ternaries), which would be discussed and adopted - either outright if everyone was on board, or as a "trial" if there was some doubt - and we've had a good few instances now of not everyone being entirely convinvced when something is proposed, but then evangelising that very thing to other teams after a trial run has proved its worth.

Once we got into the habit of saying "What do you think of this?", we found that everyone _just kept on_ having thoughts and ideas, and would be actively looking for things that other people did too in order to make our codebase as good as possible (and by "good" we tend to mean "understandable" - and by "understandable" we mean "we can teach you our preferred patterns and explain why we prefer them").

In the same way that having your ideas repeatedly shot down will lead you to _stop_ vocalising those ideas (or worse, stop having them at all), having your ideas _considered_ encourages you to have more of them. Apply that to the entire team, and you've got yourself a group of people who are constantly improving, together. 

At some point we decided that recording these preferences would be a helpful way to ensure that anyone joining the team could quickly get up to speed, as well as benefiting those of us with less-than-stellar memories (read: me), since we'd be able to easily check anything that had been decided previously. As much as this might sound horribly oppressive, it's worth noting that our styleguide is entirely decided by the team itself, and lives within a GitHub repository so that any member of the team can submit a pull request with updates, and every member of the team can discuss and approve/merge.

This saves us a _lot_ of time reviewing pull requests in our codebase, as there are a lot of things we just _don't_ have to comment on where we ordinarily would. Moreover, there are things we may _not_ ordinarily comment on because they seem "too minor", but we'd waste time deciding whether it was worth saying something, and now that doesn't happen any more either. 

It also means that the whole team feels a greater sense of ownership of the code that we write, and this makes a _big_ difference to day-to-day work.

So, with that in mind: When someone on your team has an idea, I urge you consider it. And if you don't already have one, start talking to your team about your own preferences - I'm seriously glad we did. 


### Mentioned in this post
Psychological safety: 
  https://en.m.wikipedia.org/wiki/Psychological_safety

Airbnb's style guide: 
  https://github.com/airbnb/javascript/