
Visual Studio Live Share - benaadams
https://code.visualstudio.com/blogs/2017/11/15/live-share
======
lostintangent
PM on the Visual Studio Live Share team here. Thanks for posting! We're really
excited to hear folks thoughts about this experience, how it can help improve
their existing team collaboration workflows, and how we can continue to
improve/learn. So please sign up and/or let us know what you think :)

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.

~~~
colek42
Wow, this is awesome. While the use case outlined here is great I could
probably use this as a remote editor. That is, I can have my dev environment
running in the 'cloud' and still expect responsiveness from my editor!

~~~
lostintangent
Remote development is definitely an adjacent use case that we believe could be
really compelling. Thanks so much for providing the +1 on the scenario, and
stay tuned (i.e. sign up :)) for future updates!

~~~
colek42
Cool, I signed up for updates and left my use case in the comments.

edit: grammar

------
andr
Please, please make a headless mode for this! My ideal use case would be to
run this on a development VM and be able to connect to it with my VS Code and
debug live on the VM. This would be a much better experience than rsync-ing
your changes on every run.

~~~
pingec
Yes please, that would be awesome! I have a workstation that I rdp into from
all over the world in order to do development in VS and the experience is
terrible when I am on the other side of the world because of high latencies
and low bandwidth link. Being able to connect to the workstation's VS directly
and edit files + start debugging sessions remotely, that would be fantastic!

~~~
sorenjan
You probably have a good reason for doing this, but why do remote development
over rdp instead of developing locally and syncing with git?

------
bsaul
If a product manager from Apple is reading this :

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.

~~~
kosinus
They already have collaborative editing in their productivity apps, so they
may have already poked at the idea.

------
peterkelly
Am I the only one who finds it ironic that the development teams behind the
top two open source editors introduce support for collaborative editing on the
dame day, apparently unaware that they were both working on the same thing,
and there being no evidence of collaboration between the two?

~~~
recursive
What's the other one?

