At Mastodon C, a large percentage of our workforce is remote. There are plenty of good reasons why remote work is our preference, but it isn’t without its issues. This is especially true for people who haven’t done it before and often collaborate as part of their role. Most of the remote employees at MC are software engineers so we focused on improving this area first.

Plural programming

One of the most successful techniques we’ve adopted is plural programming. Terminology already exists to describe ‘engineers working together in a single context’. Pair programming, mob programming, swarming.

At MC we encourage engineers to work together as much as they can. Often this means in pairs, but sometimes, on larger projects, this can mean three or four. Working on a single problem, together, at the same time. This acts as a counter-balance to pitfalls often associated with remote work. Low bus factors, lack of knowledge dissemination, project silos, to name a few. Our experimentation has shown that this reduces the gross time spent on a problem or feature. In real terms this means less bugs, better quality code, greater team knowledge of the system as a whole. People also build better relationships with their peers and find them more approachable. This is important in a remote environment.

Tools

Good tools are an important factor in enabling plural programming. At MC, we have had success with the following tools and processes:

• Text chat with search - This is the backbone of a remote team, especially a software team. Document everything in chat, avoid out-of-band discussions and make sure you have the right channels (and people in them). Use it as a system of record for low-impact decisions and discussions. Slack is the front-runner in this space but HipChat or Discord are good alternatives.
• Video chat with screen sharing - When it comes to coding time, screen sharing is a must. We use Google Hangouts or Appear.in depending on the style of interaction. Standard operation is to have a single person ‘drive’. Everyone else is discussing the problem, contributing to the pool of ideas.
• An internal blog with search - Decisions with a wider impact are crystallised in an blog. Unlike text chat, where you need to know what you’re looking for, a blog presents information to those who need it. WordPress is a good fit but the options are many.

The theme across these tools is to prioritise transparency, sharing and collaboration. No developer is an island; no project is a silo. Using Clojure as a single language across all our projects and tools enables this even more.

Wrap-up

The number of engineers involved in solving a problem is not linear to the time it takes to solve. This is an important truth to grasp. Increasing engineers early means less time supporting that code throughout of the project. Also, in a remote environment, where involvement is more passive, the effect increases. We’ve found this has been working very well for us and made a real improvement. We’d love to hear about your experiences with working together remotely.