Scaling Team Collaboration
tldr; We made a pretty darn good React boilerplate that’s available here.
Still with me? Okay, well in that case I’d better tell you a bit about the project. Scaling really just means making your processes so repetitive and predictable that they can be automated by computers with minimal overhead. In order to help scale team collaboration to dozens of people working from around the world in a distributed team, you are forced to constantly think of ways to improve your processes.
This article talks about some of the approaches I have taken in the two open-source communities I run, Hacksmiths and Udacity Alumni, in an effort to effectively scale distributed team collaboration amongst software engineers of all backgrounds and disciplines.
Like any good engineer, I look for patterns in everything I do so that I can reflect on how to streamline and automate repetitive work. I often wake up in the morning and start my day by writing an automation script, while drinking my morning coffee. I find that in many ways, automation is at the core of any good software engineer and software engineering team.
When working with a distributed team, areas left not automated become exposed and can wreak havoc on your efficiency. You see people in the team hitting the same barriers over and over and the amount of time taken to address those areas adds up very quickly. In other words, automating even the most menial of tasks within a team environment pays off.
At the start of the Udacity Alumni collaborative project, the leadership team and I wanted a way to communicate to the rest of the team that we would be enforcing style guides, best practices and would be integrating test driven development right from the very start. In order to effectively automate teaching our collaborators to follow these best practices, we put together a number of open source tools and example projects.
One such strategy to offer automated feedback to collaborators was to integrate pre-commit hooks right into our starter projects. What this does is it automatically runs checks against style and linting tools to ensure that code submitted to our projects passes our benchmarks before it is allowed into the main repository. If a submission fails, we offer advice to the collaborator on how to fix it, linking to our wiki or to our Slack.
On top of this, our starter projects include generators that act as time-saving tools to generate files and code. Surreptitiously, these time saving tools also provide a means to promote testing and other best practices. They follow a proven organizational strategy, that we will refer to as the Feature First strategy, whereby your app consists of encapsulated components that represent a single feature.
For example, we suggest that all files related to a single feature be put into their own folder. Rather than the traditional approach of organizing files by file type, i.e. tests go in the test folder, controllers in the controllers folder, we promote encapsulating features within their own folder. Following this approach, your application is composed of well tested units that exist without being coupled to a larger architecture. We have found, unsurprisingly, that following this approach we can often times reuse much of our code in future projects. In fact, with the Front End team, we intend to release an open source React component library at a later time.
If you are working in a distributed team and are looking for ways to improve your workflow, I would highly recommend that you take a look at what we have done. As an example, the Scalable React Boilerplate project showcases many of the strategies we have taken to automate collaborative work with the Udacity Alumni and Hacksmiths communities. Along with the React project, we will be releasing several others to showcase these strategies in all of the domains we work in.
Please feel free to leave a comment if you have any questions, or get in touch if you enjoyed using our boilerplate!
