A Remote Developer Team

I’ve never met my teammates in person.

It’s an odd situation made possible by advances in telecommuting / remote work / distributed teams. Despite working with my fellow developers for a few months — at the time of writing — we’ve never had occasion to shake hands.

Some Background

All three of us began work at Pluralsight in offices with co-located teams. Through team changes and office closures, we found ourselves together on a distributed team stretching the full width of the continental United States. We now work from home full-time, and we’re slowly discovering how to do this effectively. Pluralsight does not have many remote development teams, but we are fortunate enough to be a part of one now.

Communication

Optimizing communication within and around the team is a high priority. Most of our communication throughout the day occurs via text chat on Slack. This includes asynchronous requests from folks outside of the team and chatter among team members. We augment text with video conference stand-ups — daily for developers, thrice per week for cross-functional members — to coordinate early in the day. We also utilize audio and video Slack calls when explaining, demonstrating, or discussing the topic would be easier to do synchronously. Synchronous communication is a special case, however, and not the default mode.

In my view, it’s important to ensure that as much communication as possible occurs in an open setting. Just as someone might wait for an entire team to sit at their co-located desks before making an announcement, we make careful use of Slack channels to ensure information is shared correctly. For my team, we have a few different forums:

• A public team channel, which the entire cross-functional team and key stakeholders are encouraged to join. This is a great place for progress updates and more formal posts. We also encourage outsiders to make contact with the team here.
• A private cross-functional team channel. Here we can be a little more frank in our discussions. In general, there’s a level of chatter in this channel which isn’t overwhelming to catch up on after a day away from the computer. We can feel comfortable that everyone will have a chance to read when we post team announcements.
• A private developer channel. A lot of developer chatter is confusing and layered in jargon. The product manager of the team and I have an agreement about this channel: we will keep crucial discussions about the team and our product in channels visible to the rest of the team. This channel is where the developers operate on a daily basis. We coordinate tasks and ask for help. Besides idle chatter, developers often post end-of-day updates about what they’ve completed and what’s next. Since we end our days at different times, these messages form a great starting point for work the next day.

With these channels in place, our direct messages between developers has died down to mostly “are you ready?” checks before initiating a Slack call. This inclination towards open communication is critical for making sure everyone is on the same page.

Pair Programming

In recent history, our tendency to pair program has ebbed and flowed. We pair often while onboarding and problem solving, and we pair less while doing routine tasks. For most of our pairing, Slack’s built-in screen sharing feature has been sufficient as long as each participant has a strong internet connection. We’ve used Discord, FaceTime, and Apple Message’s built-in screen sharing to augment the various bands of communication (voice, video, screen) when necessary. (Tip: don’t be afraid to call someone on the phone.)

Lately, however, Visual Studio Code has opened up preview access to their Live Share feature. Anecdotally, the experience has been amazing. In our sessions, the sharing has effectively handled large projects with multiple files changing at once. It has also shown resiliency when people make contemporaneous changes to a single file. I’ve come to appreciate some of the details, such as the marker in the gutter representing others’ cursors. It’s my hope that similar tools like Atom’s Teletype will catch up soon, to promote some healthy competition and innovation.

We have not formalized any rules for pairing (other teams have developer roles and timed rotations for typing, driving, etc.). Generally we trade off whose screen is shown depending on whether we are addressing a problem on an individual developer’s computer or working more generally. Although we can share the ability to control the screen with others on the call, we often don’t. Instead, Slack allows us to draw ephemerally on the screen. This is useful for pointing out what we mean, though referring to line numbers is an effective fallback when navigating through code. (Restricting the ability of senior developers to type also has the benefit of forcing more knowledge to transfer between developers. This addresses one of the potential drawbacks of pairing / mob programming.)

Code Reviews

For those times when we aren’t pairing, we use GitHub’s pull request and review features. We’ve recently added the (updated) GitHub integration to our Slack channel. We subscribe only to pulls and reviews notifications, which give us the following:

• Notification that a PR is open. This is the number one way we can see progress in real time. We use a quick emoji reaction to signal that one of us will review it.
• Notification that a review is complete. For those of us who keep GitHub’s email notifications super-glued in the “off” position, this means no more anxiously refreshing the PR page or looking at the notification icon.
• Notification when a PR has been merged. This is great for celebratory purposes.

These methods are fluid and expected to change with the projects we work on, the people we work with, and the ways we choose to work.

What’s Next

I’m excited to meet my teammates in the near future, because they are genuinely great people with whom I’m honored to work. In the meantime, however, we’ve been able to build a strong team using deliberate communication and the wide array of tools available. Based on my experience so far, I have no doubt that effective remote product teams are within reach.