How to grow a successful programming language community


In this post, we’re going to talk about what it takes to run a successful community. The Elm community generally has a reputation for being friendly and welcoming. The majority of discussion happens on the Elmlang Slack group. Since the early days of the Slack group, I became one of the owners. We’re hitting 8000 users soon (today). So here’s a little blog post about how we helped make the community grow, and how we got it to the helpful state it’s in today. There’s a bunch of awesome helpful people in our community, but I won’t speak for them — these are just my personal tips.

Tip 1 — Never let a question go unanswered.

In the early days of the Slack group, there were very few people on there. People would pop by, ask a question, and it might get answered several hours later. With a language like Elm, which has a large amount of users coming from very different languages like JavaScript or Elixir, it’s easy for new users to stumble on blocks before getting anywhere — especially in the early days, when blog posts are rare.

During these early days, it felt very important to help people progress with Elm. So, I made it an internal goal to try to answer every question. For a good time, I did actually manage that — answering every single question asked on the Elm Slack. The people who were answered were more likely to hang around, and therefore help other people. These days, there are dozens of people waiting to answer all kinds of questions.

You don’t always need to know the answer when you start answering someone. You can find it out as you go along, as long as you can explain what you’re thinking, you’re gold.

Tip 2 — Lead by example

There’s been very few times when I’ve had to call people out on the Slack. I don’t think we’ve had to ban a single person. An important part of growing a healthy, welcoming culture is to be welcoming yourself. Make people feel like they can get your help, and they will come for it.

For the times when you do need to deal with a situation, handle as much of it as possible in public. Be reasonable. Remember that the people you’re talking to are people too, and if they did something, they probably had a reason for it. Be understanding but firm. If they broke the rules or are damaging the community, it’s okay to set some guidelines to help them contribute more productively. Don’t be afraid to put your foot down. If you’ve led by example, then you won’t find yourself needing to do so much.

Tip 3 — Keep a library of examples at hand

When a question comes up lots of times, it’s good to have references to hand. For example, if someone is curious about how eq works in Elm, it’s good to be able to refer them to the exact line in the core package. Another example is when someone encounters a bug — it’s important to be able to remember where to find the issue for that bug, and refer them there.

I don’t have any real tips on how to achieve this, this seems to be something I do naturally. However, one thing that can help is to read a lot of the code. There was a time when I had read the source code to every published Elm package. Knowing what packages are made of can really help when suggesting which ones to recommend.

Tip 4 — if there isn’t already an example, make one

This idea is pretty simple. The best way to way to show someone how to achieve something is to share the code and describe what it does. If it’s small enough, just write it out from the top of your head. I find myself writing a lot of code just for examples.

If you find people asking about how to do something a lot, it’s important for you to have an example to refer to. If there isn’t one out there, write one yourself, with the description inlined in comments. It cuts down on the amount of repetition you do, and you can even encourage people to make PRs to help make your example solid.

You might even find yourself writing tooling to help solve those problems. Seeing and understanding the struggle users are facing can be fundamental in learning how to improve your ecosystem. A good example of that is json-to-elm, born out of frustration with decoders.

Tip 5— Know when to take a break

If you help people all day every day, it can start to get tiring. Explaining how concepts work, writing examples, keeping the peace. They are all activities that require a cool head. If you find yourself getting irritated or frustrated at questions, step away for a bit and go do something else. Sometimes, the best for the community is for you to not take part in a conversation with someone who you often go up against. It’s not an easy thing to step away, so ensure that you recruit a team around you to help answer more difficult questions, and deal with issues when you’re away. The team doesn’t need to be big, it just needs to be consistent and friendly.

I’d often end up answering questions in the middle of the night, or while out and about. While that’s helpful at the time, it’s no good to tire yourself out or to constantly be distracted. Disable notifications on your phone when you need to step away.

Tip 6 — Learn how to guide users to good questions

Once your community gets to a decent size, there’s no way you’ll be able to answer all the questions that come up. One simple trick I’ve used is to just guide users who don’t get answers to asking better questions. There’s a decent article on that here, but my general recommendation for Elm is to prompt users to explain what they are trying to do, and provide a code example. From there, you’ll usually find other people are able to take over. Your job isn’t always answer each question yourself, but rather to ensure that each question gets answered by someone.

Tip 7 — Repeat your advice often

In the land of Python, we have PEP20 (the Zen of Python) to help guide the way. PEP20 states some simple, single line guidelines that all Python developers aim to follow. Originally meant as a joke, it’s become a very handy reference over time. The fact that everyone knows them means it’s easy to refer to such guidelines. In Elm, we try to make these guidelines second nature. Whether it’s to do with how to structure data, or how to structure the app itself, it’s good to always sum up the help you just gave. For example, if you helped someone untangle a complex model, you might say “keep your model flat as possible”. The next person who comes along with the same problem might hear the same advice even before you reply.

Tip 8 — Be patient

People get stuck on all kinds of issues. There’s no need to rush on Slack to help people. If it’s taking a long time to explain to someone a particular issue, then someone else might jump in and take over from you. Let them when you get tired — you can chime back in with helpful side-notes, but trust the community to take care of itself. There’s rarely a need to lose your patience.

If it takes long enough to explain, it might be worth writing a blog post about. If you don’t have time to write blog posts (I often don’t), or are bad at them, then a great thing to do is to encourage other users to write blog posts. The more blog posts there are, the more examples there are. The next time that concept needs to be explained, you just need to give them the blog post with the side-notes.


Hopefully these tips are helpful! It’s a strange write-up to make, examining the processes and guidelines that you follow internally. I’d just like to finish with a big shout out to the Elm community. I’ve taken some screenshots of the people saying “awesome” in reference to you, since that’s what I believe you folks are!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.