How we create and manage a ReasonML Code Style Guide at Avo in a democratic and open way
There are particularly two challenges that are relevant to any development project, that become more apparent your programming language isn't mainstream:
a) Onboarding new people into the project
b) Maintaining code quality
Neither of those challenges are new. They are relevant to any programming language, but given the nature of ReasonML, building tools to address them becomes crucial for the effectiveness of the product development.
How Avo built a democratic approach to our code style
Here’s how we approach it at Avo. In our first attempt at defining a code style the project was already a few years old and we were 4 developers.
We started out making a list of issues we face daily in the codebase. It was a collaborative document, everyone could submit there. Next, we discussed it at our developer roundtable. It's a meeting we hold every 3 weeks where all developers discuss matters related to engineering.
One of the topics on that particular roundtable was our code style. We spent an hour going through the list of suggested ideas and ended the roundtable with an actionable - one of our engineers would make a subset of the discussed topics that everyone agrees on that would become the first iteration of our official Code Style Guide. The Avo ReasonML Style Guide was born. It felt great to have a code style. On the other hand it was small and definitely incomplete, that’s why we labeled it v0.1. We had to iterate and improve, so we designed a process for that.
We use Asana to manage topics to discuss in our developer roundtable, and we have an ongoing topic for code style contenders. There anyone can suggest a new rule for the code style. Then all the contenders are discussed at the meeting and the items we agree on go into the code style. We really like this approach because it democratizes our code style and brings all new issues to the attention of all developers, so everyone knows the latest state!
Today we open our code style to the public, you can find it in this GitHub repo. Please share your ideas of new items to add to the guide in the issues section!
Next up for you
How to Reduce Back-and-Forth with Data Teams in Developer Workflows
Spending hours going back and forth with your data team and fellow developers probably isn't how you want to spend your day. But, too often, the feedback cycle around analytics feels like a snake eating its own tail. The good news is developers can help stop the chaos. Here's how.