The A List Apart Blog Presents:

Writing CSS on Growing Teams

Article Continues Below

This fall, my team started a new project and for the first time in a long while, I was working with another developer as I started to write the styles for the interface. In fact, I started the styles, and then went on vacation while they took over.

This project has been an exercise in writing modular CSS, which I love, when working in a team. Having been a solo front-end developer for quite some time, this was a new challenge to me. When you want your CSS to be reusable, how do you have several people working in git branches on different pages without writing completely separate styles?

Surprise: it’s not really about how we write CSS, it’s about the process.


Communication is the biggest piece of making this work. As we work throughout the day, we talk about the styles we’re writing and where they might be used across the application, so the other person knows how work in progress could impact the parts of the application they’re focused on.

For example, if I change a wrapper to meet the new design spec and want to be consistent across the entire application, I mention that it’s been changed, what’s changed about it, and the branch where I’ve done this. When my coworker normalizes buttons in one branch, they let everyone know that this will be taken care of for the whole team when that branch gets merged into the master branch.

Code review

I’ve worked on teams that did code reviews, but my current team didn’t always do them as we worked. As the team grew, we decided to incorporate code reviews into our process. The best part of a code review is learning from each other. Maybe the way I’ve done a layout works, but could it be better? Are there styles I’m not familiar with that would make it better?

When we review code, we discuss our modules to ensure everyone agrees they’re going to be the best way to move forward. When talking through how to use SVGs in our code, for instance, we discuss when it’s appropriate to use them as background images as opposed to images, or inlining them by putting the SVG code right into the template.


Finally, we came up with what’s important to our team when writing CSS and we documented that. We use the ideas from Jonathan Snook’s SMACSS to guide us, along with explaining features of Sass we want to stay away from (such as nesting), so the entire team has an easy reference.

By making this explicit, we can refer back to it for reminders as we review code. In the near future, we also hope to build a style guide to further document our work. That way, we’ll have documented how we want the code written, and we’ll have a more visual documentation of the styles we’re using to retain consistency as we continue working on the application.

As a team grows there are always bumps along the way, but it’s been a great challenge to start documenting our process, thinking about how we write CSS in a more formal way, and reviewing it together to make sure we’re all on the same page. For me, the challenge of going from being the only person writing everything, to adding new team members and working together, has been fantastic.

About the Author

Susan Robertson

Susan Robertson is a front end developer working with Fictive Kin who focuses on CSS, style guides, responsive, and accessibility. In the past, she has worked with clients such as FiftyThree, Imprint, Cloud Four, and worked for Editorially, The Nerdery, and Cambia Health. When not actually writing code, she can be found writing about a wide variety of topics on her own site as well as contributing to A List Apart and The Pastry Box. When not staring at a screen, she reads comics and novels, cooks lots of yummy food, and enjoys her Portland neighborhood.

10 Reader Comments

  1. We started building a styleguide to have the common set of UI patterns. Design team drives defining these patterns and continually updating or adding to the styleguide. This not only helps maintain consistency across your product, but also reduces the amount of CSS written. We simply use selectors from the styleguide, we write CSS for very one-off cases and padding/margins. This has been extremely helpful and easy to bring engineers onboard. Styleguide can also guide people in to writing semantic HTML. Check out KSS (Knyle Stylesheets). It was simple to set up. You can specify how the markup should be for consuming the CSS.

  2. On our recent project we had 3 to 4 people working in the CSS at once, and it caused a lot of issues with shared CSS fixes in one place breaking things in another.
    Things that helped included using a global CSS file split out into sections, then local CSS files for templates, and some CSS files shared in specific areas. Then one person became a gatekeeper on the global CSS file, and people would be assigned responsibilities for particular shared files. Any changes needed would have to be approved by those people. Also ensuring the same front end dev worked on the same template helped, plus as you say communication was key, particularly in terms of people knowing what other people were working on at any given time.
    Also ensuring people knew how to use Git properly was important to avoid them making mistakes resolving clashes.

  3. Vital question regarding CSS that nobody has provided an answer to in many forums I’ve posted if I may please. I currently use the weebly template provided by my web hoster Ipage for my site which when I try to combine CSS & JS files as the major setback in optimizing my uploading speed, as soon as I think I have saved the changes, the software reverts back to the weebly template. I have tried rebuilding the site from scratch in wordpress but as soon as I add a couple of vital features like a contact form by installing a plug-in, the site becomes larger in size than the original template. Is there another software that be a better choice? Thank you!

  4. We used that for [url=]Fondation Foch[/url]

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA