The Story of Visual Studio Code

What is it that you would like to talk about? What’s important to you? We talk to developers, we talk to the open source community…

Great, that’s my kind of people, because we are one of those very fluent in GitHub and open source people. I would love to talk about it, and the reason is, for example, I still feel people are judging us and looking at us with a very old lens. I was telling someone, I can remember it was three years ago at this very conference, in this very studio, where we announced we open sourced and made .NET open source and cross-platform.

Three years ago, yeah. We did a show on that… We did. And we were excited, too.

And our audience was like, “Wait, what?”

Yeah, exactly. But we’ve been those people that have felt the way you’re talking about, but see the new Microsoft.

Great, and I would love for you guys to help me get that word out, because I feel like there’s still so many people, even – it got better this year, but even two years ago, they were like “What? You mean .NET is open source? What? and that is cross-platform?” It’s complete news to them… So I’m trying to figure out all of the places these people are hiding, and how can we get the message out as broadly as possible.

Well, a lot of those people are listening to our podcast, so I think that’s a good thing. An interesting place that I think we could start - because… You know, according to Wikipedia, which - congratulations, you have a Wikipedia page. Is that you? It is you, unless there was somebody else…

I don’t know, I haven’t even looked.

Did you not know you have a Wikipedia page?

Someone mentioned that to me, but I never looked.

Okay. Well, I looked, and I found – were you born in Shanghai in 1970?

Yes, yes.

Okay, I figured it was you, because a lot of that information lined up. Live review…

\ and it even looks accurate[laughter]

Somebody from Julia’s family wrote this about her…

Maybe… That’s pretty cool, right?

That’s good, yeah. I have given many talks, and stuff; I usually do a little intro about my background before, so someone captured it, and it’s all accurate.

Okay, great.

That’s great, so this will be accurate then, because you graduated in 1991 with a bachelor’s degree in electrical and computer engineering from Washington, and you started working at Microsoft very soon after…

Right away, yeah.

So you’ve been with the company for like 26 years?

25 years.

25 years. So we’ve just been tracking this change, from the outside, maybe three, four years; we’ve seen the opening up of Microsoft, but you’ve seen it through many different phases, so maybe let’s start with you telling us a little bit of your history with the company, and then you can tell us this change that you’ve seen from the inside, and your perspective on it and how it all came about.

I would love to. As you mentioned, I joined Microsoft in February of ’92 as a developer working on Microsoft Access.

Nice!

That was before we shipped the first version of Microsoft Access.

And I learned about databases in college from a Microsoft Access; it was the first little database I learned about.

It is definitely the desktop database tool of that age, and even now I think there’s still a set of loyal users of the product.

I’m sure there are.

And I once started working on this other tool - I like to call it the worst name for a Microsoft product ever… It’s Visual InterDev.

Visual InterDev…

Do you remember that product?

No.

No, but I agree that’s not a very good name.

What the product did was it was our first web development tool; we shipped it in like ’96, ’97, and against ASP - not to be confused with ASP.NET, which shipped much later… We were being called “Visual Basic for the web”. So that was our first attempt at having a web development tool in the late ‘90’s.

What year was this?

I think we shipped the first version in late ’96, early ’97 or something.

That’s when the internet came out, basically…

[laughs] Not really…

’95 was actually when Bill Gates had The Internet Tidal Wave memo at Microsoft, so a lot of different teams were spun up, started being like “Hey, what should we about the internet?”

Right.

We did miss the internet, in my opinion.

You did miss it?

From a business model perspective we totally missed it. We didn’t create Amazon, we didn’t create Facebook, we didn’t create Google, and all of these internet business models, even though they all started their business from the Microsoft IE browser.

[08:10] Right, Internet Explorer. For a lot of people that WAS the internet.

I think we were the enablers; I think we enabled people to build these true internet companies, but we didn’t really–

Were you involved in IE?

I was peripherally involved with IE, because the HTML rendering engine was also what we used in Visual InterDev to help design HTML. So we collaborated with the IE team on those pieces, on those components.

So back then the mission statement wasn’t like a PC on every desk running Microsoft software, or something like that?

I think it was the… What was the thing? It was a Windows – like a PC on every single desktop, I think that was it… A PC on every single desktop.

Yeah.

And the inferred part was, you know running Windows.

Running Microsoft software, exactly.

I think that was inferred.

By saying PC, you’re assuming Microsoft.

Right, definitely implied.

I guess in a post “only Microsoft world”, that would make the pc.

Things change over time, but the mission statement back at that time was PC’s – I mean, it was all Windows… 98%, or whatever.

It was all Windows. But the thing – you asked me what changed… It is very important to realize that in a lot of the Microsoft internal engineering, everything in practices was very much aimed at that day and era.

If you think about even in the ‘97 – let’s just say ’97 kind of timeframe… ’97 also happened to be when we first had the first Visual Studio Product - when we took Visual Basic, Visual C++, Visual InterDev, Visual J++…

Lots of Visual things…

A lot of Visuals…

…and made that into Visual Studio, right? That’s why it was called Visual Studio back then…

Okay, because you were just putting all those together.

Right. So we launched the Visual Studio line 20 years ago, and this year is also the 20-year-birthday for Visual Studio…

And have you been on Visual Studio the entire time?

The entire time.

Wow.

And then if I think about what delivering software looked like back then, if you’re thinking back in ’97, ‘98, where would you go buy something like Visual Studio or Microsoft Office? You’d go to Egghead…

Yeah, or Best Buy.

Or Best Buy… I don’t even remember, were they at Best Buy?

In ‘97? I don’t know… I feel like there was.

Barely.

Barely, and you’d go buy a physical box, right? That’s why we called it “box offer.” And if you think about the engineering structure from Microsoft, we had a development team (which I was on) and we had a test team. Then we had a program management team. And the test team played a very important role back then, because their job was to prevent what we called “recall class bugs.” What is a recall class bug? It’s that the bug is so bad, the physical boxes have to come back to Microsoft; they’ve been shipped all over the world, and they have to come back to Microsoft and get rebuilt. That is a recall class bug.

That’s back when software quality mattered… [laughs]

Well, I think we have a different way to think about it, but that actually happened to us before, and you can imagine the cost…

Oh, man…

So whose head rolls when that happens? Does a head roll?

Julia’s…

I don’t know if the physical head rolls, but I always say that the… [laughter]

Hopefully a metaphorical head rolls… [laughter]

“Someone’s head must roll…!” You know, you hear that.

The test manager of the product feels very responsible if that happens…

Yeah, the bug stops there…

Because that is where the bug stopped.

And software development was so antiquated then, in comparison to today’s world…

Right, because the infrastructure wasn’t there. So you optimize for different things. At that time, if you had any questions or problems with your software, you would call Microsoft… There was no internet, right? ’97, ‘98… And you would call our product support people on the phone, try to describe your problem, and we’ll be like “Oh, we’re trying to help you sort it out” etc, but even if I figured out a little issue that I had, I don’t really have a way as Microsoft to give you a patch; there was just no such mechanism allowed or was really enabled.

[12:10] Right. The only way to get them something would be to mail that to them… Potentially.

Well, even with mail, you have – like, the installer doesn’t support a patch, the software doesn’t know how to patch, you need to have someone from IT to patch it for you… It’s super complicated.

A very technical problem to solve.

It sounds terrible.

Right. So the reason I think about that day and age is because that particular set of development practices was working well for us in that day and age, and it lasted for the next really 10-15 years, it kind of worked that way. Then it just didn’t work, because it’s kind of like the land phone to the cell phone transition… It’s like these big, huge internet transitions; that is no longer how you should ship software, and your customers’ expectations change, and the velocity changed. Because back then it took us three years to ship software, and that was okay, that was already fast enough.

They were even named by years.

They were named by years, and people liked to hold on to old software, where you tell them it’s not secure, like “Don’t run it, it’s terrible!”

And you had to charge for updates sometimes, large amounts for the update, because it’s such an expensive process.

It’s an expensive process, you have the entire development team… The business model back then was to sell you to the latest version etc. So now you kind of look back and say “Wow, that’s…” – that was great for Microsoft back in ’97, and the entire business and process, the engineering practices were designed for that day and age and that kind of infrastructure.

Fast forward, for us the transformation really started after we shipped Visual Studio 2012, which was five years ago. That version of Visual Studio is also interesting, because that was the version where we did not get to decide our own shipping schedule. Our schedule was tied with Windows 8.

Oh… So it was gonna ship no matter what.

It was a major release, because we had to do so much work to support Windows 8 development paradigm. That was a lot of calendars for our team to tackle. And after we come from shipping VS 2012, we’re looking ahead and a couple of things become very clear - we can no longer ship in three-year product cycles; we’re not going to survive if we ship three years, because the technology is changing so fast and so quickly. So we really started – we made a top-down decision that we were going to have quarterly updates, and that’s gonna have new capabilities and new features.

This is in 2012, this decision was made…

Yeah, so our first quarterly update was VS 2012 update 1, and it was a very traumatic thing for the team, because the entire engineering process was not set up to go do this. And I wanna give you a metaphor - imagine in old days people bought encyclopedias; they were beautifully bounded, A to Z, you buy the whole thing, you stuff your whole bookshelf. And what we were trying to do was like “Don’t buy the whole set. I just wanna go inside a chapter in this one book, or I wanna go rip a few pages out. I wanna go cross a word out and replace it with a different word.” What we wanted to do was incremental updates to the encyclopedia, versus the whole big encyclopedia, but our machinery only knows how to produce this whole big thing once every three years. That’s what the factory, our operationalization was designed for.

So it was a major transformation that we had to go through, and that transformation happened with every single major Microsoft product line, to say “Well, how do we really take that huge box software mentality and think about every piece of software we ship in Microsoft as a service, which you make incremental updates quickly, and you really observe and respond to customer feedback quickly?” That’s really the pursuit that we have been on.

[16:07] Interesting. So that transition seems to correlate with what we opened with, which is the opening up of the software as well… Because you could have changed all your machinery, but still shipped proprietary binaries… But you didn’t do that; you changed the machinery of the way you build the software to be incremental, but you also, it seems like one by one, or sometimes five by five, these different individual products, or .NET Core and then more of .NET, so on and so forth. You just opened up the software itself. Speak to that decision and how it played out.

Yeah, and that is another great question, because you’re exactly right - changing a software process doesn’t necessarily change the deliverable. And of course, that huge pivot we made is that Visual Studio was really, for a long time - and that’s the old meme we’re talking about - people think about it as a product that only runs on Windows, that only supports Microsoft platforms. That was true for many years. And the strategic pivot we actually decided on is that we want to – and it’s very much tied with the new Microsoft mission when Satya became CEO… We wanna empower every person, every organization to achieve more, and how that comes down to us in the developer division space is that we want to really empower every developer and every development team to achieve more.

If we’re only helping people running on Windows and targeting the Microsoft platform, that’s very far from every developer and every developer team. That’s when we started the pivot to the – I think that was the first slide we showed, and we’ve been showing that slide for the last three, four years, which is our “Any developer, any app, any platform.” That was a core strategic pivot we have made, and everything really ties with that strategic pivot in terms of “Well, how do we engage with all the developers out there and what does a meaningful engagement look like?”

This is when we started doing iOS and Android development, helping with the mobile side, and we look at what people really need in the cloud space, in the mobile space, and we take open.net cross-platform, and it’s become a fantastic way for our customers to share code, between their Unity gaming, to their cloud back-end, to their website, to their mobile apps… It’s just really the best programming language that can share common business logic, and today Miguel showed you how can take the core business logic written in C# and then embed that into your iOS and Android app.

That capability of us understanding developers’ needs and open sourcing our core framework capability, and really allow this breadth that has been super powerful for us. And then with that, not to mention we also started to develop Visual Studio Code.

That was exactly what we were gonna lead to next, because you now have this bifurcation of Visual Studio, where you have the established 20-year-old project that millions of people are using, but then brand new, open, greenfield new editor. That decision.

Yeah, so first of all, why we started to do that is that we realized that there are different types of developers. When you start talking to a lot of developers - a lot of different needs… And I always ask people, like “Do you use Microsoft Word?” Usually I get a nod. “Do you use OneNote?” I also get a nod. “Do you use Notepad?”, I again get a nod. Personally, I use all three. And I’m not really confused about when I’m gonna use each one. You can say they’re all for editing words, but I use them and a lot of different people use them for different scenarios.

The power of the IDE is that there’s a whole set of – it’s particularly powerful when you have very complex multi-step processes that will just simplify and automate it for you. That is actually one of the biggest powers of the IDE.

[20:03] Think about, for example, what we download on-stage in terms of mobile development. You’re developing a bunch of code, we’re compiling it, and then we’re actually patching that into the device or emulator, and then setting up the debugger with it, and we demo very similar scenarios for Docker’s development against our Azure Kubernetes Service (AKS), and from Visual Studio IDE’s. A simple, almost F5 gesture, and all of that workflow is done for you.

