Imagine a world in which you’re on a team of talented developers and can pick up any project from any teammate, make meaningful contributions in a matter of minutes and walk away knowing someone else can come behind you and do the same. Sounds pretty awesome, right?

Unfortunately, this is the exact opposite of almost every team in the development world. Projects are almost always littered with personal preferences and traps you know someone might fall into. But you know they’re there, and no one else is working on the project right now, so it’s cool… you can ignore them and fix them later.

These are the things that cause nightmares for your fellow developers. And not just the “wake up in a cold sweat and it’s all over” nightmare. This is the kind of nightmare that doesn’t end until you refactor the project, drop supporting it altogether or hand it off to another unlucky coworker in a weird and vindictive game of hot potato.

This is where standardizing a set of practices you and your peers agree to abide by is important. By doing this, you alleviate massive headaches and allow everyone to focus on building cool shit, instead of cleaning up someone else’s crap code.

WHAT ARE STANDARDS?

Standards are simply a set of rules by which you and your peers agree to operate and hold each other accountable to. I’m sure there’s a more sophisticated answer than this, but this is my definition in layman’s terms.

There are a lot of universally(-ish) accepted standards in the development community. Examples of these are:

• Always write DRY code
• Create classes with SRP in mind
• MVC is the way to go

While all of these are debatable to an extent (because the dev community really just likes to argue about things), they’re important to know and use as a foundation for what your team’s standards look like.

In addition to these broad-brushed principles, you’ll also have stylistic preferences to explore.

WHO CARES ABOUT STANDARDS?

Everyone. Before you flame me on Reddit, let me explain.

Everyone has their own way and preference of doing things. Whether they realized it or admit it, they’ve subconsciously created a set of standards for themselves and tend to follow them on every project they touch. Everyone wants a project handed to them that adheres to their set of made-up rules and over which they will lose their mind (temporarily) when that doesn’t happen.

When you’re working on a team, it’s necessary to vocalize and reconcile any conflicts in preferences that may arise. This may even mean making sacrifices in how you like to do things, but it’s for the greater good and will make your work and life more enjoyable.

via GIPHY

WHY IS THIS IMPORTANT?

Lots of reasons. Efficiency. Mastery ability. Sanity preservation… you get the idea.

To illustrate this, imagine you have a friend, we’ll call him Frank. Frank likes to start every single conversation in a completely different language. Now imagine you call your friend Frank with something you need to solve really quickly and have an exchange like this:

Frank: Bonjour?
You: Dammit, Frank, you know I don’t speak French!
Frank: Pardon?
You: @&%$ hangs up

via GIPHY

That’s not a very effective use of your time, is it? That’s quite literally what it’s like to develop on a team where there are no standards. It’s why developers hate… no… loathe working on code they didn’t write in the first place. Someone wrote it with completely different principles and rules in mind.

By creating standards and holding yourself and the rest of your team accountable to following them, you create an environment within your team where the expectation is that every conversation will begin in a common language and dialect. This removes unnecessary cognitive overhead and frees up brain cycles to concentrate on solving problems and doing work.

And that’s when the magic happens.

via GIPHY

HOW DO YOU DO IT?

I could write an entire series of posts on how to actually create a set of standards for your team. Maybe I’ll do that someday. For now, let’s leave it at the broad strokes.

The important things to accomplish are:

• Agree on language preferences and support
• Agree on library preferences
• Agree on task runner preferences
• Agree on stylistic preferences
• Agree on universally accepted practices
• Agree on an enforcement/code review practice

As you accomplish each of these, write them down. If your standards aren’t documented in an easily accessible location, you don’t have standards. You can’t measure yourself or your peers by something that only exists in everyone’s heads.

WRAPPING UP

By agreeing on a set of defined standards for yourself and your team, you’ll create a group that masters how to utilize their tools and works together better than others. You’ll spend time actually accomplishing things instead of arguing about principles or why Frank has been favoring French these days for some arbitrary reason.