Frontend Guidelines Exercise

I’m helping my client’s web development team establish some frontend guidelines as we roll up our sleeves to build a new website from the ground up.

We’ve done a projects together in the past, but (naturally) they were on pretty pretty tight deadlines, so despite our best intentions the team’s code consistency fell by the wayside as we raced to the finish line project. Sound familiar?

We’re determined to fight that entropy this time around, and I thought of a fun little exercise to do with the team to get everyone on the same page at the beginning of the project. Here’s what we did:

1. Have a conversation

This might sound crazy, but developers on your team might have opinions on how to write frontend code. Get all the frontend people all in a room together to discuss how you’re planning to write code together.

I created a frontend guidelines questionnaire to help facilitate these conversations.

bradfrost:frontend-guidelines-questionnaire

Discuss the pros and cons of different principles, methodologies, syntaxes, and structures. It’s worth your time to have some healthy debate on the best way to approach things. Remember that the team needs to work together, so individual (sometimes strong) preferences may need to take a back seat for the good of the team and product.

2. Establish some initial frontend guidelines

Take some notes during this meeting and immediately start transforming them into some initial frontend guidelines.

These guidelines will undoubtedly get fleshed out refined as your project progresses, but at the beginning focus on getting a loose consensus on frontend principles and agree to specific naming conventions and syntax.

Get the team together and review and discuss these conventions. Once everyone feels good about the working hypothesis, put the guidelines into action.

3. Code a molecule

Now for the fun part! Pick a relatively simple component for the team to mark up and style. Each developer will put their heads down and apply¬†the agreed-upon syntax/structure to the component’s HTML and CSS.

For our project, we picked a simple media object pattern:

See the Pen Media block pattern frontend guidelines exercise by Brad Frost (@bradfrost) on CodePen.

4. Review

After about 20 minutes of coding, get the team together and have each developer present what they came up with. You’ll likely be surprised how much deviation can occur even with agreed-upon frontend guidelines in place.

Talk through discrepancies, identify potential weak spots in your guidelines, and have each developer tweak their code based on the feedback of the group.

5. Repeat and refine

We didn’t get time to do this, but it would have been great to do a few more rounds of this with components of increasing complexity. I suspect that with each round everyone would get a little more comfortable with the conventions we’ve agreed upon.

The nascent frontend guidelines should be updated based on the reviews and discussions around the exercise. Your frontend guidelines can and should be referenced, revisited, and revised throughout the course of the project. It should be an evolutionary, living thing rather than a static file that doesn’t truly represent the way the team is writing code.

Over the next few weeks, my team will be conducting some pretty thorough code reviews to make sure we’re on the same page with our¬†frontend conventions. I suspect the code reviews will lighten up as the project progresses, but I think it’s a smart move to make sure we get things right at the beginning of the project.

So that’s the exercise! Rather than waiting until the whole team is stressed out and slammed with deadlines, you can proactively establish conventions and make sure the team is on the same page.