~~~
Maarius
Atom Teletype, discussion:
[https://news.ycombinator.com/item?id=15704730](https://news.ycombinator.com/item?id=15704730)

------
abdelhai
Atom announced "Teletype" today: [https://blog.atom.io/2017/11/15/code-
together-in-real-time-w...](https://blog.atom.io/2017/11/15/code-together-in-
real-time-with-teletype-for-atom.html)

~~~
frik
While Atom's Teletype works today. VSC Live Share is still unreleased
"vamporware" (a term coined by MSFT). The ripping of Atom, rebranding it as
VSC and doing a press release for such vital new feature is I guess pure
coincidence, and not a typical tactic they are known for, right?

Edit:

> That's just patently false.

Curious, how can it be patently false when "Visual Studio Code is based on
technology from Github’s Atom editor".

[https://thenextweb.com/apps/2015/04/30/microsofts-cross-
plat...](https://thenextweb.com/apps/2015/04/30/microsofts-cross-platform-
visual-studio-code-app-is-based-on-githubs-atom-editor/)

~~~
debaserab2
> Curious, how can it be patently false when "Visual Studio Code is based on
> technology from Github’s Atom editor".

That would be electron. Electron was originally made for Atom and is now being
used as a framework for many other desktop apps. All the guts and internals of
VSCode are completely different than Atom's.

------
alangpierce
The demo showed this as an alternative to screen sharing, but I could also see
this feature being really useful for pair programming and providing in-person
help. Even when I'm standing next to someone, it's nice for me to be able to
poke around in their code on my own laptop, especially if I can type in
examples of things I have in mind if I make a suggestion.

~~~
segmondy
My own opinion, but it's not pair programming if everyone doesn't have their
own keyboard and mouse. When I've practice pair programming, either I screen
share with screen/tmux where anyone can take over and type or if at the same
computer have multiple keyboards and mouse. Both programmers must be active.
With only 1 input we end up in a passive/active scenario, which is fine for
mentoring.

------
igloofoo
Privacy concerns: how is a public link more secure than a Skype screen share?

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.

~~~
jonwchu
We authenticate when people try to use the link. We are exploring ideas on how
to enable fine-grain permissions for sharing.

The link is an association between team members who are in a live share
session. The workspace (i.e. source files) is not stored in the cloud. During
a live share session, the communication is facilitated by an Azure Relay in
the cloud. We are also looking at the ability to have peer-to-peer
communication if you are on the same network.

------
adpirz
Pretty cool, but I wonder what the implications are for code privacy given
that this runs through Microsoft's servers. Will they also be collecting data
on the code being shared? Especially given the Kite debacle, think it's
important to be clear up front.

~~~
jonwchu
Hey there! Another PM on Visual Studio Live Share here. Security is absolutely
something we are designing for. Microsoft will not be collecting data on the
code. The code is not stored or uploaded in the cloud in any way. Rather, it
is just a connection that is established between you and the teammate you are
sharing with.

There's more details in the FAQ here:
[https://code.visualstudio.com/docs/supporting/live-share-
faq](https://code.visualstudio.com/docs/supporting/live-share-faq)

~~~
rightos
That FAQ seems fairly vague - what I'm looking for is simply how connections
are established - can I simply point the thing at another copy of VSCode
running in my LAN? Or do I have to involve Microsoft servers on the internet
for session setup? Is the connection directly between us or via an MS server?
What encryption is performed and where? Can a Microsoft employee or someone
who compromises them theorically gain access to my code simply by accessing my
coworkers account and connecting to my session?

~~~
chuxel
PM from MS here. Authentication and authorization is managed by a cloud
service but your code is not persisted in the cloud. The service optimizes for
the most high perf connection possible via an encrypted channel with the cloud
being one option. We intend to allow customers to lock down their invite links
as well as they so choose.

~~~
vvanders
First off, pretty cool stuff. MS is definitely killing it on the editor front
lately.

Going to throw in another +1 here for being able to self-host the connection
resolution. Without that I don't think I'll ever be able to make use of this.

I realize it's a large ask but if you're serious about driving adoption of
VSCode, MSVC and other MS tech I think that would be a huge boon to a lot of
your users.

------
twitchard
My team at the Node Knockout hackathon implemented an editor-agnostic version
of this feature literally last weekend.
[https://www.nodeknockout.com/entries/35-nodeist-
colony](https://www.nodeknockout.com/entries/35-nodeist-colony)

~~~
lostintangent
Nice work! This looks really awesome, and is another great example of the
passion around better collaboration tools for developers. Thanks for sharing
this.

With Live Share, we're also looking to extend the collaboration experience
beyond real-time editing, and into collaborative debugging, and more, as we
continue to learn from the ecosystem what is needed to continue improving team
cohesion, regardless of the app scenario/issue at hand.

------
kumarvvr
This really shows how seriously they are taking VSC. Very cool.

~~~
lostintangent
We're definitely very serious about Visual Studio Code :)

~~~
kumarvvr
Just saw the shared debug feature. Really really cool. Mind literally hit a
breakpoint.

~~~
lostintangent
That's great to hear! We definitely believe that collaborative debugging is a
critical component of being able to demonstrate/reproduce issues, as well as
validate changes made during a collaborative/pairing session. We look forward
to seeing how folks end up using it :)

------
dep_b
Screen sharing is such a drag using Skype. Everything goes slow as poop even
on the fastest of MacBooks. Yet for a lot of purposes doing a screen share is
super valuable. I imagine Live Share is much leaner much alike watching
somebody changing a Google Doc in front of your nose.

~~~
cjsuk
Personally I'd find it irritating, as I do with Google Docs.

This is a neat gimmick but I don't think it'll revolutionise anything or end
up being the status quo in the future.

~~~
dep_b
Well Google Docs still is less irritating than screensharing what you are
doing in Google Docs via Skype.

~~~
cjsuk
I'll give you that :)

------
jimnotgym
Were Microsoft and Github using some kind of collaboration tool? Calendar
syncing perhaps?

------
skc
This is absolutely fantastic because until you see it, you don't even realise
how much you actually need it.

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.

------
jacobr
How well do these tools generally handle poor latency?

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.

~~~
jonwchu
Since we are only sharing what is necessary for the collaboration, this is
significantly lighter-weight compared to screen sharing. Addressing latency is
absolutely a core principle of our design.

------
veidr
This looks really cool and I am looking forward to it, but I spent a little
too much time reading about it before realizing it won't be available[1] until
sometime in the middle of next year (with a private beta starting sometime in
Q1 of 2018).

[1]: [https://code.visualstudio.com/docs/supporting/live-share-
faq...](https://code.visualstudio.com/docs/supporting/live-share-faq#_what-is-
the-roadmap)

------
dotnetisnotdead
This could be super useful for code reviews. I wonder how well it works across
continents (I'm guessing fairly well).

~~~
lostintangent
Code reviews are definitely a scenario we believe can benefit from Live Share,
regardless which version control workflow your team is using (e.g. PRs, trunk-
based development). In addition to being able to quickly seek help, we want
Live Share to enable easily seeking and _providing_ feedback/advice, in a way
that makes code reviews something that happen frequently and more naturally
bi-directional (e.g. "Hey I have a suggestion about your PR, can I show your
something in a quick share session?").

------
Rovanion
So this is exactly like Saros for Eclipse?
[https://youtu.be/ISM83tLYQ-Q?t=76](https://youtu.be/ISM83tLYQ-Q?t=76)

~~~
chuxel
PM at Microsoft. Beyond co-editing, Live Share enables co-debugging which
allows you to track down problems that only happen on one machine in a low
latency environment and enable concurrent investigation of different variables
or stack points against the same running app. We've got more features in mind
to enable end-to-end development. It also follows a model that actually does
not require sync'ing at all which gets you up and running fast and improves
security.

------
figers
My team does this every day using other tools to share code we're writing in
VS Code against Azure, this just makes so much more sense! Can't wait to try
it!

------
forgotAgain
Just wondering if there are any plans to make this available to management for
viewing workers surreptitiously?

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

------
chrisper
Now, if you could work on making Visual Studio 64 bit, that would be nice.
(And no the weird reasons given like a decade ago don't make it).

------
swagtricker
This is pretty exciting. I've seen a number of failed attempts years ago to do
this sort of thing with the Eclipse IDE. As someone who does a lot of pair
programming (XP), this looks like a compelling way to support occasional
remote work for XP developers. I could easily see a team with a good cadence &
feature set to work on opting for "remote Fridays", "remote Wednesdays" or the
like with tooling like this. Looking forward to trying it out!

------
romanovcode
Very nice, super impressed about the fact that VS and VSCode can work together
like that.

------
lpcmacho
How about pricing?

------
faaq
Wow, this is amazing! <3

------
INTPnerd
I prefer to just do screen sharing with an audio conversation going to
maximize the learning and flexibility. Since I also like Sococo, I prefer to
just stick to that, since that is one of the features it provides. I will now
explain why.

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.

------
0xbear
Umm, looks like all those remote interview coding notebook companies are about
to go out of business.

------
SantiagoElf
Cool sounding feature, but in practice remote code sharing and working on the
same code is to extreme programming as 'phone sex' is to sex. :)

~~~
coldtea
Given that "extreme programming" is a meaningless buzzword, whereas the
developments shown sound actually useful, that's probably for the better.

------
throwawayf238
Super no thanks. There's too much risk in this work for bloaty, spying type
code to land in the editor because of this.

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

~~~
chuxel
PM at Microsoft. Thanks for the feedback - we're thinking hard about ways to
ensure that the changes that land in your code is only that which you expect.
Are there specific features that you'd need before you'd be comfortable using
something like this?

~~~
bousaid
Ah, a wonderful response. That’s for keeping your ears open on what customers
actually want.