A lot of developers love them, but there are also developers for some scenarios, like “I don’t wanna use your workflow. I want to go construct my own workflow, so I just want the code editor to go do a thing for me, and I can go assemble my own workflow for me.” That also happens. So we’re like, “You know what? In that case, Visual Studio Code is great for you.” You define and you decide what your workflow is. It’s not going to package these things up for you, so you have the full freedom to go do and write whatever code you want to go write. And we provide this light IntelliSense to help you, we have this light capability of debugging to help you… So it’s not going to decide your workflow for you.

We see those two things as fundamental differences in how developers approach certain scenarios, so we think it’s very valuable that we provide both of those to enable those scenarios.

Well, Visual Studio Code has been on fire lately.

Yeah, it’s become cool, for some reason.

Everybody’s trying it, switching…

It had a bad name, or not so much a name generally, but it seems like more and more people talk about it, and not just talk about it but also use it and be like “This is the best for this, and this is the best for that”, and it’s scenarios where they have workflows, or it’s scenarios where they don’t really have workflows, and it’s kind of good for many.

One thing I always wonder with decisions like this coming out of a large corporation like Microsoft, where it’s this new direction, “We’re gonna continue with Visual Studio, we’re also gonna have Visual Studio Code…”, I wonder how that idea percolated, and then who championed it, and how it became – as vice-president of the Visual Studio section of Microsoft surely you know how did that idea come out. Did you think of it one day? Was it somebody on your team? Like, “Hey, let’s do VS Code alongside Visual Studio and run these things in parallel.”

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.

[24:19] 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.

Yeah, that’s gotta be exciting.

It is very exciting, and I think that as much as it’s great for developers, one of the key things we’re really hoping to show developers is that Microsoft is different. We can do marketing events all day long, but there’s power in people using an open source cross-platform Microsoft code editor called Visual Studio Code every day. One of the things we are hoping is that it will help developers worldwide see us in a new light.

Can you speak to that change? Maybe since it’s out there now, more and more people are using it, how has the feedback loop, so to speak, of you putting it out there, having this hypothesis that this will happen, and it does begin to happen.

I always say that as Microsoft people we think we have pretty good tech, but I think in the past we were more closed; now when we come in the open what we really didn’t know is whether the community will welcome us, or actually truly embrace… That was the question in our mind. There’s really not that much question that we’ll have great tech, that it will actually be a good product.

Once we put it on GitHub, we were just amazed by how many contributors are telling their logging issues, are working with us out there in the community, and Visual Studio Code, in GitHub’s latest ranking, we are number one in terms of contributors. We are almost double the next project, which is Facebook’s React Native, in terms of contributors. That’s just totally amazing.

There’s lots and lots of active discussions going on in the VS Code GitHub repos, and it completely changed the way our team works. Before we actually were engaging with the community, when the team was working internally before the launch, we’d work on a monthly sprint schedule for that particular team, and once we started to open source on GitHub, the community feedback came in and the team realized they need to go spend up to like 30%-40% of their time interacting with the community on GitHub, triaging issues, responding to requests and addressing any concerns. You have to be active in the community in order to have that kind of level of interaction.

One of the phrases I increasingly say is that we’re not only customer obsessed, which we are now, we’re also community obsessed, because we really view the community as an extension of our team. That is true for Visual Studio Code and that is also true for the .NET project we have, or Typescript, or all of these main GitHub repos that we actually drive.

Do you see the analogy of Microsoft Word would be your IDE, and then your Notepad would be your VS Code, and they serve different niches during context, right? Do you see that as lasting 5, 10 years down the road, them running in parallel, or do you see VS Code as eventually becoming the one true editor, as it usurps its established product?

[28:10] I think that one of the things we have learned in the last five years as well is that we used to do five-year planning - we no longer do that because the tech world changes so fast. Five years ago, can you imagine we’re here talking about these things, and talking about Kubernetes and containers?

It’s a different world.

It’s a different world, so I really–

That’s the best non-answer I’ve got in a long time… That’s a very good non-answer, because you’re right - the answer is “We don’t know. We don’t plan 5, 10 years out.”

We really don’t anymore.

“And if we do, then that plan is gonna–”

It’s irrelevant.

It’s irrelevant by the time the five years hits, because who knows what’s gonna happen next year?

It’s just a bad guess. [laughter] Or a good guess.

It could be good, we don’t know. [laughter]

You know, if I’m gonna bet on it, anything I guess right now is gonna be wrong. It’s just gonna be wrong. If you go back, think back in 2012 - can you imagine the world… Not just about what happened to Microsoft, but can you imagine all the technology advances that we’re seeing today, what’s going on with AI, what’s going on with machine learning, what’s going on with containers…? You just talk about technical advances, but like, no, I absolutely could not. So whatever I guess, will be wrong, that much I know, if I look five years out.

I personally think the best way for us to really keep going forward is to have a very tight engagement loop, constantly hear our customers’ feedback, understand in the new world what are the new pain points our customers are experiencing, and continue to provide value to our customers. That’s really quickly, right? That’s actually the way to kind of keep moving forward with the industry. We’re creating new technologies, other companies are creating new technologies, the entire industry is moving up very fast, and we just have to keep going with that flow.

You’ve been there from the beginning…

I have been, yeah…

Well, take us to the beginning then.

…before VS Code was VS Code.

There was a previous name?

Well, it was called Digital Studio Online Monaco.

Windows Online Monaco…

No, Visual Studio Online “Monaco”.

Okay.

I’ll take you back to the very beginning. It started out with an experiment to see if we could build an HTML and JavaScript-based code editor that we hosted in the browser.

What year was this?

Six years ago, so…

I think Chrome at that time just came up with the notion of web workers, so being able to run processes which then enabled us to be able to do things like have IntelliSense, and errors and things like that. Erich Gamma had basically started on that project - that was his first project at Microsoft - and built that up. We needed somebody to dogfood the editor, so…

The correct term is “champagne the editor.”

Champagning, is that what it is now?

Yeah, you don’t say dogfood anymore.

Think how weird is saying “eat our own dogfood.” Really? How about this - we drink our own champagne.

It implies good stuff, no matter what.

Just think about it, maybe try it on for size.

I’m gonna have to work it through a couple times… But I like it. So we champagned the editor by building a little bit of a workbench around the editor that we could then develop the editor with. So it was a little bit explorer, and editor, and… Source code control I think we built in there. But it really was done as a little Node server that ran locally on the machine… So you HTTP whatever, and you get this little workbench up, full access to all your files for the editor, and we build the editor and champagne the editor at the same time.

