Well, the decision, like most things in Microsoft, wasn’t one person’s idea. Actually, a lot of people have been discussing scenarios like this for a while. If you look at the code heritage of VS Code, a lot of that was actually in our Monaco, with the online development environment, which Erich Gamma, who is our technical fellow who is overseeing the project… Our initial thing was really when we looked at it to say, “Hey, do we need to have a fully in-the-browser experience?” and that’s where actually Eric’s team in the very beginning started working through on that.

Our learning is that we actually have that, the Monaco editor embedded in a number of different scenarios. And what we learned is that developers really wanted a local, on their Mac or PC, on their own desktop kind of scenario… Which is really not surprising, because we have a lot of – Microsoft has 65,000 developers that are kind of coding every day.

And I remember we had this conversation – I remember Anders was there, and Eric was there, and a bunch of other people… And we were like, “Why don’t we just make a local editor, and we can experiment, we can see how the community thinks about it, whether there’s some catch-on or not…?” And we have, between Erich Gamma, who obviously was one of the key folks behind Eclipse back at IBM, and all of the VS folks, we have many, many decades of experience building IDE’s, so we know what are the key workflows and things like that, what are the thoughts, so we positioned it to be what we call a lightweight code optimize editor - that was the key positioning. And we were like “That is the area we’re really gonna focus on, and we’re gonna have a very flexible extension system, and the way we design extensions is going to be such that it can never interfere with some main editor experience, which is a core lesson that we have learned from both Eclipse and Visual Studio. I cannot necessarily say the same thing about the Visual Studio extension system, or the Eclipse extension system.

[ ] We have taken these lessons that we have collectively learned and applied it to the design of VS Code. Initially, we were like “Hey, let’s try it out, to see if it’s actually something that’s gonna resonate with the market, and to see if there’s actually a developer need.” What we learned is yes, there is one, and not to mention that it’s always great when our strategy of really serving all the developers married very well with identifying good pain points, and actually deliver a good solution. When those things come together, it’s just super powerful.