Collaboration is critical for any successful development team. That's a fairly uncontroversial opinion, and definitely not novel. Whether you're mentoring someone, providing a code review, lending a helping hand with a difficult bug, or just doing regular pairing, it's important to encourage continuous knowledge transfer (in all directions!), and support a culture of shared ownership and team cohesion. That said, there are plenty of existing tools and processes to help developers collaborate, so why create yet another one?

When we set out to build Visual Studio Live Share, we learned that teams collaborate in very diverse ways, with unique and meaningful perspectives about how it works most effectively for them (e.g. frequency of collaboration, session duration, whether it happens ad-hoc vs. scheduled). We didn't intend to ask teams to change how they already work, but we were interested in complementing it. In particular, we discovered a few ways that developer collaboration could potentially become more enjoyable, and ultimately, more productive, regardless if your team is fully remote, partially distributed, or entirely co-located. Let's see what I mean!

Sharing context, not screens

As developers, we spend countless hours customizing our environment, tuning it to be more ergonomic and visually appealing. Everything from your OS preference, default shell, editor theme, keybindings, window layouts, and font size contribute to an experience that makes your workflow feel "just right". So the idea of sacrificing (or inflicting 😊) those personalizations, in order to do something as fundamental as collaboration, seems...kind of silly.

With Live Share, participants can collaboratively edit and debug a shared codebase in real-time, while retaining their individual machine setup (from either Visual Studio or Visual Studio Code). Prefer a light theme, while everyone else on your team favors dark? Great! Does your pair use Vim keybindings, and you'd...rather not? No problem! Do you prefer to align the file explorer on the right-side of your IDE, increase your font size, hide the status bar, render whitespace and/or display the minimap (among many other decisions)? Keep doing that! And let the rest of your team keep all of their preferences as well. Everybody wins 👍

This experience works because Live Share is simply synchronizing the project context (e.g. files, edits, debugging state, localhost servers) and user positions (e.g. cursor, highlights), while leaving everything else intact. Each “guest” in a collaboration session is leveraging the runtime environment of the developer who shared, but viewed through the lens of their own world. This may seem like a subtle win at first, but when collaboration happens daily or weekly, it quickly adds up.

Besides decoupling screens, Live Share also enables everyone in a session to have entirely different keyboard layouts, which is important for geo-distributed teams. So you could have developer’s collaborating, using a combination of QWERTZ, QWERTY and/or AZERTY keyboards, and everyone can edit freely, without any unexpected behavior. This works because everyone is actually editing locally (unlike screen sharing), which allows their keystrokes to be handled properly, before being synchronized with the group.

Another key benefit of the fact that edits happen locally, is that you won’t experience any of the latency associated with screen sharing. Since editing is the most latency-sensitive operation we perform, having collaboration tools that optimize for that is critical for both productivity and long-term satisfaction.

Collaborate together, but think different

Two (or more!) minds are often greater than one, because diverse perspectives can help break down problems more quickly, and produce better results (e.g. less “clever” abstractions). Collaborating via a shared screen/projector has the benefit of keeping everyone focused on the exact same thing (e.g. a method implementation), but it also has a potential downside: it limits participant's ability to explore independent ideas, without disrupting the entire group. Even if you're using a solution that supports multiple cursors, everyone is still fundamentally locked to the same screen, and therefore, limited in their ability to think on their own, or at their own pace.

With Live Share, participants are collaborating on a shared codebase and runtime environment, but are able to seamlessly transition between focusing on the exact same thing, and working independently. Furthermore, Live Share even supports a hybrid model, where you can temporarily edit separate files (or sections of the same file), while continuing to observe each other at the same time.

Whether you want to parallelize a task (e.g. you write a test and your pair writes the associated code), look at different stack frames while debugging, or simply peek the definition of a method you’re not familiar with, Live Share enables a form of collaboration that isn’t mentally serialized. You can choose whether to focus together, divide and conquer, or somewhere in between. The decision about which model works best is up to you and your team, and Live Share is simply there to enable it 👍

View this post for more details on multi-modal collaboration.

Code-centric communication