So we built out this editor which actually was pretty popular across Microsoft. Like, if you go to OneDrive and you look at source code, that’s the editor; Azure, any place you go in there and look at source code, that’s the Monaco editor. It’s the same editor that’s in VS Code itself.

If you go to Edge browser and maybe 12 those in Windows and look at source code, that’s the Monaco editor. It’s a bunch of other places… So that got pretty popular. And as we did it, we built more and more of this workbench around the editor. We had this locally hosted development environment, which since it was running on Node and it was an HTML and JavaScript thing, it could easily be moved up to the cloud.

So we kind of looked at it like “What’s the next step from a code editor?” Like, well, we wanna develop a fuller web-based app. The Azure website and it started to come online, so what we decided to do was say “Hey, can we host this workbench in Azure, so that you can do live editing of your websites straight in the portal?” They said, “Yeah, let’s do that”, so we brought that up online. It was fairly easy, because of the whole architecture. We branded that with our name, Visual Studio “Monaco”. So that’s where it originated from.

And it started. Okay.

This is 2001.

No, ’11.

In 2011 we started the editor, and probably it was 2013…

I know it wasn’t around 2001…

The Space Odyssey… [laughter]

So probably 2012-2013 when we did Visual Studio Online. That was an interesting project. The thing that was difficult about it was that… It did really enable a bunch of developers to do anything, because you had – there were so many things that you had to do before you got there, right? You had to have a subscription, you had to have a website, you had to have this, that… Pull up the magic, whatever, and then you could use this online hosted tool.

But it was pretty cool, and there was a big wave of online hosted tooling that was going on around that time, like Cloud9… I can’t remember all the…

Ace?

Ace was the editor that Cloud9 used…

Cloud9 was a service–

That’s right.

Well, Cloud9 may have used Ace, but there was two of them - Code Mirror and Ace. Those were the two editors, and then Monaco was the third one.

Okay. I do recall that time period. Those things were never that sticky from a user’s perspective.

No.

In the browser, you mean.

Yeah.

Browser-based tools were never really –

It was a big sell. It was like, you know… notebook IDE in the cloud.

Office had a suite of tools that actually work in the browser fairly well; there were a lot of things you could do, and it seemed like a natural progression… Like, you’ve got a desktop application, which would have been Visual Studio, and then you’ve got browser-based tools. But you’re right, the challenge with those was that – there were a bunch of challenges… The biggest one that we saw was that it was great, you got your development tool in the browser, but all your other tools are on your machine, so there’s no connection between the code that you’re working on in the browser and “Oh, I need to run this other tool at the same time” - how do you bridge that gap?

So it was an all-in scenario - you had to either go all-in cloud.

Exactly, and people aren’t all-in on the cloud for developer tools…

Or anything.

Developer tools.

There’s latency, there’s…

Network interruptions…

It requires an internet connection…

Yeah, you can’t work offline…

object browse.

There are cool aspects to it, right? The idea where you could go and just spin up an environment instantly and not have to provision anything on your machine - that’s a cool aspect of it.

It’s great for educational means; I used to teach web development, and it’s like we just spin up in a browser, and there’s no pre-recs, it doesn’t matter what operating system you’re on… But when it came time for me to actually write code, I’m not gonna use that.

Yeah, from an educational scenario where you’ve got this box that you’re working in, it works great.

So then what we decided to do – it was kind of popular, but we decided “Well, let’s try to do…” What we saw was we were actually getting a lot of people that were coming from non-Windows machines using it… Like, “There’s an audience out there that we could go and talk to that we–” Today, with the suite of tools, which was Visual Studio at the time, we had nothing that we could go and say “Hey, you cool guy using a Mac, sitting at Starbucks, working on your web app… If I’m from Microsoft, I can’t talk to you. I have nothing.” I have to say “Close your Mac, get rid of your operating system, get rid of your tools…”

It’s two worlds.

Yeah.

At that point you’re like “I’m just drinking my coffee, man…”

[39:51] Yeah, “Get out. Get out of my face.” [laughter] So we decided to pivot and see if we could do a local client based tool. Again, since we had this Node infrastructure and everything, we moved it over to – what was it called before it was Electron? There was Electron, before that it was called Atom Shell, but then there was the…

Before Atom Shell?

Before Atom Shell there was another tool that let you host Node apps on the desktop. So yeah, so that was kind of the genesis of the whole thing. But then once we had that tool, we could say “Alright, actually we have something to talk to people about”, and we decided that – we couldn’t just come up with yet another editor… Like, okay, there’s Sublime, there’s Notepad++, there’s Atom - a bunch of code editors out there. We had to do something different, so what we decided to do is we called it “Redefining what the code editor should be in the modern world, for the modern developer”, and that was really about great editing experiences out of the box, and great debugging experiences out of the box.

Visual Studio has always had this sort of strong debugging lineage, right? It’s like “Hey, what’s the best debugger?”, a lot of people will say “Visual Studio.” So what we wanna do is kind of take the best of that, the best of editing, bring that to the code editor space and basically create our own place where we could say “You know what, we’ve got a tool that you can use. It’s gonna be a better editing experience, you’re gonna get debugging, but it fits in with the rest of the stuff you’re doing. You don’t have to drop everything and come over to our stuff. Try it out. If it works for you - great. If it doesn’t - try again in six months when we bridge a few more features.”

So that was kind of the genesis of it, and really that’s the way it progressed. We had people kick the tires from it right away, and they used it for a short amount of time, said “Hey, it’s missing XYZ, ABC and it’s not open source. Maybe we’ll check in with you again in the future”, so we just cranked away at it; we had this whole good backlog of things to do… And we still do it today. Every month, a very public roadmap and all this stuff. We’re just constantly churning out required feature after required feature, so that people can actually just pick it up and use it. And it’s been fairly successful.

What would be the tentpole features, for somebody who’s – so as we said, our audience and the people in our community are very interested in it, people are trying it, it’s won over a lot of people; we both downloaded it, we both used it… I’m still stuck on Sublime for reasons that I will talk to maybe offline - or maybe I’ll do it online.

Yeah, you can talk about that online, I’m happy to–

But I’ve very impressed, and everybody is very impressed. What are the selling points to, say, a Vim user or an Atom user; I know these are all very different users, but… And PJ, maybe this is a good place for you to hop in. One aspect, it seems - it seems like there’s a “batteries included” to it in terms of the setup experience, but what do you guys consider when you’re like “Okay, here’s what VS Code has going for it right out of the box today?” What are its advantages that would compel somebody to switch, or even just try it?

