I love reading articles and snippets to find the latest and greatest in CSS, but the reality is that many of us are on growing teams, dealing with the (sometimes) harsh fact that not all of our developers are frontend developers. If there’s a way to get our CSS better in the long run, it’s not by doing the bleeding edge of things (and then providing fallback after fallback), it’s, instead, focusing on levelling up our current resources, displacing the worst that we see, today.
Since there are a few articles that articulate opinions on ‘worst practices’, let’s focus on the strategies we can use to displace those practices. The key components I recommend are training, style guides and code review.
Training doesn’t merely start on a developer’s first day, or end after their first few days or weeks. Training comprises of intern programs, onboarding, continuing education, indoctrination documentation and perhaps more. For intern programs and onboarding sessions, be sure to include frontend development for all developers, even if they’ll rarely touch that part of the stack. The reality is, they probably will eventually, and it’s best to be prepared.
Continuing education is both a boon to your codebase and a great recruiting tool – people often become developers because they like to learn. I’ve written about the joy of company hack days, but other continuing education opportunities range from traditional external sources, such as conferences, to internal lightning talks and book clubs.
Style guides are another important component. There are three kinds: an interactive style guide where components are combined in common arrangements; a visual dictionary-type style guide where individual components are defined and shared; and a textual style guide that clarifies common idioms and practices. The Starbucks style guide is a hybrid of the interactive and dictionary style guides, but more interactive; it doesn’t just give components, it gives components with context.
If you’re intrigued by the visual dictionary option, you’ll want to see GitHub’s style guide. GitHub uses an open source tool created by one of its own called KSS (Knyle Style Sheets). This mode of style guide is generated through documentation written in your SCSS and is a very good way to progressively build a style guide while providing some information and use cases for each component.
Adding a textual style guide on your CSS to your company’s documentation is a valuable way to passively mentor developers. Every time a developer has to stop and figure out why code is written a certain way (such as sloppy indenting), they’re wasting valuable development time. GitHub’s style guide includes a textual component. Google and ThinkUp are other good examples of this type of style guide. These guides serve as good ‘the argument solvers’ for any idiosyncrasies and help guide a team towards clean-looking, scannable and readable code.
Code reviews
A great way to enable code quality monitoring is to introduce code review into your team’s workflow. Code review is a process by which all code sent to production is first approved by at least one other developer, preferably a senior developer. If your team uses GitHub or a similar version control system, you can easily add line comments to pull requests to discuss code, point out style guide violations and approve it to ship before it’s merged into production.
If you’ve made a commitment to levelling-up your team and making code quality a priority, also consider the overall architecture and development as well as how the staging and shipping process plays a role in how you can mentor developers and evolve your codebase.
It doesn’t all happen in a day. Bring on new strategies a little at a time, monitor how they work for your team, and I’m sure you’ll see great results.
Pam Selle is a professional web developer and UI engineer in Philadelphia, PA, and currently works for AxisPhilly. This article first appeared in issue 241 of net magazine.
