Visual Studio Live Share

We've heard pretty loud and clear that developers want better collaboration tools, without needing to switch editors, without needing to continuously negotiate control (i.e. look at the exact same thing), and without sacrificing the context/fidelity they would normally get while developing locally (e.g. full auto-completion/navigation, debugging). We think Visual Studio Live Share helps teams get there, and as it evolves, can hopefully become a powerful tool for teams to collaborate, not only more efficiently, but more naturally.

Additionally, we’ve found that successful collaboration needs to include more than just the project’s source files, and real-time edits, which is why we’re excited to also support collaborative debugging (even between Visual Studio and Visual Studio Code!). We’re only just getting started, and look forward to great developer feedback from the community.

Please, I beg you, do NOT try to replicate this feature. Get back to fixing the critical bugs and slowdown of the os, xcode and swift toolchains.

And what exactly gets associated to the link? Is it a tunnel straight into my computer? Is it pushing my VS workspace somewhere?

More details please. This seems more appropriate for getting help on small, isolated code snippets rather than collaborating on a project.

I desperately need something like this especially when I'm working with junior devs. I'm usually pretty busy so I often ask them to get the debugger to break at just the point where they are having an issue before I walk over to their desks and take over.

This would be heaven sent.

I often work remotely over 3G/4G. Voice is fine, as is simple screen sharing of stuff like Trello boards in a meeting. I tried Slack's screen collaboration and it was hardly usable though.

[1]: https://code.visualstudio.com/docs/supporting/live-share-faq...

I would expect this to be an enterprise request almost immediately.

I disagree with what was said in the video about how there are many reasons you don't want to share your entire screen. With a little care, it is actually reverse, there are many things you are missing out on if you are not sharing your entire screen. I will explain this more in a moment. I also disagree that both people being able to edit the code is a good thing. I will explain more about that in a moment. Admittedly there are situations where you actually want to control the other person's computer, but you can't have both the benefits of being able to control their computer and the benefits of not being able to, so I prefer to not be able to.

On screen sharing. The reason I prefer to share my entire screen is basically this is more flexible. There inevitably ends up being other windows and programs that have some relevant information I want to show them. It might be a web browser or something else. Prior to sharing my screen I reduce the number of monitors I'm using to 2, and I increase my font size for my editor and browser.

On computer control. I recently read an article about strong style pairing. It really resonated with me because it reminded me of something I either read or heard, can't remember which, about the current recommended way of doing mob programming. I think the main benefit is it maximizes learning. The concept is the same for both types of collaborative programming, but for some reason I never considered that it could also work with pair programming as well. Basically, you have your driver and your mapper. The driver is the one with their hands at the keyboard and mouse. The mapper is the one who tells them what to do. The mapper explains what to do at the highest level of abstraction that they both understand, and they increase the level of detail as necessary if the driver does not understand them. The driver is supposed to trust their mapper. This takes a lot of discipline to work this way, but if you are just doing screen sharing, you really don't have a choice, which makes it easier to force yourself to stick to this.

Here are the advantages of strong style pairing. It allows the mapper to keep their head on the bigger picture, while simultaneously still being the one who is really in control. Traditionally the driver would be in control, and this would free up the mapper to think on a higher level. But then it is easy for the mapper to get distracted, and there is always this nagging feeling it is not really worth having two people at the same computer. In this way, the driver is like a human interface the mapper can use to control the computer. It is as if they can talk to the computer and tell it what to do! By not having to focus on actually making the edits, they are able to plan ahead and keep more of the plan in their head. This allows them to always be ready to give the driver the next instruction as soon as the driver executes their previous one. Since the mapper is in control, they need to know how to do what they want to do. Therefore the editor and language that the driver will use, is the one the mapper wants to use. This is great because the driver can quickly pick up new editors, IDEs, and languages fairly quickly, just by driving with an expert mapper for a few days. For the same reason this makes strong style pairing work great when you want to pair experts with people at a lower skill level, which might be more frustrating otherwise. In that case, the expert is normally the driver. If the driver really has an idea they want to try out, you would switch roles for a time rather than the driver taking control.

I'm sure the team at Microsoft is super talented, but this seems like an awful product direction.