Well, like Chris said, really strong editing and debugging experiences. Out of the box support for Node, JavaScript, Typescript - that primarily is a function of that’s the language that VS code itself is written in, but expanding it to other languages, like Python, like Java’s recent one, Go - you’ve spoken with Ramya in the past… But that debugging experience that a lot of Visual Studio users have known and are somewhat used to - we’ve been able to bring that to this VS Code package that can be delivered on any operating system.

I think also a big component of it is honestly the openness and transparency of the VS Code team with the community. I think a number of people that have been converts from other tools have been because they’ve been able to interact with members of the VS Code team on GitHub, through issues or pull requests, or even over Twitter.

[44:08] I think something that the team prides themself of quite a bit is how open and how engaged they are with the community of not just developers that use VS Code, but developers that use other tools.

Yeah, I’ll echo… To me, it’s editing and debugging. So like, you say you’re a JavaScript guy and you’re using Sublime; probably you have a bunch of packages that you’ve figured out that you kind of like, and recommended from other people… It may or may not provide you sort of a completion experience for plain old JavaScript, right?

Yeah.

So you open up a VS Code, you’ve got a folder, you open it up, express you’ll get statement completion, IntelliSense, overloads, all sorts of stuff about the express object, without having to do anything. What will happen is, since we use TypeScript as the language server for JavaScript, it does a whole bunch of work for us, and analyzes the JavaScript, but it also goes and actually downloads those Typescript definition files. Basically, people write Typescript files which define - or almost type - the shape of regular, old JavaScript libraries.

Yeah. That’s the coolest thing I learned today… To be clear, you don’t have to be writing Typescript yourself; you’re writing your regular JavaScript, but in the background, what do you say - it’s the language server?

Yeah, do you want me to explain what that is, the language server?

Go ahead.

So basically what happens is you’ve got your presentation of the source code, right? And we use TextMate grammar to syntax colorize - it’s kind of standard across all editors. But when you wanna do IntelliSense or object browse so you kind of need a language server which will effectively offer up an AST and send that back over to VS Code. So there’s a whole spectrum of support for languages and extensions for VS Code, and the ones that are the best, like JavaScript or Typescript or Python or Go, all have this language server that runs basically in another process. It’s usually written in the language that it’s running in, which is cool, right? Because you can do Python; you probably have Python on your machine… But it’s smart enough to give you all that semantic information about your source file. So for JavaScript we use the Typescript compiler. We just spin that thing up, because it basically runs as JavaScript.

Right.

And it’s smart enough, it gives you the whole completions, everything that you need - errors, warnings - but as far as you’re concerned as a JavaScript guy, who cares?

It’s seamless to you get all the benefits of Typescript.

Yeah, you get a good amount… And more and more come online every month with Typescript.

But I think there’s two components there. One is bringing the Typescript to writing JavaScript in VS Code is what gives you the ability to write var x = some string, then when you call x dot, you get string completions, not just every completion that it could possibly be because it’s JavaScript and you’re not sure.

Right, it’s all there.

But where some of the Typescript definitions come in is understanding of Node, understanding of Angular… So it’s sort of going the next step in, you know, why we say IntelliSense necessarily, instead of autocomplete.

Yeah, there’s thousands of Typescript definition files for all the popular JavaScript packages that are out there.

The other thing I wanted to note on this point was – I just forgot what it was. It’s forgotten. Sorry.

Let’s focus in on the debugging aspects. When I think about IDE’s and text editors, I think of like…

Oh, wait, can I go back to what I remembered?

No. I’m just kidding, go ahead. [laughter]

So the other thing about Typescript and JavaScript - you can do sort of like a single file, bar x = some string and parts but with Typescript it works actually cross-file. All the files and folders in your workspace you can sort of just say “Here’s the universe of things”, so then I get completions against things that are in other files.

[48:20] As long as they’re in the same project or folder…

Yeah, and you can even go so far as put a JSON file in the folder to say “Here’s what my workspace looks like. Here’s my project. Include these files, exclude these files. This is how I want the compiler to run against it”, and you configure it quite a bit. But by default it just happens.

Sorry. If I didn’t jump in there, I would have lost my mind.

No problem. Now, what was I talking about?

Debugging.

Debugging - I look at text editors and IDE’s very differently, because I don’t expect debugging from a text editor; they usually have limited debugging, so I don’t have – I’m used to a command line debugger. I’m more of what I call a puts debugger, or a trace debugger, which is the person who’s putting the print statements in… So I’m not a good developer. We find out there’s lots of us, you know–

We had this conversation.

Yeah, I can’t remember… We had this conversation–

Firefox. Not Firefox, but Mozilla Debugger.

Yeah, the debugger inside the Firefox DevTools project.

That’s right.

That being said, I watch other people do some debugging, I see the value, I see the stuff that you demo-ed today, and that’s what I’d like you to go into… Give us the real juicy – because for me it has to be like a killer feature for me to be like “Alright, I’m gonna start using this AND the debugger”, in my life where I’m ingrained to just throw some console logs and see what happens. Talk to us about the debugger inside VS Code and some of the stuff you show with like the live share debugging – this craziness that I think people would be interested to try, even if they’re not debugger people.

Yeah, so I should say console.log is just fine… Everybody does it, right?

Oh, yeah.

The biggest thing for me when debugging – so once you press F5, the debugger spins up… The biggest thing for me is that it’s easy to set a breakpoint. I don’t have to plow through oodles of console.log output to figure out where it is that something is happening… Like, okay, this is the general area, hit a breakpoint, and then I get an immediate window that comes up, a repl, and I can come and evaluate expressions right there… So I can start to understand what X is, what Y is, and figure out where they are.

Inspecting values is that much faster; you don’t have to litter your code with console.log’s, you don’t have to take it out, you don’t have to deal with all the output that happens. Still, at time, console.log is a very useful thing, so I’m not saying that it completely replaces it. And of course, you get call stack, you get watch windows, and all sort of goodness…

I think all of those extra things – so I should preface it with I do do just trace statements, but I’ll often use what I call a weak debugger; it’s like a pry tool. In Ruby there’s a gem call Pry… It’s a “stop the world” type of a thing, and it gives you the repl, but it doesn’t provide the call stack… You can dig in for those things, but you’re not seeing frames here, and you don’t have a list of locals; there’s just less chrome around it…

Well, we try to strike this balance between the power of the debugger and what we present in the UI, so it’s not everything…

