Visual Studio Live Share(code.visualstudio.com)
code.visualstudio.com
Visual Studio Live Share
https://code.visualstudio.com/blogs/2017/11/15/live-share
114 comments
Important question: if I have configured my editor with the one true way (VIM), and the remote has some dumb evil way setup (not VIM), are we able to be separately good and evil?
Absolutely! Live Share allows developers to quickly/easily collaborate with each other, while continuing to use their pre-configured editor, which includes themes, key maps, extensions, etc. This way, everyone can feel completely at home while working together.
Does this require full internet access or can this work peer-to-peer for developers working behind the firewall.
Full internet access required. From this comment: https://news.ycombinator.com/item?id=15705063
Authentication and authorization is managed by a cloud service
Authentication and authorization is managed by a cloud service
Wondering what will be the final pricing of this feature? It looks too good to be available for free for any VS/VSCode user.
Surely they're not incurring much costs with this feature if they're just using Microsoft servers for the initial WebRTC handshake? That's what Atom's recently announced Teletype feature does at least: https://blog.atom.io/2017/11/15/code-together-in-real-time-w...
This is incredibly not promising (in regards to pricing):
https://twitter.com/VisualStudio/status/930885113159802886
This looks pretty amazing. Question: if two people are sharing code and one of them hits "Build", whose machine builds the project?
Great question! The project would be built on the machine of the developer who initiated the Live Share session. That developer is effectively the "owner" of the session, and all developers who join the session are connecting their editor/IDE to theirs, and remoting certain editing/building/debugging operations. This allows the participants to fully collaborate, investigate/explore the project independently, but without incurring additional environment/setup requirements simply to get started.
We want the act of providing feedback/advice/etc. to each other to be as lightweight/frictionless as possible. Ideally, it would be so easy to collaborate, that it becomes harder for teams _not_ to do it :)
We want the act of providing feedback/advice/etc. to each other to be as lightweight/frictionless as possible. Ideally, it would be so easy to collaborate, that it becomes harder for teams _not_ to do it :)
[deleted]
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!
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!
Cool, I signed up for updates and left my use case in the comments.
edit: grammar
edit: grammar
Yes, I really want this too.
All the existing ways I know to do this (shared filesystem NFS/smb/sshfuse, or shared screen PCoIP/VNC/RDP, or remote file editors like BBEdit, TextMate+rmate, etc) are all terrible to use in practice.
All the existing ways I know to do this (shared filesystem NFS/smb/sshfuse, or shared screen PCoIP/VNC/RDP, or remote file editors like BBEdit, TextMate+rmate, etc) are all terrible to use in practice.
My primary use case would also be as a remote editor.
How open is this going to be? Will it be based on a protocol implementable by other editors, akin to the Language Server Protocol (https://github.com/Microsoft/language-server-protocol) ?
Question: What data will be sent to the Microsoft servers? Lots of companies have very strict policies, most of them dont want their source code in any way at third parties.
I read a comment by another PM on Reddit who said that everything is fully encrypted, but is sent to a remote server to negotiate the connection with the other user. They also said that they don't collect any private information/code.
Are you gonna have any sort of extensibility apis. Would love to build something like coderpad, which saves/plays history of edits.
I hope this is just a another open source vscode plugin so other developers can contribute. I don’t trust Microsoft enough to build a closed collaboration system. We all know how abusive they were with good ol’ MSN messenger.
I hope this is just a another open source vscode plugin so other developers can contribute. I don’t trust Microsoft enough to build a closed collaboration system. We all know how abusive they were with good ol’ MSN messenger.
It would have been even better to include at least some idea of the expected release time or availability of the preview. It's hard to believe there is so much detail on the feature set, a big website to promote this and nobody at Microsoft has any certainty when this might be out.
We will be releasing a private preview of the feature early in 2018.
You can sign up for it here: http://landinghub.visualstudio.com/vsliveshare
You can sign up for it here: http://landinghub.visualstudio.com/vsliveshare
Yes, I saw that but -
It doesn't mention a date.
It only says 'may'.
It asks for an email "For a Microsoft enabled work or school, personal Microsoft, or GitHub account", which is not particularly clear.
The form and data goes to some 'hubspot.com', rather than to Microsoft. It is default-blocked by ghostery as a tracker.
The feature looks really interesting, the promo site and the experience of using it is, to use the technical term, poopy.
It doesn't mention a date.
It only says 'may'.
It asks for an email "For a Microsoft enabled work or school, personal Microsoft, or GitHub account", which is not particularly clear.
The form and data goes to some 'hubspot.com', rather than to Microsoft. It is default-blocked by ghostery as a tracker.
The feature looks really interesting, the promo site and the experience of using it is, to use the technical term, poopy.
This seems super helpful when swarming compared to squeezing everyone on the team into one office. Will collaborators all be required to be running admin level accounts? That might be a problem in shops (mine!) where admin access is rarely granted to devs.
Awesome! Thanks for this feedback. Swarming is definitely a scenario we'd love to see Live Share help improve. And no, collaborators wouldn't need to be running admin level in order to participate in a sharing session. We want to make sure collaboration is as accessible/frictionless as possible for everyone :)
Does it use any external services to perform the sharing ? Can I run it on a vpn? What port does it use ?
[deleted]
Is it relaying the data over Microsoft (or Azure/Skype/etc) server? Or is it a point-to-point / peer-to-peer connection?
And if it relays the shared data over Microsoft server, what data beside currently opened source code files and keyboard + mouse inputs is transfered? Will it also transfer more source code files (e.g. whole VS project)?
I have to say this feature reminds me of the hollywood movie "Startup" (2001): http://www.imdb.com/title/tt0218817/
And if it relays the shared data over Microsoft server, what data beside currently opened source code files and keyboard + mouse inputs is transfered? Will it also transfer more source code files (e.g. whole VS project)?
I have to say this feature reminds me of the hollywood movie "Startup" (2001): http://www.imdb.com/title/tt0218817/
Yes, the data goes over an Azure relay, but we are investigating using a peer-to-peer communication for sharing as well.
We don't transfer all keyboard and mouse inputs. Instead, we communicate the data behind each collaboration activity (e.g. opening and editing source files, initiating debug sessions, stepping through code, etc.). We only transfer what is needed during the collaboration session.
We don't transfer all keyboard and mouse inputs. Instead, we communicate the data behind each collaboration activity (e.g. opening and editing source files, initiating debug sessions, stepping through code, etc.). We only transfer what is needed during the collaboration session.
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.
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!
You probably have a good reason for doing this, but why do remote development over rdp instead of developing locally and syncing with git?
TextMate + RMate works great for editing files on a remote linux box. https://github.com/textmate/rmate
This would be great for debugging apps on my Macbook or cloud MacOS machine, while still working on my main Windows machine!
You could use Xvfb even if it doesn't support headless mode :)
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.
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.
They already have collaborative editing in their productivity apps, so they may have already poked at the idea.
Haha. Agree. My xcode8 cannot remark line
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?
I'm curious to hear what you think of collaborative debugging that we also demonstrated with Live Share?
since when is atom a top open source editor? by what metric? notability on HN?
Do Google searches qualify as a metric?
https://www.google.com/search?q=open+source+text+editor&ie=u...
https://www.google.com/search?q=top+open+source+text+editors...
https://www.google.com/search?q=open+source+text+editor&ie=u...
https://www.google.com/search?q=top+open+source+text+editors...
What's the other one?
Atom Teletype, discussion:
https://news.ycombinator.com/item?id=15704730
Teletype for Atom.
https://teletype.atom.io/
https://teletype.atom.io/
Atom announced "Teletype" today: https://blog.atom.io/2017/11/15/code-together-in-real-time-w...
It's really exciting to see the energy being directed at improving developer collaboration!
Did the two teams collaborate to make the editors protocol-compatible?
Atom’s new Teletype protocol is open, so at minimum a Teletype-compatible plugin could be developed for VSCode.
Note - the Teletype plugin initiates the connection via GitHub’s servers, but then the rest of the communication is entirely peer-to-peer via WebRTC. (I hope LiveShare uses a similar approach...?)
Note - the Teletype plugin initiates the connection via GitHub’s servers, but then the rest of the communication is entirely peer-to-peer via WebRTC. (I hope LiveShare uses a similar approach...?)
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...
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...
> 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.
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.
How on earth is VS Code a 'ripping and rebranding of Atom'?
That's just patently false.
That's just patently false.
Regarding Teletype vs LiveShare, your statements aren’t fair based on what I’ve read. It appears the teams have been working in isolation. Also the MS team’s deadline was planned to coincide with the MS Connect conference. (Maybe Atom’s announcement was planned to coincide with QConSF?)
It's based on Electron, which used to be Atom Shell. You are conflating the editor Atom with its runtime.
Lots of stuff is built on Electron. (Desktop Slack, Discord, Atom, VS Code, Kitematic, GitHub Desktop, etc.) Electron is not an editor framework.
Your statements remain patently false.
Lots of stuff is built on Electron. (Desktop Slack, Discord, Atom, VS Code, Kitematic, GitHub Desktop, etc.) Electron is not an editor framework.
Your statements remain patently false.
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.
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.
Thanks for this feedback! We believe that Live Share's ability for developer's to work together in real-time, while choosing to "follow" each other, or temporarily/periodically investigate something independently (e.g. "Let me check out whether this helper function could work here"), will enable it to apply naturally to many collaboration scenarios (e.g. pairing, seeking help/advice, swarming, consulting, mentoring, etc.), without needing to impose any specific opinion on team workflow and/or the practices they've found to be efficient/successful for them.
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.
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.
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.
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.
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.
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
There's more details in the FAQ here: https://code.visualstudio.com/docs/supporting/live-share-faq
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?
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.
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.
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.
Good to hear, thanks!
Really? So Microsoft just provides name resolution, and the data goes peer-to-peer?
Or maybe this “connection” is actually going through your servers and we have to take your word for not peeking inside the packets?
Or maybe this “connection” is actually going through your servers and we have to take your word for not peeking inside the packets?
Seems pretty easy to verify where the traffic is going with Wireshark once it comes out. Given how easy it would be for anyone to check that (especially in a product targeted at developers, who are likely to know how to use network diagnostic tools), it seems rather pointless to lie about where the traffic goes.
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
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.
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.
This really shows how seriously they are taking VSC. Very cool.
We're definitely very serious about Visual Studio Code :)
Just saw the shared debug feature. Really really cool. Mind literally hit a breakpoint.
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 :)
Is there any plan on adding built in FTP capabilities?, I would love to get rid of my current IDE and use VSC but is a hassle changing the code there and uploading using some FTP client
Why not use one of the extensions?
https://marketplace.visualstudio.com/search?term=FTP&target=...
Any chance of talking the UE4 teams into requiring VSCode as a minimum instead of VS?
Me and my colleagues are going to play with Live Share ASAP.
Me and my colleagues are going to play with Live Share ASAP.
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.
PM at Microsoft here. Live Share not only allows you to collaborate in real time in a lower latency snappier environment but also enables you to seamlessly transition from watching to participating, editing, stepping, and inspecting. The difference is you can collaborate but still operate independently which is not possible with something like a screen share. Screen sharing is great when you want to show your entire desktop or show visuals. Live Share lets you add another tool into your tool chest to better enable concurrent collaboration.
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.
This is a neat gimmick but I don't think it'll revolutionise anything or end up being the status quo in the future.
I can see it being extremely useful for group projects in university settings...
Pair programming is okay with two people looking at one screen, but once you have more than two people, it really is just a drag. Of course, you can use git and contribute separately. But looking at the same version of the code seems tremendously useful.
Pair programming is okay with two people looking at one screen, but once you have more than two people, it really is just a drag. Of course, you can use git and contribute separately. But looking at the same version of the code seems tremendously useful.
When I was at university doing programming, we just sat three people to a machine.
Were Microsoft and Github using some kind of collaboration tool? Calendar syncing perhaps?
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.
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.
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.
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.
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.
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...
[1]: https://code.visualstudio.com/docs/supporting/live-share-faq...
This could be super useful for code reviews. I wonder how well it works across continents (I'm guessing fairly well).
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?").
Should work much better in theory! Screen sharing is really inefficient for this purpose.
So this is exactly like Saros for Eclipse? https://youtu.be/ISM83tLYQ-Q?t=76
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.
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!
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.
I would expect this to be an enterprise request almost immediately.
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).
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!
Very nice, super impressed about the fact that VS and VSCode can work together like that.
How about pricing?
Wow, this is amazing! <3
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.
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.
Umm, looks like all those remote interview coding notebook companies are about to go out of business.
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. :)
Given that "extreme programming" is a meaningless buzzword,
whereas the developments shown sound actually useful, that's probably for the better.
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.
I'm sure the team at Microsoft is super talented, but this seems like an awful product direction.
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?
Ah, a wonderful response. That’s for keeping your ears open on what customers actually want.
Strong second. I love visual studio, and visual studio code, but this particular feature would be extremely irritating. I'd also worry that it would promote awful development models like Pivotal's pair programming take on agile, which has always struck me as creepy and totalitarian.
But if you don't want to you don't enable it. You need to actively enable this feature in order for it to generate link with your code.
I don't see the problem there.
I don't see the problem there.
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.