 Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Amanda Silver. Hey, Amanda. Hey, Robert. Thanks for coming on the show. Of course. To celebrate two things. One, being that this is the 300th episode of Visual Studio Toolbox. Congratulations. Thank you, and more importantly, to celebrate the launch of Visual Studio 2019. Yay. Which is out and available for download. Everyone should go get it. Yeah, and it seems to be going pretty well. I have, at this point, installed it on two of my three machines. I know I'm a little behind, but. I'm disappointed. Haven't put it on the home machine yet, but both of my work machines. Well, that's great. We had a great launch event. It was a lot of fun. People should go watch the keynotes and the sessions, and there's all kinds of on-demand content that people should watch. We'll put up links to those. Yeah, I'm kind of amazed at how much stuff was in Visual Studio 2019, actually. Yeah, but what I wanted to do today is kind of step back and let's talk about how we build Visual Studio, how we think about building Visual Studio. It's been 22 years now of Visual Studio-ness. The landscape has changed dramatically in terms of the types of apps people are building, in terms of the demands that customers face. The audience has changed. Lots of new people have come in. We've changed as a company. How do you account for that, and how does that work its way into the planning and the building of this product? Yeah, I mean, when I started at Microsoft in 2001, that was right after we had shipped the first version of Visual Studio.net and kind of the whole.net platform. And so by that point, Visual Studio was already a pretty established developer product. So I've definitely cut my teeth in terms of product development, working on Visual Studio over the last almost 18 years. And it's changed. It's definitely changed in terms of how we approach it. And I think that a lot of the change over the last couple of years has really come with the cultural change that's been happening inside of Microsoft. I think there's been a huge emphasis, I don't know if you've felt it too, on building kind of a learning culture, like a growth mindset kind of idea, that basically every experience and opportunity that we have is an opportunity to learn something and that we really try to build a learning organization. So when we learn something as an individual, that we also elevate the entire team with that newly found knowledge. And how can we actually become a better, more effective team over time? And to me, that actually translates into the way that we build the product. So every time that we think about any new feature that we wanna go work on, obviously we get a ton of feedback from our community and that builds up a lot of the functionality that we work on. But if there's some brand new area that we think we can provide some new value in, new help in, it really starts with what I call customer led inquiry. Basically this idea that what you should do is go and talk to customers who are either existing customers or aspirational customers, those customers that we would like to be using Visual Studio family products. And we ask them open-ended questions about basically like, what's hard? What's the biggest pain point in whatever job you have to get done? Yeah. So that's kinda in addition to, or just completely different from the idea that, oh, containers are big, we need to support containers. Oh, everybody's gotta be doing DevOps, we need to support DevOps, right? Yeah, I mean, in a way, the technology trends that come out are becoming popular because they are solving a particular problem, right? And so containers are coming out because they solve the problem of having reproducible environments where your dev environment and your production environment really match each other. It's one of the many reasons that containers have kinda come out. DevOps has come because you need a more reliable system to push your code from dev to test to production and you need better coordination amongst your entire team. So a lot of these trends come from pain points that development teams are really encountering. And then we're living, we're doing the same thing. We've gone from Visual Studio ships once every two or three years to now it ships. Is there a defined cadence? So Visual Studio basically, we ship a major release every year, year and a half and then we have, we call them quarterly updates, but they don't exactly happen on quarters, but the idea that there might be anywhere from three to five updates per year of a major release. And then there's tons of small incremental releases that are basically servicing fixes for security reasons or other reasons like that. And then Azure DevOps is on a three week, right, three weeks, they ship every three weeks. Some features, some bug fixes, but every three weeks is a new version. Right, but they also ship even more frequently if there is something that is a more urgent issue they have to address. Yeah, yeah, so our ship cadence has gone from two to three year products that had like a six month planning cycle, waterfall style development approach where I remember we would have spec writing periods and you had to get your spec authored by a certain date because there was going to be the printing of the spec book that everybody would read and it was the book of whatever that release was. And so you had to make that date and you might have six months to do your research or three months to do your research, then that would lead to the final spec, but then it would go to the engineering team to kind of go and implement. And that's very different from how we do development today. Yeah, and that kind of would get in the way of learning from the customers because when you're going dark to build a spec for a product that hasn't been announced yet, it's all NDA, it's very narrow types of questions you can ask people. Right, right. I imagine now it's way more continuous and it can be continuous because if we get something not as right as we thought. Yeah, we can iterate. Yeah, we can fix it fairly quickly. Right, and also if there's new industry trends, if there's something that, if you end up with a product vision that's like two or three years out and something changes in the landscape and what developers have to do, whatever it is, you don't have a lot of, it's not a very agile ship. You can't move it this way or that way. With the more agile kind of model that we've adopted in the last couple of years, not only have we moved towards continuous delivery, but we also are much more agile in terms of what we pick off. Do you do as much two, three, five years out now? Yeah, so the way that we kind of think about it is that there are like horizon one, horizon two, horizon three time frames for research projects that we're doing. So horizon one are things that are like in the next six months to a year. Horizon two would be two to three years out and horizon three would be five years or more. And we have research projects going on in all of those spaces. And in some cases we have engineering going on in all of those spaces, yeah. So how do the customer, how have the customer pain points changed? So it's a very big and loaded question from 20 years ago to 10 years ago, five years ago now. And how do you see them evolving in the future? Well, I mean, that's a pretty massive question. So I mean, I can go through kind of what I'm still hearing today as the major pain points for developers that we've been trying to focus on for the last couple of years. And I think we've been making some good progress but we still have a long ways to go. So one of the biggest, biggest things that developers spend a lot of time doing and they don't always even recognize that they spend a lot of time doing this is dev box setup. That actually getting a developer environment that is configured to build the app that you need to build takes a lot of time. And if you think about something like, let's say you want to build a hands-on lab or a training module or something like that, a course that you wanted to lead a bunch of developers through, it's fairly common that we hear that people spend half the day just setting up machines before they actually get to author any code. And you could think about that, that's actually a similar problem to onboarding a new developer on the team, right? For them to actually get productive and integrate into the team, it can be sometimes a day or two days or even more before they can actually fix a bug or look at the code base or things like that. So dev box setup is definitely something that we've spent a lot of time kind of thinking about and researching. And I think we've made some good inroads in but we still have a long ways to go to improve that. And how much of that is at install time versus incrementally? Well, so actually it's a great question. Part of what we've been trying to do over the last couple of years with Visual Studio is it used to be that first of all, Visual Studio in its, in the old days, I guess. I don't know how to refer to previous versions of Visual Studio, but it was really only designed to build local Windows applications. And maybe you would develop applications locally but then you'd deploy them to a Windows server. But all of your development cycle in the inner loop was done locally. And so for that, you would, for the most part, pick your programming language and install the entirety of what Visual Studio had to offer. Nowadays, developers are building Windows applications, Linux applications, Mac OS applications, iOS, Android, IoT applications, gaming solutions, and Visual Studio has really expanded to enable all of that, right? But the challenge is that if you still, if you check all of the boxes on setup, you're gonna end up with a pretty massive install. And we've tried to over the last couple of years make it so that we don't lead you down that path because we know that most developers are not building for all of those workloads at once. So that's one kind of thing that we've been trying to do. The other thing that we've been working on is making it so that you don't need, it's basically set up as re-entrant. So that, let's say today you're doing C sharp ASP.net development, but tomorrow you need to do Python development. And maybe you need to do Python development for machine learning. How can you not have to pave your machine and basically update your install to be able to do that Python development? And the setup is shockingly fast now. Right. I thought in 2017 it was remarkably faster or less slow, 2019 is shockingly fast. Yeah. Unbelievable, for the exact same workloads. Yeah, so I mean we've definitely done a lot of optimizations on various workloads to get them much more improved. The Xamarin workload for Android in particular is one that's gotten a lot faster. But the minimum install of Visual Studio takes about 2.5 minutes to install. And with that, you get basically the lightweight editing experience with language services that are provided by like text-made bundles. And you can get syntax highlighting, grammar checking, that kind of stuff. But you're not gonna get the really rich debugging experiences or designer experiences. But it's an okay place to start. Because once you install that, you can start looking at code and host your repositories and then you can figure out what else you need to install. But even, I installed on one of the machines six or seven different workloads on Wi-Fi, not even on hardwired. And I think it was like 20, 25 minutes or something. It was crazy. Yeah, yeah. And I mean, the full install will take on a typical machine, I think two hours, something like that, it could take up to that. If you checked everything, yeah. But that's not the norm anymore, which is great. The other thing that we've tried to do is to have what we call tailored installs so that, let's say you're just a mobile developer and that's all that you work on. That you can land on a web page that is optimized for mobile developers and that leads you to exactly the install that you should have. You might not even see setup in that case. In that case, you might actually just click install, everything's kind of pre-checked for you and you're off to the races. So another pain point that I think we're addressing is collaboration. Yeah, yeah. Let's talk about that a little bit. So yeah, I mean, a couple of years ago, probably three years ago now, we started a research project to understand basically like what's the white space? What's the unaddressed problems that development teams are facing? And in particular, we were really focused on those development teams that were focused on time to market as opposed to maintenance, right? So in, let's say startups or teams that are building apps that are kind of more about marketing as opposed to internal LOB applications, those teams have a different development style from a team perspective than those teams that are internal LOB applications. And what we found in studying those teams is that their style for collaboration is really different. What we heard from them was that waiting for the collaboration to happen at the point of commit or a pull request or pull review was too late. Right. And we found that they needed to collaborate much, much, much earlier in the process because everything was changing so rapidly. And so for those folks, we heard all kinds of behavioral evidence that said that this was a huge problem for them. So just some examples of some of the folks that we had talked to said that they didn't want to hire anybody who was in a different time zone because it was so hard to collaborate with them. I even heard one team that was seeing a lot of success with their application didn't want their team to get larger than the physical size of the room that they were able to hold. Because even just the notion of them having to collaborate with somebody down the hall was too onerous. And so that's a big behavioral indicator that like, wow, these teams are really constrained and facing pain because of collaboration. And so what we found was that they really needed to have real-time collaboration, the ability to talk over the code as the code was being written. So that's really where Visual Studio Live Share came from. But not only that and Visual Studio Live Share for those who don't know is the ability to basically have two people co-author the same code base at the same time. It also helps you with kind of that debugging capability so that you can actually talk about a bug or something like that or reproduce a problem. And that actually relates back to the dev box setup problem because a lot of times when you're trying to collaborate with somebody, the problem that, you know, for a lot of consumers, it's like it works on my machine. But for developers, the problem is often it's broken on my machine and it works on your machine and I need your help. And we have to figure out how to get you to reproduce the problem that it's broken on my machine so that we can actually collaborate. And people use screen sharing for those kinds of things and obviously they come over to each other's desks, but there's kind of, I don't know if you- Well, what are you seeing? Yeah, it's, yeah, but also like- Click on the button, no, not that button. Right, there's all this control issue that happens with screen sharing, but also a lot of people don't really want to use other people's keyboards and mice. Like there's kind of a ickiness factor to that. Let alone settings on the computer that like some people might use high contrast mode and others might not, or all different kinds of settings. So Visual Studio Live Share helps you collaborate in real time, not only over code authoring, but over debug sessions, accessing local hosts for the web application that you're working on, things like that. The other thing that we've been trying to do is to make it so that the process that happens either at the CI or as part of the code review process can actually be shifted left, kind of earlier in the phase of development. So we've been working on moving the experience of doing reviews, code reviews, into Visual Studio IDEs. Yes, the idea that you can now make a pull request and then I can see that inside Visual Studio, I can do my code review without having to context, which is tremendous. Yeah, and so like that helps you use the tools that you're really familiar with. You get to use the muscle memory that you've come to, with your code hotkeys and all of that kind of stuff, but you also get like the full navigation, the full semantic analysis that you would get from your normal coding environment, which you don't often get from other kind of pull request review environments. So we've gone from building desktop apps, to web apps, to cloud apps, to mobile apps, and now we've got the conversational AI, and machine learning, and the spatial and mixed reality. So there's all these dimensions where the landscape is changing, and yet you've got Visual Studio for everybody, for anybody can build any type of app they want. So how do you, and with fixed resources for building, so how do you juggle features for the folks whose job it is to maintain existing WinForms apps, versus people who want to move to the cloud, want to adopt some of the better practices for how you collaborate to people that want to be able to dabble in, machine learning and AI, all inside one IDE? Yeah, it's a great question. I mean, there's an art and a science to it. So, I think part of what we do is we really try to focus on the things that are durable assets, like very long-term investments that will pay dividends in the future. So as an example, one of those that I think of is TypeScript, we started to work on TypeScript because we saw this general trend of JavaScript applications becoming a lot larger for a bunch of different reasons. One of the reasons, even internally into Microsoft was that we were authoring Office 365 and we had a bunch of C-Sharp and C++ developers that were starting to work on JavaScript. And they had hundreds of thousands of lines of code, not millions of lines of code, and JavaScript at the time wasn't really ready to scale. And so we introduced TypeScript, and so we introduced TypeScript to kind of help it scale. Now, it turns out that TypeScript allows us to create a much better developer environment for any kind of JavaScript application and provide better tooling. And what we found is that because TypeScript allowed you to have a better tooling experience for JavaScript, it was better for certain libraries like Angular libraries or React libraries or things like that. So for example, the JavaScript community is a little bit fickle about what's a popular framework every year and a half. There's a new hotness on the scene. And TypeScript has shown that it's kind of a durable thing that has basically weathered the storm of the fickleness of new JavaScript libraries coming up, right? But the TypeScript investment then also translates into Visual Studio Code in that, you know, we can actually, the same language service that powers the JavaScript experience in Visual Studio also powers the JavaScript and TypeScript experience in Visual Studio Code. And that's allowing us to kind of go into different domains like React, and that kind of brings up all of the mobile, a bunch of mobile developers as well. There's also Visual Studio for Mac. Right, exactly. So we've also been working on bringing the TypeScript and JavaScript language service to Visual Studio for Mac in 2019 as well. So what we try to look for are those durable long term investments that are going to, you know, if we see a series of trends that will basically allow us to kind of weather those trends and kind of no matter which way it goes that we're on the good side of that. We also definitely, you know, put a lot of weight on the volume where the volume of our existing customer base is and the amount of feedback and the volume of the feedback and the urgency of the feedback that our customers give us. So that also kind of plays in. And then with respect to brand new domains, you know, whether it's machine learning or IoT over the past couple of years, there's a lot of white space to actually provide good tooling because oftentimes when a new domain comes up, the tooling is not particularly good to start. And so I would say that we have a lot of capacity to kind of tiptoe into that space, learn a little bit, get some users, and then once we get a lot of users that are using that on the kind of basic capabilities of hey, I can use the most popular libraries or I can use the most popular languages for that domain, then we start to figure out how to optimize the flows. And then if you're writing C-sharp code, regardless of the type of app it is, things like debugging and editing and the refactorings, they just are C-sharp things, right? So it then doesn't matter that you're still writing C-sharp code in a 20-year-old WinForms app or a brand new Xamarin app or a brand new bot, right? Yeah, there's a little bit of truth to that. Only a little. Well, so I mean what we try to do is to make sure that our users can use the same muscle memory for debugging, for example, whether they're building a Windows application, a web application, or an IoT application or a mobile application. So we wanna make sure that the user experience is the same. That's not to say that it's not work for us to enable all of those things. A lot of what, for example, our debugging team does is they port existing features over to new platforms because every time we support a new architecture chipset or a new runtime target, we actually have to kind of get that to work with our debugging capabilities as well. Yeah. So there's work involved. We don't just get that for free. Yeah, but I mean, I think that's also a super interesting discussion about kind of what's another pain point. One of the things that we're finding is that as developers are moving from on-premises applications to cloud deployed applications that the approach that you take for debugging and diagnostics is really different as well. You know, I think originally when we started doing cloud debugging, our thought was, well, you're just debugging. Right. So you just stop the process just like you do with any application like you would on your server box and you just redeploy. But in this world where you need continuous uptime that you're deploying to production in the cloud, that your inner loop is in the cloud and not local on the box, then the artifacts that you need to do debugging is really changing. So rather than doing what we call stop the world debugging, you instead might capture a trace or a snapshot that you can then look at later and basically use to populate a debug session so that you as the human can look at the program and say and reason over it, but you're basically looking at an execution path that was captured in the past. Cool. Yeah, so that really helps to reproduce and kind of diagnose issues that were found in production. So to close up, what's your favorite new feature of the product? That's a tough one. I mean, I think LiveShare is definitely pretty groundbreaking in terms of we're getting a lot of fantastic feedback from educators, from mentors, from remote employees, from people who love pair programming or mob programming that it's a game changer for them. So I love that. Also from people with different accessibility needs, we're hearing a lot of good positive feedback on it. I'm very excited about Visual Studio and Telecode in that this is just the beginning of how artificial intelligence can make you a more productive developer and make your teams more productive. But I think my favorite feature in 2019 is something really simple. It's search. The fact that we've really improved the search capability in Visual Studio makes it easier to find new workloads, find features that have been there for three releases that you didn't even know were there. There's just a lot less hunting and pecking that you have to do through the menu system than you had to do previously. I'm gonna say that mine is the ability to review pull requests from inside Visual Studio without having to go out to GitHub. I understand that you still have to go to GitHub to actually do the merge. That's fine. But the actual reviewing of the code takes place all inside Visual Studio. Right, right, right. I like that. Thanks so much for coming on and chatting about Visual Studio. Cool, thanks for having me, Robert. See you next time on Visual Studio Toolbox.