On Code and Community

People often ask me “Why Sass?” Why choose Sass over another preprocessor? Why is it so much more popular than its competitors?

That’s a great question, and aside from all of the technical conversations about similarities and differences between preprocessors that can follow, the real answer is: the community. With a thriving, benevolent, and encouraging community of designers and developers, Sass has grown to be the irrefutably most popular and mature CSS preprocessor out there.

Let’s take a look at what happens in a large, healthy development community:

More people look at the source code, which means more people are there to triage issues, log bugs, and help develop the source.

More people try out the product because it’s improving more rapidly.

More people write about using the product and develop new ideas on workflows.

More people help contribute to the documentation.

More people develop 3rd party applications and toolkits to improve upon the product.

More people talk about using the product and its tools at meetups and conferences.

More people switch to using the product in the workplace.

More people are introduced to the product, from development teams to interns to designers to project managers.

From development teams, to interns, to designers, to project managers, this is cyclical.

Eventually there are meetup groups, books, videocasts, and a conference devoted to the product. Community is essential in the life line of any piece of software because without people to use your product, what’s the point? This is something that the Slack Chat Product Team understands very clearly, and if you read the story of their journey, you’ll see how user-centric their development approach was. The founder of the company recalls “when key users told us something wasn’t working, we fixed it — immediately.”

People are Everything

Word of mouth is the number one contributor to product adoption than anything else. I learned about Sass and Compass at a Refresh Meetup in Washington, DC. To me, it was a new tool — a simple idea that I started tinkering with until I found so much value in it that I passed it along eagerly to everyone I knew.

Studies show that 92% of consumers believe recommendations from friends and family over any and all forms of advertising.

This is so important for developers, who often think product-first and not people-first to understand. Your audience is largely influenced by its community. Once you have a basis, this grows exponentially. I can’t even begin to name how many grid frameworks, style guide generators, blog posts, and other tools there are out there that have branched off of Sass, and which introduce new developers into the mix continuously.

Building a Beautiful Dev Community

One of the most amazing things about the Sass community is its brilliant diversity and dedication to embracing inclusivity. This is a community where the code of conduct is taken very seriously and where any form of intimidation is really looked down upon. All opinions are welcome, encouraged, and embraced.

What happens when you take inclusivity seriously is that it decreases barriers to entry. Developers feel more comfortable, therefore unafraid to ask questions and report bugs. This increases participation and introduces new opinions into the mix. New participants are excited to be a part of something, as they introduce zeal and experimentation, and are likely to pass along the project to their friends and colleagues. And it grows, and grows, and grows.

Reaching Out

But Sass isn’t the only example of a burgeoning development community. I want to talk to you all for a moment about Craft. If you aren’t familiar, Craft is a Custom CMS, created by ExpressionEngine developers, Pixel and Tonic. Let me tell you a little story about this growing community.

Craft version 1.0 came out in June of 2013. At the time, I was interning at a Development Shop called Viget, who was pretty involved in the ExpressionEngine community at the time and curious about this new product. I had the opportunity to try it out first, having the opportunity to start a brand new project with no clients to convince. Despite being a junior in college studying graphic design and struggling to learn about ARIA roles and the <figure> element, the kind of treatment and support I received from the (then tiny) Craft community was inspiring.

The two developers, Brad and Brandon, held (and still hold) an open chat every Friday at 1:30 PM PST where they asked people to log in and talk about their issues, their successes, and the projects they were working on with Craft. When I was having difficulty with the system, they took time out of their day to remotely connect to my computer and fix the bugs that I was having issues with (twice actually — I’m really good at breaking things). It was very clear that the developers sincerely cared about the people using their product and it was clear.

Setting an Example

And it grew slowly from there: at first Craft workshops started popping up at conferences, then they had their own Craft Summit, and now, most recently, as I was browsing meetup groups in my area, I noticed that there was a Craft meetup group. It’s been a year since I’ve built anything significant with the Craft CMS, but I am always going to recommend it when asked. Because I sincerely enjoy using it, and because the developers care about people, and developers who care about people tend to breed the kind of community of people who also care about people.

The maintainers and core contributors of any product set the example.

At SassConf last year, Chris Eppstein said something along the lines of “I don’t know how this community came to be so awesome, but I’m really thankful for it.” Well the answer to that is simple. It’s because the people who built it made it that way, and made sure it stayed that way during each step of the growth process.

Compassion is Key

Read any dev forum and you’ll likely see people bashing each other’s code and opinions on subjects, proving their intellectual superiority as communities become increasingly fragmented. This just leads people out of the conversation, feeling intimidated and frustrated. You never know what people will make or contribute in the future.

If you want to foster a supportive community, try to decrease barriers to entry as much as you can. Here are a few recommendations:

Have a code of conduct. Don’t just “have” a code of conduct, but enforce it, and stand up for each other’s voices.

Talk to your users. Have a chat room (IRC, Gitter, Hipchat, Slack) where anybody can join and contribute opinions or ask questions.

Have a Contribution Guideline. How can people participate? Guide them through setup and in areas where they can begin to help out with the project.

Be careful about the vernacular you use when commenting on Pull Requests. I really like this guideline. Be sure to include something similar in your Contribution Guidelines or Code of Conduct.

These tips don’t just relate to the FOSS (Free/Open Source Software) Community. They are even more important within a workplace. Remember: People above code. Encouragement above superiority. Those are the traits of a blossoming development community.

Una Kravets is a Front End Developer currently residing in Austin, Texas. She co-founded the SassyDC and ATXSass meet-ups, is a core member of the Open Design Foundation team, and is a big advocate of performance-first design.