I've been always drawn to bringing structure where it was lacking, systematizing information and defining processes. Not sure if that's a designer's trait (along with a particular fondness of symmetry) but it continues to carry through all the work I do. One of the ways I utilise it is by creating standardized approaches for others to follow.
"Best practices"
When writing software we often look for guidelines on how to do it in the most effective and standards-compliant way. We search for patterns we can follow. Standards are obvious signposts leading us to valid code (which is why we call them standards in the first place). The other way of approaching this problem is to look for so-called best practices.
Why “so-called”? Because we don’t really know where these rules came from. Is it because of the broad adoption within a given community, or something else?
The tricky thing about so-called "best practices" is that they have been widespread, oftentimes leading to cargo culting and detaching the standard from the "why" behind it.
While an approach may be valid for one person, one group or one section of the industry, it might be completely disempowering and useless for others.
A good example of this is web sites vs. web apps: there are a different set of practices that should be applied to each.
Like baking recipes, one approach might result in the most visually appealing pie, but that doesn’t necessarily mean everyone will enjoy eating it.
The human side of technology
Practices are often built without targeting the crucial aspect of collaboration—the human factor.
The secret lies in understanding of good patterns and mindfully applying them (and we’ve elaborated on that a little bit here).
A starting point for building up effective collaboration is to create resources than can serve as learning and reference materials. One of the ways to do so is to have a style guide (see Github, MailChimp, The Guardian and A List Apart). They feature not only coding patterns but also specific interface elements. They are becoming more and more widely adopted—not only by big companies or teams.
Collaboration truly starts with just one person—projects are handed off, contributors appear, people change jobs.
Writing software as if we are the only person that ever has to comprehend it is one of the biggest mistakes and false assumptions that can be made. The greatest challenge that we’re facing with software isn’t technology itself, but effective collaboration.
What if you don't agree?
You're likely to have instant agreement on some standards within your team, but guaranteed there will be far less easy consensus on others.
In a recent discussion about standardizing our approaches, it became apparent that on some stylistic choices I disagreed with my teammates. For example, with Jade, I prefer including classes alongside other html attributes like so:
p(class="some-special-paragraph another-exciting-class") Here's our amazing content.But many of my other teammates preferred to use Jade's dot-chain approach, which creates a visual separation from other attributes:
p.some-special-paragraph.another-exciting class Here's our amazing content.I was the one trusted by the team to make the final call on our standardization decisions. So what did I do?
I didn't have a strong argument why one approach was better or worse, so I chose the approach preferred by more people.
You're going to have disagreement on what conventions are right for your team and that's to be expected. But as Lynn talks about in this post about making design decisions, the important thing is to "decide to decide."
It doesn't really matter what you choose, as long as you all agree to abide by one approach.
Building empowering resources
As &yet has grown, we too have noticed an emerging need for resources that will not only bring cohesiveness to our work but also empower less front-end savvy members of the team to improve.
I’ve worked for several months on various projects surrounding this effort, the beginning of it being the Yeti Guide.
Yeti Guide is a collection of general rules for writing maintainable front-end systems in Stylus and Jade.
Naturally, it is opinionated and includes some of our preferential choices, but it’s also inspired by the work of some of the most respected front-end developers we know—Mark Otto, Nicolas Gallagher and Harry Roberts.
Hopefully it can serve as a source of inspiration to some of you.
We'd love to help you find your team's best practices for frontend development. A great starting point could be a frontend code audit by our super-friendly team of veterans. Reach out to our team and say @fox sent you. :)