Introduction

In Part 1 of this series we touched on the evolution of IDE from a personal, standalone tool to a connected and networked hub of all things code. We explained how connecting your IDE to your teammates’ simplifies communication and collaboration with two specific use cases: Discussing code in general, and performing code reviews right in your IDE, eliminating the context switching and improving knowledge sharing.

In this post we will expand this to additional use cases and show how the Connected IDE is the most important step towards team collaboration in a world where we are all remote developers.

What is collaboration anyway?

There are many flavors of collaboration platforms and tools for developers, and many permutations through extensions. In the context of making your IDE more connected, we look for collaboration to enhance velocity and value for the team. In a post updated on November 24, 2019, Geoff Stevens writes about How to collaborate like a pro in VS Code. Since VS Code is today the most popular modern editor, we will focus on it as an example, but the analysis applies to much of the collaboration approach out there.

In the post, Geoff looks at a list of VS Code extensions that bring collaborative features into the editor. These include, among others:

• Microsoft’s own Live Share that “eliminates the friction of coding together by letting you collaboratively edit, debug, and fix code in real-time without leaving the comfort of your own VS Code setup,” according to Geoff. Live share is pair programming inside VS Code, and provides an experience that is reminiscent of screen-sharing, but specifically for developers.

• CodeStream, which “allows you to comment, ask questions, and have discussions across your codebase from within VS Code.” Note that CodeStream now also allows you to perform code reviews in your editor.

• The Jira extension for VS Code gives you the ability to “view, search, and filter issues in Jira inside VS Code.”

• GitHub Pull Requests that helps you review and manage GitHub pull requests right inside VS Code.

We believe that collaboration starts with communication between developers. Through that lens, only Live Share and CodeStream are actually delivering collaboration, while the GitHub and Jira extensions serve only to reduce friction for the individual developer by reducing context switching. We believe collaboration is a communication-first endeavor. The ability to view or reference other content inside my IDE makes it easier for me to collaborate with my team, but only in communicating am I actually explaining my intent and resolving conflicts, misunderstandings or misalignment. A communication-first approach drives velocity and code quality.

Code needs to be a first class object in communication

In order to reduce friction and simplify communication about code, the code itself needs to be a first class object in the communication exchange. In part 1 we discussed the difference between a Personal IDE and a Connected IDE approach to asking a question or performing a code review. Here we will present a couple of use cases that illustrate how a tool like CodeStream allows code to become a first class object because your IDE is now connected.

Suggesting an improvement

• Personal IDE: You come across some code that you believe could use some improvement. You don’t want to take this on as a project, nor do you want to change someone else’s code without communicating with the author. You copy and paste the code in question into Slack or MS Teams, explain the context (repo, file, line number, etc.), type the code you suggest replacing it with, and explain why you think it’s a better approach. Upon receiving your suggestion, the author needs to locate that code in their IDE, review your suggestion, get back to Slack, discuss it with you, copy and paste the final suggestion (if modified) into her editor and push it. If this happened once, perhaps the friction would be tolerable. But there is just as much friction the second time you have a suggestion, and a third.

• Connected IDE: You see code you believe could use some improvement. You make your suggested change in your IDE. Then you highlight the code block in question and add a comment in CodeStream such as, “is it safe to short-circuit the loop here? It would make this function much more performant”, like this:

When the author gets the notification, she can just do a diff in her IDE and apply the patch if she finds it useful, like this:

Connecting related code:

• Personal IDE: Let’s say you want to point out to your teammates that different parts of the code you are writing are related. Perhaps you want to indicate the part of a React component that isn’t interacting with your stylesheet in the way you would expect. You would choose a file, jira ticket, or slack thread to communicate this outside your IDE and assemble there the list of permalinks that point to those code blocks in the different files. Whenever you or anyone on your team wants to make a change, you would have to try to find that external resource with the permalinks.

• Connected IDE: If you want to connect different parts of the code and share that information with your team, you can just make a comment on one of the codeblocks and add the different ranges in other files and even other repos that are connected to that original range, like this:

The Connected IDE enables knowledge sharing

Coding Sans conducts a Development Trends Survey every year, and for the past two years the #1 challenge for developers is Sharing Knowledge. It’s very telling that the issue of knowledge sharing remains so challenging. The personal IDE, where each individual developer produces code remains an island detached from colleagues and teammates, so extra effort must be applied to share information about the code being produced. We already covered the fact that documentation is not common among development teams. The Connected IDE provides an opportunity to finally address knowledge sharing in an effective and ubiquitous way.