It would be overwhelming.

Yeah, so it’s not overwhelming; we try to not be overwhelming in VS Code. We actually try to make it so that people that write debuggers can actually contribute things back to the explore on the left-hand side… So for like a particular language, if there’s something that’s really useful for that language, they can contribute, but everybody is not then bombarded with that UI. We try to make it pluggable for the debuggers.

[52:03] The shared debugging we showed today was actually really cool, because – I mean, the scenario is really like “Hey, can you come over here and look at this? Help me debug this thing”, and you basically sit there and you’re both like “step-step-step-step.” But if you’re in another room, another place, to be able to let you do it–

It’s not a person this is not screen sharing.

It is not screen sharing. It’s sharing of the debug session, and the data, and the breakpoints, and the instruction pointer, call stack - everything.

The whole workspace. So it’s not just one file, it’s not just what’s active in your window right now, it’s the whole workspace that you currently have.

Collaborative on the same session, or what–

Yes, collaborative in the same editing and debug session, which is really cool. And it really struck me… Like, there’s always this time when you have a feature that comes online and you’re like “Okay, I get it”, or like “Oh, I can no longer live without that”, and quite honestly, two weeks ago we were preparing for these demos, and there was another – like, the team that does the live share was getting their part done, and we were bringing the two things together for the demo… And I was running into a problem with the Docker extension that I demo-ed today, and it was pretty deep in the bowels of VS Code where the exception was getting thrown. I was sort of in a panic and I’m like “Hey, can somebody help me debug this?”

One of the guys - we have teams in Switzerland, and one of the guys said “Hey, I’ll stay on the phone call with you and we’ll debug the process, we’ll debug it after we finish this other meeting”, and I’m like “Cool.” So then I screen-share with him, and he’s like “Okay, put a breakpoint here.” He was like, “Oh, wait! You closed that file. Open that file back up again. Okay, now step… Step, step over… No, step into that one. Alright, let’s restart –”, like it was just this whole him guiding me on what to do…

Right, plus the latency over the ocean…

And the latency, and it was just a huge pain. And then as we started to build up the scenario and stuff, I just kept thinking “If only Alex and I had this two weeks ago, it would have been a game changer.” That was to me the moment where I went like “Oh my god, I get it.”

I kind of feel like shared editing is a little bit of a – you know, how often are you two gonna write the same code together, in the same file…?

Well, there’s a lot of people that practice pair programming. In that case I think it makes a lot of sense, but I agree that in many cases it seems like a good marketing thing to say “It’s live, collaborative editing!” and it’s like, we’ve all done that with docs, but is the real value there with code?

I think with pair programmers probably it is, but with lots of other stuff…

But for the debugging was the thing that really got me!

And it totally sold you.

Yeah, right then and there. I was like, “Okay, got it. This is it.” That’s the thing that was really cool, I think, about the live share thing - the fact that it’s the workspace, and literally, there is no node on that other machine. And as part of this demo we actually went through this whole process where we were debugging the web app running in a Docker container on my machine, because you can basically attach to a running Docker container, set breakpoints and debug the code that’s in there.

It’s like Inception.

It’s like next-level stuff.

Yeah.

Because the other person on the other side, all they need is the editor. They’re connecting to your session, so they don’t have dependencies, they don’t need any of that stuff.

Or VS Code. They don’t need to have VS Code. Amanda had Visual Studio 2017, so Chris was going from VS Code on a Mac to Visual Studio on a PC.

[55:56] So what does that session data look like on the wires? It has to be a normalized format that at least those tools can use it. Is it a thing that you could publish a spec and people could plug it in? So I could be using Sublime and you could be using VS Code, and because we both – you know, whoever wrote the Sublime side of it, wrote to that format, they can get the session data… Is that a potential thing?

I think it’s definitely a potential thing. I don’t know if it’s in the roadmap or where it is in the roadmap, but if you think about it, it makes sense. It’s kind of like – we talked a little bit about language servers earlier… We actually have this nice protocol, it’s called the Language Server Protocol, that we made open source in a public area thing, which basically means that any editor or IDE can use the language server and plug into the environment. So you can use Sublime with Typescript and get a pretty rich editing experience, because it goes to the Language Server Protocol.

So you can imagine in this model that there’s a protocol that’s running over the wire so one editor can connect to another editor, or IDE, or whatever it is… And that can be something that’s open sourced and all editors take advantage of, and there’s basically a plugin for each editor. But I don’t think we’re far enough down the road yet to say “Okay, here, we’ve got this protocol. Everybody go build!”

Sure. You just demo-ed the feature for the – or was it the first demo?

It was the first time, yeah.

Yeah, so it’s brand new stuff.

But the model makes sense. It is definitely – it’s a protocol. It’s funny to see sort of the big circle of life - we were talking about this earlier, about recycling names… Like, a lot of stuff in VS Code is STDIN and STDOUT, right? Just piping, and it works really well, so you can do the same thing with these as well.

Nothing new under the sun… Just new names.

That’s right.

Let’s talk about the roadmap a little bit… We’ve seen what you’ve been up to. First of all, are there any major features that are just clearly still lacking, that somebody says “Well, I can’t switch because of feature X”, and you guys are all like, “Yeah, we know. That’s coming.” Are there any of those, and if not, what else is–

Well, the biggest one that we just shipped literally last week was multi-workspace support. Up until now, if you wanted to open up two folders at the same time, you’d have two instances of VS Code. What we now support is the ability to have multiple top-level folders open at the same time, language servers work against them properly. We’ve been working on that for six months probably… It was a lot, a lot of work…

It’s been in the Insider for a few months now.

Yeah, so the Insider has had it for a while, and really in the last milestone we kind of held off releasing it in stable, because we wanted to do a push to make sure that the top extensions that are out there were all multi-root aware. There’s sort of this very root API that had an assumption about the fact that there was one workspace, and everybody used that… So we had to make sure that people were supporting the fact that you could have multiple roots.

Like the old singleton design principle problem… “There’s only ever gonna be one of these”, and then six months later you’re like “It’d be great if there was two of those.” [laughter] Or N of those, right?

So that has clearly been the biggest one that people have been asking us for, and there’s a long tale of things that people are looking for. The other thing we just released was the ability to have the horizontal pane that’s at the bottom of the debugger (debug console terminal) - we put that to be vertical in this space. So if you’ve got a widescreen monitor, you can have your console on the right, the code in the middle, and the explorer is on the left.