There are plenty of great chat tools out there, and Live Share was built to compliment whichever one(s) you and your team are already using. However, most of these tools were built to facilitate conference calls and presentations, not to enable efficient discussions about code. As a result, while they work great for keeping your entire organization in touch, they don't provide an experience that's optimized for distraction-free, developer "flow".

With Live Share, you can simply share your current workspace, and begin chatting with your guests using integrated text and voice support. There's no need to coordinate the use of a separate service, or context switch between different apps. Just remain in your editor and begin communicating and collaborating as neccessary!

Furthermore, while you're collaborating, it's likely that you or others will have questions about specific section of code. To make it easier to talk about code, Live Share allows you to click on any line in the shared project, and add a rich, Markdown-enabled comment to it. This way, you can communication effectively at all levels of detail, without needing to explain or re-create the context that your editor already provides.

View this post for more details on Live Share's integrated communication support.

Real-time editing, and beyond!

Developers often refer to Visual Studio Live Share as being like “Google Docs for Code”, which is understandable, since it provides a real-time collaborative editing experience, with shared cursors and highlights. However, in order to enable developer collaboration, that can scale from the simplest situations (e.g. a quick code review), to the most complex (e.g. group debugging a site incident), we found that we needed to support much more collaborative context than simply files and edits. We needed to enable collaboration that was truly end-to-end, and didn’t require developers to turn to another tool or service in order to progress a collaboration session forward.

With Live Share, developers start by sharing their entire project context (just click the Live Share button!). This gives participants access to the entire codebase, as opposed to needing to exchange code snippets back and forth (which is a painful way to collaborate!). From there, it enables you to share as much or as little as needed, in order to satisfy the requirements of your specific collaboration session. That way simple situations are simple, and complex situations are...simple as well. Humor me as I illustrate this via a parade of tweets:

• Need to debug through some code? Cool! Just press F5 and everyone will be automatically attached to a shared debugging session (that's running on the host's machine!).

• Need to illustrate a failing test or run a diagnostic command? Great! Open up a shared terminal, and everyone in the session will automatically see it.

• Do guests need to see a running web app in order to understand a bug or validate a fix? Simply share the localhost server on your machine, and everyone can immediately access it, using the secure SSH channel that Live Share already establishes.

• Want to do a code review, but in real-time? Guests can access the state of the Git repo, and if you're using the GitLens and/or GitHub Pull Request extensions, they are fully shared as well!

• Want to explain something visually? Check out the collaborative whiteboard and start drawing together.

• Want to provide a guided walkthrough of a codebase, using a pre-prepared "tour" (almost like a developer-optimized PowerPoint!)? Check out the CodeTour extension, and start sharing your knowledge!

• Want to make sure everyone you collaborate with gets proper Git attribution? Live Share will automatically generate your commit message trailers.

• Do you use the Pomodoro technique for time management, and want to continue using that while collaborating? The Live Share Pomodoro has you covered 👍

• Need to browse documentation together, such as looking up code samples, or following along with a tutorial? Grab the Browser Preview extension and begin collaboratively browsing together.

And that's only the tip of the iceberg. While Live Share comes with a bunch of functionality out of the box, it's also fully extensible, and has a growing ecosystem of extensions that are building on top of its collaborative platform (e.g. time tracking, shared test runners). We're constantly looking for new opportunities to engage the community, since that's the only way to to sustain a collaboration experience that accommodates the moving target that is "modern" development.

View this post for more details on Live Share's extensibility and ecosystem.

We’ve only just begun

So in summary: Visual Studio Live Share enables developers to collaborate in real-time, using their own personalized environments, working together and/or fully independently, all while being able to share the holistic set of project context (you can whiteboard for heaven's sake!). We've found that this combination of experiences can enable a pretty useful form a collaboration, and may actually mitigate some of the frustrations that some devs have with traditional tools and processes.

That said, we're only just getting started, and so we look forward to continuing to learn more about developer collaboration, and in particular, how we can contribute to making it a more enjoyable experience. Considering how critical collaboration is, that seems like a pretty worthy pursuit.