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...
Julia Liuson: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.
Adam Stacoviak:Three years ago, yeah. We did a show on that... We did. And we were excited, too.
Jerod Santo:And our audience was like, "Wait, what?"
Adam Stacoviak:Yeah, exactly. But we've been those people that have felt the way you're talking about, but see the new Microsoft.
Julia Liuson: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.
Jerod Santo: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...
Julia Liuson:I don't know, I haven't even looked.
Jerod Santo:Did you not know you have a Wikipedia page?
Julia Liuson:Someone mentioned that to me, but I never looked.
Jerod Santo:Okay. Well, I looked, and I found -- were you born in Shanghai in 1970?
Julia Liuson:Yes, yes.
Jerod Santo:Okay, I figured it was you, because a lot of that information lined up. Live review...
Julia Liuson:\ and it even looks accurate\[laughter\]
Adam Stacoviak:Somebody from Julia's family wrote this about her...
Jerod Santo:Maybe... That's pretty cool, right?
Julia Liuson: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.
Adam Stacoviak:Okay, great.
Jerod Santo: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...
Julia Liuson:Right away, yeah.
Jerod Santo:So you've been with the company for like 26 years?
Julia Liuson:25 years.
Jerod Santo: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.
Julia Liuson:I would love to. As you mentioned, I joined Microsoft in February of '92 as a developer working on Microsoft Access.
Jerod Santo:Nice!
Julia Liuson:That was before we shipped the first version of Microsoft Access.
Jerod Santo:And I learned about databases in college from a Microsoft Access; it was the first little database I learned about.
Julia Liuson: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.
Jerod Santo:I'm sure there are.
Julia Liuson: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.
Jerod Santo:Visual InterDev...
Julia Liuson:Do you remember that product?
Adam Stacoviak:No.
Jerod Santo:No, but I agree that's not a very good name.
Julia Liuson: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.
Adam Stacoviak:What year was this?
Julia Liuson:I think we shipped the first version in late '96, early '97 or something.
Adam Stacoviak:That's when the internet came out, basically...
Jerod Santo:\[laughs\] Not really...
Julia Liuson:'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?"
Jerod Santo:Right.
Julia Liuson:We did miss the internet, in my opinion.
Jerod Santo:You did miss it?
Julia Liuson: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.
Jerod Santo:\[08:10\] Right, Internet Explorer. For a lot of people that WAS the internet.
Julia Liuson:I think we were the enablers; I think we enabled people to build these true internet companies, but we didn't really--
Adam Stacoviak:Were you involved in IE?
Julia Liuson: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.
Jerod Santo:So back then the mission statement wasn't like a PC on every desk running Microsoft software, or something like that?
Julia Liuson: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.
Jerod Santo:Yeah.
Julia Liuson:And the inferred part was, you know running Windows.
Jerod Santo:Running Microsoft software, exactly.
Julia Liuson:I think that was inferred.
Adam Stacoviak:By saying PC, you're assuming Microsoft.
Jerod Santo:Right, definitely implied.
Adam Stacoviak:I guess in a post "only Microsoft world", that would make the pc.
Jerod Santo:Things change over time, but the mission statement back at that time was PC's -- I mean, it was all Windows... 98%, or whatever.
Julia Liuson: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++...
Jerod Santo:Lots of Visual things...
Adam Stacoviak:A lot of Visuals...
Julia Liuson:...and made that into Visual Studio, right? That's why it was called Visual Studio back then...
Jerod Santo:Okay, because you were just putting all those together.
Julia Liuson:Right. So we launched the Visual Studio line 20 years ago, and this year is also the 20-year-birthday for Visual Studio...
Jerod Santo:And have you been on Visual Studio the entire time?
Julia Liuson:The entire time.
Jerod Santo:Wow.
Julia Liuson: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...
Jerod Santo:Yeah, or Best Buy.
Julia Liuson:Or Best Buy... I don't even remember, were they at Best Buy?
Jerod Santo:In '97? I don't know... I feel like there was.
Adam Stacoviak:Barely.
Julia Liuson: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.
Jerod Santo:That's back when software quality mattered... \[laughs\]
Julia Liuson: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...
Jerod Santo:Oh, man...
Adam Stacoviak:So whose head rolls when that happens? Does a head roll?
Jerod Santo:Julia's...
Julia Liuson:I don't know if the physical head rolls, but I always say that the... \[laughter\]
Jerod Santo:Hopefully a metaphorical head rolls... \[laughter\]
Adam Stacoviak:"Someone's head must roll...!" You know, you hear that.
Julia Liuson:The test manager of the product feels very responsible if that happens...
Jerod Santo:Yeah, the bug stops there...
Julia Liuson:Because that is where the bug stopped.
Adam Stacoviak:And software development was so antiquated then, in comparison to today's world...
Julia Liuson: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.
Adam Stacoviak:\[12:10\] Right. The only way to get them something would be to mail that to them... Potentially.
Julia Liuson: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.
Adam Stacoviak:A very technical problem to solve.
Jerod Santo:It sounds terrible.
Julia Liuson: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.
Adam Stacoviak:They were even named by years.
Julia Liuson: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!"
Adam Stacoviak:And you had to charge for updates sometimes, large amounts for the update, because it's such an expensive process.
Julia Liuson: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.
Jerod Santo:Oh... So it was gonna ship no matter what.
Julia Liuson: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.
Adam Stacoviak:This is in 2012, this decision was made...
Julia Liuson: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.
Jerod Santo:\[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.
Julia Liuson: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.
Jerod Santo: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.
Julia Liuson: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.
Jerod Santo:Well, Visual Studio Code has been on fire lately.
Adam Stacoviak:Yeah, it's become cool, for some reason.
Jerod Santo:Everybody's trying it, switching...
Adam Stacoviak: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.
Jerod Santo: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."
Julia Liuson: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.
Jerod Santo:Yeah, that's gotta be exciting.
Julia Liuson: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.
Adam Stacoviak: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.
Julia Liuson: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.
Jerod Santo: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?
Julia Liuson:\[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?
Adam Stacoviak:It's a different world.
Julia Liuson:It's a different world, so I really--
Jerod Santo: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."
Julia Liuson:We really don't anymore.
Jerod Santo:"And if we do, then that plan is gonna--"
Julia Liuson:It's irrelevant.
Jerod Santo:It's irrelevant by the time the five years hits, because who knows what's gonna happen next year?
Adam Stacoviak:It's just a bad guess. \[laughter\] Or a good guess.
Jerod Santo:It could be good, we don't know. \[laughter\]
Julia Liuson: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.
Break:\[30:01\]
Jerod Santo:You've been there from the beginning...
Chris Dias:I have been, yeah...
Adam Stacoviak:Well, take us to the beginning then.
Chris Dias:...before VS Code was VS Code.
Jerod Santo:There was a previous name?
Chris Dias:Well, it was called Digital Studio Online Monaco.
Adam Stacoviak:Windows Online Monaco...
Chris Dias:No, Visual Studio Online "Monaco".
Adam Stacoviak:Okay.
Chris Dias: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.
Jerod Santo:What year was this?
Chris Dias:Six years ago, so...
Jerod Santo:2011. 2001.
Chris Dias: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...
Jerod Santo:The correct term is "champagne the editor."
Chris Dias:Champagning, is that what it is now?
Adam Stacoviak:Yeah, you don't say dogfood anymore.
Jerod Santo:Think how weird is saying "eat our own dogfood." Really? How about this - we drink our own champagne.
Adam Stacoviak:It implies good stuff, no matter what.
Jerod Santo:Just think about it, maybe try it on for size.
Chris Dias: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.
Jerod Santo:And it started. Okay.
Adam Stacoviak:This is 2001.
Jerod Santo:No, '11.
Chris Dias:In 2011 we started the editor, and probably it was 2013...
Adam Stacoviak:I know it wasn't around 2001...
Jerod Santo:The Space Odyssey... \[laughter\]
Chris Dias: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...
Jerod Santo:Ace?
Chris Dias:Ace was the editor that Cloud9 used...
Jerod Santo:Cloud9 was a service--
Adam Stacoviak:That's right.
Chris Dias: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.
Jerod Santo:Okay. I do recall that time period. Those things were never that sticky from a user's perspective.
Chris Dias:No.
Adam Stacoviak:In the browser, you mean.
Jerod Santo:Yeah.
Chris Dias:Browser-based tools were never really --
Adam Stacoviak:It was a big sell. It was like, you know... notebook IDE in the cloud.
Chris Dias: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?
Adam Stacoviak:So it was an all-in scenario - you had to either go all-in cloud.
Chris Dias:Exactly, and people aren't all-in on the cloud for developer tools...
Adam Stacoviak:Or anything.
Jerod Santo:Developer tools.
Chris Dias:There's latency, there's...
Jerod Santo:Network interruptions...
Adam Stacoviak:It requires an internet connection...
Chris Dias:Yeah, you can't work offline...
Adam Stacoviak:object browse.
Chris Dias: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.
Jerod Santo: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.
Chris Dias: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..."
Jerod Santo:It's two worlds.
Chris Dias:Yeah.
Adam Stacoviak:At that point you're like "I'm just drinking my coffee, man..."
Chris Dias:\[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...
Jerod Santo:Before Atom Shell?
Chris Dias: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.
Jerod Santo: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.
Chris Dias:Yeah, you can talk about that online, I'm happy to--
Jerod Santo: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?
PJ Meyer: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.
Chris Dias: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?
Jerod Santo:Yeah.
Chris Dias: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.
Jerod Santo: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?
Chris Dias:Yeah, do you want me to explain what that is, the language server?
Jerod Santo:Go ahead.
Chris Dias: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.
Jerod Santo:Right.
Chris Dias: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?
Jerod Santo:It's seamless to you get all the benefits of Typescript.
Chris Dias:Yeah, you get a good amount... And more and more come online every month with Typescript.
PJ Meyer: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.
Jerod Santo:Right, it's all there.
PJ Meyer: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.
Chris Dias: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.
Jerod Santo:Let's focus in on the debugging aspects. When I think about IDE's and text editors, I think of like...
Chris Dias:Oh, wait, can I go back to what I remembered?
Jerod Santo:No. I'm just kidding, go ahead. \[laughter\]
Chris Dias: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.
Jerod Santo:\[48:20\] As long as they're in the same project or folder...
Chris Dias: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.
Jerod Santo:No problem. Now, what was I talking about?
Chris Dias:Debugging.
Jerod Santo: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--
Adam Stacoviak:We had this conversation.
Jerod Santo:Yeah, I can't remember... We had this conversation--
Adam Stacoviak:Firefox. Not Firefox, but Mozilla Debugger.
Jerod Santo:Yeah, the debugger inside the Firefox DevTools project.
Adam Stacoviak:That's right.
Jerod Santo: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.
Chris Dias:Yeah, so I should say console.log is just fine... Everybody does it, right?
Jerod Santo:Oh, yeah.
Chris Dias: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...
Jerod Santo: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...
Chris Dias: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...
Jerod Santo:It would be overwhelming.
Chris Dias: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--
Jerod Santo:It's not a person this is not screen sharing.
Chris Dias: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.
PJ Meyer: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.
Jerod Santo:Collaborative on the same session, or what--
Chris Dias: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...
Jerod Santo:Right, plus the latency over the ocean...
Chris Dias: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...?
Jerod Santo: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...
Chris Dias:But for the debugging was the thing that really got me!
Jerod Santo:And it totally sold you.
Chris Dias: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.
PJ Meyer:It's like Inception.
Jerod Santo:It's like next-level stuff.
Adam Stacoviak:Yeah.
Jerod Santo: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.
PJ Meyer: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.
Jerod Santo:\[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?
Chris Dias: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!"
Jerod Santo:Sure. You just demo-ed the feature for the -- or was it the first demo?
Chris Dias:It was the first time, yeah.
Jerod Santo:Yeah, so it's brand new stuff.
Chris Dias: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.
Jerod Santo:Nothing new under the sun... Just new names.
Chris Dias:That's right.
Jerod Santo: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--
Chris Dias: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...
PJ Meyer:It's been in the Insider for a few months now.
Chris Dias: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.
Jerod Santo: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?
Chris Dias: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.
Jerod Santo:Well, if it's published, we don't need to talk about it. Click the link in the show notes...
Chris Dias: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.
PJ Meyer: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.
Adam Stacoviak: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--
Jerod Santo:Please remind us of Microsoft's mission...
Chris Dias:For VS Code?
Adam Stacoviak:Just Microsoft's mission in general...
PJ Meyer:Any developer, any app, any platform.
Adam Stacoviak: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.
Chris Dias:And he's using an editor right?
Adam Stacoviak: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?
Chris Dias: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.
Adam Stacoviak: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.
Chris Dias:\[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.
Adam Stacoviak:That's an interesting mission.
Jerod Santo: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...
Adam Stacoviak:"Be my friend."
Jerod Santo:Yeah. "Do you guys like us?"
Adam Stacoviak:Yeah.
Jerod Santo: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.
Chris Dias:You've gotta be a good citizen, right?
Jerod Santo:Yeah.
Adam Stacoviak:That's the truth.
Jerod Santo:Nobody likes a bad citizen.
Adam Stacoviak:Well, you have a bright spot on you if you're not.
Jerod Santo:A bright spot, or a shadow?
Adam Stacoviak: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.
Chris Dias:I think you're almost ignored.
Jerod Santo:Your ignored.
Chris Dias: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."
Jerod Santo:Yeah, "Doesn't speak my language."
Chris Dias:So you had to break that down. That has been our mission.
Adam Stacoviak:How is that going? Is that happening?
Chris Dias:I think so.
Adam Stacoviak: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?
Chris Dias:There's a bunch of ways we look at it...
Adam Stacoviak:Downloads probably is an impacter, right?
Chris Dias: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.
Jerod Santo:Okay so other types.
Chris Dias:We look at engaged usage of it...
Jerod Santo:Do you have analytics on usage?
Chris Dias:We do.
Jerod Santo:Is that an opt-out for everything?
Chris Dias:What's that?
Jerod Santo:Like, you can opt out of that during the download?
Adam Stacoviak:We often get that question, if you're tracking analytics essentially of usage...
Chris Dias:Yes, you can opt out of it, definitely.
Adam Stacoviak:Okay.
Chris Dias: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.
Adam Stacoviak:The promoter score...
Chris Dias:If you have enough promoter score, yeah.
Jerod Santo:How likely are you to delete...?
Chris Dias:Yeah, there's a lot of people that do that, but it turns out to be a very effective...
Jerod Santo:I think it's effective because it's a single question, one through ten. You just click and you're done.
Chris Dias:\[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--
Adam Stacoviak:6+?
Jerod Santo:All you care about is the haters and the lovers.
Chris Dias:Yeah, because those are the ones that actually have the impact on other people.
Jerod Santo:They have a multiplicative effect.
Chris Dias:Yeah, yeah. And we look at sentiment that comes in through issues... What else do we look at?
PJ Meyer: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.
Chris Dias:Yeah, that's a pretty decent number.
Jerod Santo:That's a good number. And that's like during the month of November...
Adam Stacoviak:Yeah.
Jerod Santo:How many people are on the team?
Chris Dias: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...
Jerod Santo:I really throw the hard balls at him.
Adam Stacoviak:There you go.
Jerod Santo:25(ish)?
Chris Dias: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.
Jerod Santo:Somebody's gonna know exactly...
Chris Dias:It was like "It was 300", "Okay, yes, 302", it doesn't really matter, but there's like 22.
Jerod Santo:Everyone's like "Chris forgot about ME!"
Chris Dias:Yeah, yeah. And if I say eleven, it's like "No, there's one person less." It's roughly that.
Jerod Santo:I'll take rough numbers...
Chris Dias: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.
Jerod Santo: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?
Chris Dias: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...
PJ Meyer: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.
Adam Stacoviak:Wow.
PJ Meyer: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...
Jerod Santo:You can send us that...
PJ Meyer: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.
Chris Dias: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.
Adam Stacoviak: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?
Jerod Santo:429 contributors...
Adam Stacoviak:How many?
Jerod Santo:429 on the VS Code repo. There may be other repos as well...
PJ Meyer:Yeah, the report lists a different number. I don't know exactly how they calculate the difference, but...
Jerod Santo:It's still a good number--
Chris Dias: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.
Jerod Santo: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.
Chris Dias:Yeah.
Jerod Santo: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...
Chris Dias:Sorry, what was the question again?
Jerod Santo:What have you done to enable this kind of contribution?
Chris Dias:\[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."
Jerod Santo:Yeah, there was controversy around the icon recently.
Chris Dias:A little bit, a little bit.
Adam Stacoviak:But the point is that you're listening--
Jerod Santo:They changed it.
Adam Stacoviak:Yeah.
Chris Dias:We respond...
Adam Stacoviak:You're open, you're transparent, you respond, you care...
Chris Dias:Yeah.
Adam Stacoviak:You're quick to change when change is required.
Chris Dias: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."
Adam Stacoviak:Right.
Chris Dias:We'll take feedback and everything in.
Adam Stacoviak: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?
Chris Dias:Go download the Insiders builds. Get those Insiders builds, they're great.
Jerod Santo:Tell us about that, because our community is very much -- we're enthusiasts, we're hackers, and so...
Adam Stacoviak:Edge.
Jerod Santo:This is some sort of nightly build, right?
Chris Dias:It is our nightly build. Like I was saying this morning, this is the exact same build that we use to build VS Code.
Jerod Santo:Insiders build.
Chris Dias:Insiders build. It comes out every night, Zurich time...
Adam Stacoviak:Where do you go for that?
Chris Dias: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.
Jerod Santo:Brand new features every morning, brand new bugs sometimes every morning... \[laughs\]
Chris Dias:\[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.
Jerod Santo:Cool.
Adam Stacoviak:Very cool.
Chris Dias:And learn about Typescript too, because it's mostly in Typescript. It will change your life.
Adam Stacoviak:It'll change your life. Alright, well thank you so much for your time today, guys.
Chris Dias:Yeah, no problem. It was fun.
Jerod Santo:Thanks.
Chris Dias:Thank you.