You see a lot of feature requests for people stemming about wanting to have more control over the editors, the layout of the editors inside the environment, so I wanted to be able to split it horizontally or vertically at the same time. Those are things that we’ll start to – now that we’re sort of out of the multi-root workspace push, which was a lot of people across the team… In the short-term, really for the upcoming month, month and a half left in the calendar year, it’s really just a push on performance and bug fixing, and not like a whole slew of new features.

[01:00:18.12] We’ve published our roadmap on GitHub and our wiki, so you can go up there and there’s just a whole slew of things; I have to think off the top of my head what’s in there.

Well, if it’s published, we don’t need to talk about it. Click the link in the show notes…

No, but that’s one of the things that we try to do - every 6-12 months we put together a 12-18 month roadmap, we publish that on the wiki, and then for each milestone we go through a whole planning process. We publish that, we make it real, and we turn it from draft into like “This is the plan”, and then at the end of each milestone we publish our endgame, like schedule and process and testing and all that stuff, so everything is completely out there in the open.

And a lot of these elements… I don’t think the roadmap, but the iteration plans and things like that - not only are they visible and readable, but you can comment on them and react to them… It’s good, because we get real-time feedback just as we post the plan.

What’s the larger motivation of this project? You mentioned earlier, and I think we kind of talked a bit about it with Julia, about any app or any developer, any – what’s the mission? Remind me the–

Please remind us of Microsoft’s mission…

For VS Code?

Just Microsoft’s mission in general…

Any developer, any app, any platform.

Yes, so given that, what’s the motivation for VS Code? You mentioned… Back to the original scenario - Jerod’s in Starbucks, he’s cool, he’s on a Mac, and you have nothing to offer him… [laughter] You’re mostly cool.

And he’s using an editor right?

What’s the motivation? What is the mission statement behind VS Code? Why this editor, why are you guys doing this? What’s the larger picture?

Well, I think the larger picture is like, the world is no longer a place where you can say “We’ve got this thing, this great thing… Come to us and use it, and you’ll be happy.” People are like “Nah, I’ve got all these other tools and things that I’m using.” And I’ve kind of mentioned this before, like, we didn’t have anything for this whole class of developers - not on Windows, not using IDE’s, very sort of modern, webby, Node-oriented developers, JavaScript and all that… We had nothing to talk to you about. There was no way to have that conversation. You were a developer we were never gonna be able to attract, at all. So the motivation for VS Code was to break down that barrier and say “Actually, you know what? We do have something that you could use.” Then we give that to you, and if you like it, cool. Maybe there’s some other stuff from us that you’ll use at some point in the future. And if you don’t like it, at least we had a conversation, and maybe in six months you’ll hear about it from your buddy… “Oh yeah, I heard about it. Let me go look at it again”, and maybe at that point there’s enough stuff for you to sort of come on board.

But the days where you could say “Here’s our developer ecosystem. Come to our ecosystem, drop everything else you’re doing” - that’s over, and Microsoft can’t survive in that model, so we really had to turn around and say “Well, we’ve got tools for everybody. We’ve got great tools, we have a history of having awesome tools, and by virtue of using our tools, perhaps you will also use these other things that we have.” Azure.

And is it to attract essentially things to the brand name of Microsoft that they are no longer sidized - you’ve used the term before. Kind of getting that respect back that may have not been there from every developer out there.

[01:04:04.15] If you looked at it and just said “Oh, the goal is to get people to do Azure” - I think that’s not the entire story, because that can’t be your only goal. Your other goal has to be, I believe, an excellent player in the developer ecosystem, and that requires you to do things like “Be open source, be transparent. You’re a valid person in the ecosystem”, because if not, developers don’t like you. You can’t have one without the other, I think. You can’t just say, “Alright, we’re on the ecosystem, but we’re closed” and then “We want you to use Azure.” No, you have to be a viable member of that ecosystem in order to be even considered, so we have to do both of those things.

I think our mission for the past couple of years, seriously, has been - the first part - go break down all those old barriers that Microsoft put up for all these developers out there that just aren’t on our stuff. Just go make people happy. Literally, what Scott’s directive when we first did this - he just said “I don’t want you to worry about anything else. Just go get your first x thousand people, make them happy developers.” That’s empowering.

That’s an interesting mission.

It’s funny to me, because when we talk about open source and motivations and stuff like that, it’s not money - you know, there’s other reasons people do open source, but a lot of them boils down, whether it’s a big company like Microsoft, or Adam Stacoviak… Like, we just want people to like us. [laughs] It boils down to…

“Be my friend.”

Yeah. “Do you guys like us?”

Yeah.

I mean, think about it… I do cool open source, people value it, they benefit from it, and they’ll like me. I mean, it’s a very kind of base motivation, but we all kind of share it, even though we have our other reasons as well. It’s just interesting.

You’ve gotta be a good citizen, right?

Yeah.

That’s the truth.

Nobody likes a bad citizen.

Well, you have a bright spot on you if you’re not.

A bright spot, or a shadow?

Either/or, pick your metaphor, but the point I’m saying is you stand out. If you’re not a good citizen, you stand out.

I think you’re almost ignored.

Your ignored.

Microsoft was at a point where a vast majority – I don’t know if it was a vast majority, but a large majority of developers were like “Just… Irrelevant. Doesn’t matter.”

Yeah, “Doesn’t speak my language.”

So you had to break that down. That has been our mission.

How is that going? Is that happening?

I think so.

So you said that Scott gave you that mission, go make people happy, go make developers happy… How did you track that? How do you even measure that? How have you measured that?

There’s a bunch of ways we look at it…

Downloads probably is an impacter, right?

Downloads is a bit of a vanity metric, because you can download it all you want, but if you don’t use it, it doesn’t matter.

Okay so other types.

We look at engaged usage of it…

Do you have analytics on usage?

We do.

Is that an opt-out for everything?

What’s that?

Like, you can opt out of that during the download?

We often get that question, if you’re tracking analytics essentially of usage…

Yes, you can opt out of it, definitely.

Okay.

So we look at that, we watch Twitter quite a bit, because you have a very sort of instant pulse to what’s going on. We look at NPS scores - a standardized score, I guess Facebook came up with it; I don’t know a whole bunch about the history of it, but it’s basically your ratio to promoters versus detractors, basically a quick survey.

The promoter score…

If you have enough promoter score, yeah.

How likely are you to delete…?

Yeah, there’s a lot of people that do that, but it turns out to be a very effective…

I think it’s effective because it’s a single question, one through ten. You just click and you’re done.

[01:08:02.28] Yeah. And a lot of the middle are actually thrown out. It’s really only people at the high end and the low end that you’re actually kind of–

6+?

All you care about is the haters and the lovers.

Yeah, because those are the ones that actually have the impact on other people.

They have a multiplicative effect.

Yeah, yeah. And we look at sentiment that comes in through issues… What else do we look at?

In our blog post that we published for this event, we shared that in November, monthly active users - so people who used the tool once that month - 2.6 million, I think was the number.

Yeah, that’s a pretty decent number.

That’s a good number. And that’s like during the month of November…

Yeah.

How many people are on the team?

So there are about 25…? I could go through all the names, and I could count them all. It was like ten in Zurich and 12(ish) in…

I really throw the hard balls at him.

There you go.

25(ish)?

So the problem is this - if I get the number wrong, because there are so few people on the team, I’m really cutting a person off.

Somebody’s gonna know exactly…

It was like “It was 300”, “Okay, yes, 302”, it doesn’t really matter, but there’s like 22.

Everyone’s like “Chris forgot about ME!”

Yeah, yeah. And if I say eleven, it’s like “No, there’s one person less.” It’s roughly that.

I’ll take rough numbers…

And I’m also thinking about the Slack channel that we have, because there’s extra people in the Slack channel, which are not on the core team.

Well, the reason I ask that is because then I wanted to measure that next to the community contributors, and just see how much it’s been embraced from a contribution perspective, because like you said, a good community member of the open source – even though it’s a product, so there’s product roadmap and vision… Like you said, the roadmap is published and commentable, are there other people outside of Microsoft that are contributing? Have you gotten that going and how does that play back into the editor?

Yeah, I can’t remember the numbers off the top of my head, maybe you know them, but we are one of the top projects on GitHub…

So every year GitHub releases sort of like a rapport that is kind of like their state of the union, I guess, where they share a couple of metrics… One of the metrics was open source projects ranked by contributors. VS Code was number one, so we had the most contributors of any repo on GitHub.

Wow.

The link is also in the blog post that you posted, so we can – I don’t remember the URL off the top of my head, but yeah…

You can send us that…

And there was a couple other ones on there, and there was also a number of contributions and things like that… But yeah, I think in short the question “How much does the community contribute to the growth and improvements in VS Code?”, it’s a lot.

If you look at the release notes, every milestone we actually list out all the people that did pull requests that we were able to pull in in that milestone… It’s in the tens and twenties every month.

What do you think you’ve done that has enabled that? What are you doing well that other projects that aim to have your mission can learn from you?

429 contributors…

How many?

429 on the VS Code repo. There may be other repos as well…

Yeah, the report lists a different number. I don’t know exactly how they calculate the difference, but…

It’s still a good number–

And there was one which was of all Microsoft projects we were number one, and then there was another one which was all of GitHub. I think we’re the number one Microsoft project, I’m not sure if we’re number one overall.

That would make more sense. Or 5,000 forks, which is a good number. You have 94 open pull requests, 500+ open issues… Very active. 2,259 closed pull requests, so there’s a good metric there.

Yeah.

94 open may sound like a lot open, but when you have 2,200 closed, you’re making your way through them. Anyways, back to Adam’s question…

Sorry, what was the question again?

What have you done to enable this kind of contribution?

[01:12:07.28] I think there’s a bunch of things, there’s not just one. I think the things that we’ve done right are the transparency in our planning; putting that out there, letting people comment on it and seeing what the roadmap is I think had been very useful in that.

I was just talking to another guy earlier - PJ and I were… The fact that we sort of recognize folks that are actually contributing to the project has been a huge motivator for people. It’s almost like GitHub commits, where you’re like “Hey, it’s my resume.” People take this huge pride in being recognized the fact that they contributed to the project, and we’re excited about it and we say “Hey, thank you!” and then people are like “Hey, my pull request got in.” So there’s a lot of that that goes on.

I think there’s also – right from the get-go we kind of published, like “Here’s the guidelines about how to contribute to the product, and what we’re trying to do” and all that stuff. I think when people ask us questions, we’re honest… Like “Hey, why are you doing this? Why isn’t this open source, or that open source?” or license, or questions like that… Like, “This is what we did, and here’s why”, and people appreciate that honesty. When we screw up, we admit it; we go out and say “Yeah. We had an orange icon. People didn’t like the orange icon.”

Yeah, there was controversy around the icon recently.

A little bit, a little bit.

But the point is that you’re listening–

They changed it.

Yeah.

We respond…

You’re open, you’re transparent, you respond, you care…

Yeah.

You’re quick to change when change is required.

Yeah. And it’s not a free for all, though, right? It’s not just like a rudderless project, it’s like “This is what we’re doing and this is where we’re going.”

Right.

We’ll take feedback and everything in.

In less than a minute, what’s one call-to-action for those listening? What’s a good first step? Download it, play with it, check out issues…? What’s a good call-to-action for those out there listening?

Go download the Insiders builds. Get those Insiders builds, they’re great.

Tell us about that, because our community is very much – we’re enthusiasts, we’re hackers, and so…

Edge.

This is some sort of nightly build, right?

It is our nightly build. Like I was saying this morning, this is the exact same build that we use to build VS Code.

Insiders build.

Insiders build. It comes out every night, Zurich time…

Where do you go for that?

On the download page there’s a big green button to download VS Code, and there’s an arrow next to it. If you click on the arrow, it will show you both stable and Insiders. It’ll update every morning, and basically you just kind of get in this rhythm of “Okay, I’m just gonna update.” It takes a couple seconds, and boom, you’re ready to go.

Brand new features every morning, brand new bugs sometimes every morning… [laughs]

[01:14:47.11] Brand new bugs, brand new bug fixes, too. But if you think about it, since we’re using it to go build VS Code… Any big blocker we usually hit, and we’re not afraid to go pull the trigger and re-release an Insiders build that people blocked by it So a) I would go and do that. b) Go look at how to contribute, which is in the wiki. Look at the iteration plans… I know we’ve got one or two. And then I would go and do a query for – I think it’s “needs help” or “help wanted” in the repo, where you can see places where you can start to kick the tires.

The cool thing about it - it’s really easy to use VS Code to build VS Code, and we have full instructions on how to do that. So you can run VS Code, you can develop it at the same time, you can hit a breakpoint and debug it from VS Code. So an easy way to get started there.

Cool.

Very cool.

And learn about Typescript too, because it’s mostly in Typescript. It will change your life.

It’ll change your life. Alright, well thank you so much for your time today, guys.

Yeah, no problem. It was fun.

Thanks.

Thank you.