The Pragmatic Engineer - 50 Years of Microsoft and Developer Tools with Scott Guthrie

Episode Date: June 4, 2025

Supported by Our Partners•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more.•⁠ Sinch⁠ — Connect with customers at every step of their journey.•⁠ Modal⁠ — The cloud platform for building AI applications.—How has Microsoft changed since its founding in 1975, especially in how it builds tools for developers?In this episode of The Pragmatic Engineer, I sit down with Scott Guthrie, Executive Vice President of Cloud and AI at Microsoft. Scott has been with the company for 28 years. He built the first prototype of ASP.NET, led the Windows Phone team, led up Azure, and helped shape many of Microsoft’s most important developer platforms.We talk about Microsoft’s journey from building early dev tools to becoming a top cloud provider—and how it actively worked to win back and grow its developer base.In this episode, we cover:• Microsoft’s early years building developer tools • Why Visual Basic faced resistance from devs back in the day: even though it simplified development at the time• How .NET helped bring a new generation of server-side developers into Microsoft’s ecosystem• Why Windows Phone didn’t succeed • The 90s Microsoft dev stack: docs, debuggers, and more• How Microsoft Azure went from being the #7 cloud provider to the #2 spot today• Why Microsoft created VS Code• How VS Code and open source led to the acquisition of GitHub• What Scott’s excited about in the future of developer tools and AI• And much more!—Timestamps(00:00) Intro(02:25) Microsoft’s early years building developer tools(06:15) How Microsoft’s developer tools helped Windows succeed(08:00) Microsoft’s first tools were built to allow less technically savvy people to build things(11:00) A case for embracing the technology that’s coming(14:11) Why Microsoft built Visual Studio and .NET(19:54) Steve Ballmer’s speech about .NET(22:04) The origins of C# and Anders Hejlsberg’s impact on Microsoft (25:29) The 90’s Microsoft stack, including documentation, debuggers, and more(30:17) How productivity has changed over the past 10 years (32:50) Why Gergely was a fan of Windows Phone—and Scott’s thoughts on why it didn’t last(36:43) Lessons from working on (and fixing)  Azure under Satya Nadella (42:50) Codeplex and the acquisition of GitHub(48:52) 2014: Three bold projects to win the hearts of developers(55:40) What Scott’s excited about in new developer tools and cloud computing (59:50) Why Scott thinks AI will enhance productivity but create more engineering jobs—The Pragmatic Engineer deepdives relevant for this episode:• Microsoft is dogfooding AI dev tools’ future• Microsoft’s developer tools roots• Why are Cloud Development Environments spiking in popularity, now?• Engineering career paths at Big Tech and scaleups• How Linux is built with Greg Kroah-Hartman—See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

One of the things that we did in the early days of 2014 was kind of just looked around and said, you know, I think we have an opportunity to make a couple of choices that will be bold and aggressive that give us a shot to rewin relevance with developers of the world. And if we don't, we're going to be on an iceberg that's going to slowly melt. And at some point, we're going to be swimming. And so we kind of had a set of meetings in spring of 2014 and kind of wrote on the whiteboard, let's be bold, and came up with three big things that we said, okay, what can we do to become more relevant? The first one was we actually introduced a community edition of Visual Studio.

Decision number two is let's open source.net and let's make it across platform. We want the community to contribute code and do it under the right license and put it on GitHub. And then decision number three was, as much as we love Visual Studio, the IDE, let's also recognize increasingly web developers and those that are not using a compiled language are looking for something that's much more of a lightweight code optimized editor. And there was a great project that had been started. It was basically a web-based. editor written in Node, written in TypeScript, but it ran in a BS online. It was great technology,

but at the time people weren't really looking to write code in a browser. And the three different decisions we made, we kind of made all those decisions, I think, in about an hour and a half. Of the three decisions, they were all very big. The ones that we remember the most would be VScode and then the open sourcing at dot net. Microsoft was founded 50 years ago in 1975. So how has the company changed and held those developer tools across these five decades? Today I sat down what's called Guthri, who has been Microsoft for 28 years, created the first prototype version of ASP.net, and is currently the Executive Vice President for Cloud and AI. In this episode, we talk about few decades of Microsoft,

and how Windows became a success in part thanks to shipping programming tools like Quixie or MFC to help devs build programs on top of the OS. How and why Visual Basic, C-sharp, ASP.net, and Visual Studio were created, the time when developers pay thousands of dollars per year to access quality documentation over MSDN, how Microsoft decided to embrace open source and create VS code as an open source project, and many more topics, including what Scott is excited about looking ahead. This is a rare conversation with Scott, who has been with Microsoft for over more than half its lifetime, and I hope you enjoy the stories and details that he shares with us.

So Scott, welcome to the podcast. It's great to be here. Thanks for having me. It is so nice to meet again, especially that we've met a long time ago, 10 years ago, and that I also worked at Microsoft. But today, I'd like to talk, just go back to way to the, the beginning. Fifty years ago, it's crazy to say that, that's when Microsoft was founded. And when I think about Microsoft, my first memory is Windows, but actually, it started with developer tools, right? Yeah, the very first product that Microsoft built. And really, you know,

not just the first product, but for many years, we were just a developer tools company. And so it was Microsoft Basic for the Altair. And Bill and Paul Allen built it while Bill was still in Harvard. and the legend is they flew out to Albuquerque, New Mexico, which is where the company that built the Altair was. The computer no longer exists, obviously. And they brought a tape of Microsoft Basic, a paper tape, and they actually plugged it in and loaded it, and it worked. And it was actually they built the app basic entirely without access to the computer.

and it was kind of the hit product for that particular computer, and then they expanded other platforms and then eventually operating systems. But the first dollars, they made by selling basically a developer tool, a compiler, right? So, like, you could write basic code and it would compile to machine code, right? That was the product, right? I think it was an interpreter at that time. The interpreter, yeah. But basically, yeah, I mean, it was literally, and back then,

that was how you kind of used computers as often you were a programmer and you actually, you know, I guess today would be modern equivalent be scripting. And you built your own logic and your own applications. And so, yeah, that's one of the things that's been cool is that the company started as a developer tools company. And when you look at what we built today, whether it's VS code, whether it's GitHub, whether it's Azure, we remain a developer tools company. If you want to build a great product, you have to ship quickly. But how do you know what works? More importantly, how do you avoid shipping things that don't work?

The answer, Statsig. Statsic is a unified platform for fly. analytics, experiments, and more, combining 5 plus products into a single platform with a unified set of data. Here's how it works. First, Statsic helps you ship a feature via feature flag or config. Then it measures how it's working, from alerts and errors, to replace the people using that feature to measurement of top line impact.

Then you get your analytics, user account metrics, and dashboards to track your progress over time, all linked to the stuff you ship. Even better, Statsic is incredibly affordable. With the super generous treats here, a startup program with $50,000 of free credits and custom plans to help you consolidate your existing spend on flags, analytics, or AB testing tools. To get started, go to statisic.com slash pragmatic. That is sta, tsig.com slash pragmatic. Happy building.

This episode is brought to you by Cinch, the customer communications cloud trusted by thousands of engineering teams around the world. If you've ever added messaging, voice, or email onto a product, you know the pain. Flaky delivery and platform stack with middlemen. Sinch is different. They run their own network with direct carrier connections in over 60 countries. That means faster delivery, higher reliability, and scale that just works. Developers love Sinch for its single API that covers 12 channels, including SMS, WhatsApp, and RCS.

Now is the time to pay attention to RCS, rich communication services. It's like SMS but smarter. Your brand name, logo, and verified checkmark, all in the same. inside the native messaging app. Built by Google, now rolling out with Apple and major carriers, RCS is becoming the messaging standard. Cynch is helping teams go live globally. Learn more at cinch.com slash pragmatic.

That is S-I-N-C-H-com slash pragmatic. And just stepping forward from basic, this was 1975, but in the 90s or actually like mid-80s, Microsoft starts to become big because of Windows. And as I looked into the history, I was pretty surprised to, see that as Microsoft developed Windows 1.0 and then 3.0 and 3.0 was a big, big breakthrough. They always developed programs to build on top of Windows. So they did QuickBasic, Microsoft C, and QuickC. Do you think, you know, having talked with early Microsoft employees and just knowing the answer, was this an intentional strategy? Or might have this thing actually helped Windows become as big as it did?

Well, I think it absolutely helped Windows become as big as it is. I mean, at the end of the day, if you're building an operating system or you're building a cloud platform, your success is very much, no one buys a platform by itself. They buy it for the applications that run on top. And so if you don't have developers building those applications, you don't have a business. And so I think definitely in the early days with Windows, you know, part of the whole thesis was, you know, build great tools, make it easy to build applications that are great. help developers be successful.

And if their apps are successful, we'll sell more Windows. And it's similar today with Azure in terms of, you know, one of the things I covered in my keynote was chat GPT, which runs, you know, entirely on Azure. And, you know, it's another great example of, you know, how do we make, in this case, a company, opening I successful and enable them to build an amazing app. And if they are successful and they're running on our platform,

we're successful too. And so it's a model that I think is very much core. of the DNA of the company. Yeah, and then in the 90s, as Windows became more popular and, you know, there was these tools, Microsoft did something really, really interesting. They built some tools that allowed maybe not as technical developers to build stuff. Visual Basic, Microsoft Access, later Microsoft Front Page. And I'm now having a little bit of what we're seeing today, but just reflecting on that time

and what you've seen. Visual basics seems to still have a massive impact. When I worked at a bank at J.P. Morgan, you know, like building like software that was used by professional traders. Some of the traders loved using Visual Basic that they, as non-technical people, could, you know, write their own programs. Visual Basic at the time was absolutely revolutionary because I remember I was in high school and I was a developer on the Mac. Maybe System 7 had just come out. It was like a long time ago on the Mac. pre, you know, OS10 and everything.

And, you know, building a GUI application was a lot of work. You know, if you wanted a menu, if you wanted buttons, if you want a dialogue, I mean, you were writing a lot of code. And it was often very error-prone code because if you got anything wrong, it would crash. And there were no visual designers. You know, it was pretty much, you kind of had to do everything from scratch. And Visual Basic came along and it was sort of you could drag and drop buttons, you know, visually lay them out, double-click, write a couple lines of.

code hit F5 and it ran. And it really transformed development. And, you know, we ultimately took that same paradigm and used it with access for databases. We also had a product, which is one of the ones I used. I think it was the first thing I ever got paid for was a product called Visual Fox Pro, which was another database product that was graphical. And then extended it to things like Visual J++. And then, you know, ultimately the Visual Studio family, including C-Shart.

C++ and others. And so that notion of, again, it was core of like, how do we take the friction out of what developers needed to do and provide great developer tools to do it. And as much as the drag and drop aspect of Visual Basic was revolutionary, the other thing that was revolutionary was just the speed with which you could run. And it had a pioneered a feature called Edit and Continue.

So you could even have the application running, modify a couple lines of code, and then push the button again, and without having to kind of rebuild or recompile or relaunch, you could actually see the edits immediately take effect. And that was also kind of transformative. Today, with JavaScript, we were sort of used to that kind of paradigm of make a change, hit save, and it just works.

But, you know, in the 90s, that was radical in a big way. Can we just rewind back time? Because I feel there's a bit of a similarity. Like back then, up in the 90s, before Visual Basic. and Access and Fox Pro came about, there was no way for like non-super technical people who knew, you know, you learned the syntax to write programs. And these things just allowed,

honestly, everyday people like my dad, who was not a developer, he used, he put together a bunch of stuff with Access later Fox Pro. And today we're in a similar thing, but I'd like to know, like, do you remember what the mood was like? Where developers saying like, oh, no, this is the end of development. where now, you know, like, we're not going to have work. Was there any of this? And then what happened as a result of this?

Because now we have like 20 or 30 years of looking back of how it transfer of software engineering and the industry. There probably was some, you know, questioning in terms of like, oh, is this going to, you know, mean anyone can be a developer. I think it's often the refrain, whether it's, you know, that era, whether it's web development, whether it's, you know, co-pilots and AI assistants now.

I remember that same pushback when Java came out and Donnet came out. It was sort of like, you know, no real developer would ever use garbage collection. Oh, yeah. It really should be, you know, Malican free. And, you know, I think the history of development and the history of computing is really around how do we continue to optimize the productivity. And, you know, I think what makes a developer successful or have impact, you know, is not syntax. and it's not unnecessary writing of code that can be automated. It's often the logic.

It's identifying a problem. It's the creativity. And it's often the problem solving to make it work. And I think developers that embrace the new technology and build on top of it end up being so much more productive, which ultimately means that they have better careers, they're more impactful. And so I always encourage people that kind of don't assume your value is the syntax. that you're familiar with, you know, assume the value is a higher level thing that you can leverage. And, you know, I think it's true both for developer tools and languages, you know, especially in the

context of AI now. But I think it's also true in terms of cloud platforms. You know, it's, I talked to my keynote this morning at Build about chat GPT. And, you know, if Chad GPT had been built 10 years ago, you know, or certainly 20 years ago, a company would need to build their own data. centers, they would need to build their own operating system. They would need to build their own deployment orchestrator. They need to build their own database. That's exactly what Google had to do. That's exactly what Google had to do.

And the fact that they were able to leverage things like CosmosDB and our Azure Kubernetes service, you know, they now have an app that's the fastest growing in history with 500 million weekly users. And one of the stats I put in the keynote is they have a total of 12 people on their infrastructure team that manages all their Kubernetes and compute infrastructure. And that type of productivity is stunning. And so I do think, you know, I would encourage if your developer embrace the technology and the productivity that's coming. And it only makes you more successful and have more impact.

And there's more than enough problems that are still left to solve. So after Visual Basic, one of the big years was 1997. I guess for two reasons. Was that the year that I remember that you joined Microsoft? I joined Microsoft full-time in 19. I was actually an intern in 96. But I joined out of college. I think I graduated like May of 97,

and I joined Microsoft on June 16th. And obviously, in history of books, we don't look back on you joining specifically, but it was Visual Studio released. And of course, later Visual Studio became this really, really powerful, the Bullet Pro Tools. I started my career working on Microsoft Technologies and Visual Studio.

So back then, like, You were at Microsoft as an interim before this came out, Visual Studio came out. What was the story behind? Why did Microsoft decide to double down? There were developer tools. Like there was, I think Microsoft had their quick C. Like, there were things that kind of, like compared to Visual Studio,

they looked like very kind of early versions, but there were things like that. How did this whole development come about? And then why did Microsoft decide to just double and triple down on it? Well, I think one of the big things that happened, you know, really, and we kind of really started the project in 98, was both the real emergence of Visual Studio as a tool, and then also dot net. And they kind of, you know, in 2000,

we unveiled kind of dot net and Visual Studio.net together at the PDC conference in July of 2000, I remember. And, you know, the impetus behind that was, you know, Digital Basic had been hugely successful in the mid to the late 90s. and, but there was still this gap in between where you had Visual Basic or Visual Fox Pro, and then you had on the right hand side in the more advanced category, C++. And, you know, C++ was, and still is, a key programming language.

And there was MFC, right? The MFC library. There's MNIFC libraries. Which, which I guess you can't talk about Windows development. It wasn't just C++, NFC made it like so productive. Yeah. And there was also an thing called ATL. which is another library.

I haven't thought of that in a long time. But yeah. So we had a couple different framework libraries, but it's still, you know, if you use C+++, MFC made a huge difference, but it wasn't as productive as it could be. And there was a sort of gap in the between.

And part of why we created dot net was to sort of say, okay, can we create this common language runtime that could handle VB, could handle a C++-like language, and could handle a bunch of language, languages in between. And then, you know, could we also avoid each language having to have its own programming framework? And so like MFC only worked with C++. It didn't work with VB. You know, the VB designer didn't work with Z++. And, you know, instead could we build a common set of developer

tools, whether it was debugging, whether it was around visual design, whether it was around code optimization, profiling, et cetera, Intellicense, and leverage it. And that's where really dotnet and Visual Studio really took root. And basically we came up with the common language runtime. I started a project called ASB.net with Mark Anders, the two of us. And that was a web framework. And when did that start compared to dotnet? So did dot net come first or was ASB.

Does that parallel to all of this? Sort of parallel. I mean, basically, ASB on net started, I mean, I kind of wrote the original prototype over Christmas 97 to 98. Wow. And the prototype I wrote was, you know, I used

some C++ plus, some JavaScript, and some Java. It was kind of a, you know, it was more the idea as opposed to there was no code that was actually reused. But it was, you know, it was this idea of like, okay, could you use classes, could you use objects and could you have language productivity that allowed you

to kind of work very quickly? And so I started, you know, we started, Mark and I started showing it to a lot of people internally and got a lot of excitement around it. Sort of in parallel at the same time frame, the common language runtime got started. It wasn't called dot net, but it was called Core,

was the original, I think, code name. But they were kind of building a runtime that could do languages. They didn't have libraries, but, you know, they had languages. And then Visual Studio was trying to figure out, okay, we had the VB, IDE, we had the VC, Visual C++ IDE, we had this job, of IDE, how do we merge that? Yeah, J-Sharp, right? J-sharp, and then it all kind of came together.

And so in the process of 98, these three teams sort of found each other, and we started working together, and 99, we built a whole bunch of stuff, including Windows libraries and for GUI and for other things. And then ultimately, we were supposed to release it to the world. I think it was like the equivalent of build. We called the PDC back then. I think it was supposed to be February or March. of 2000, and we were late.

And so we slipped it to July. And July 2000 was when we kind of unveiled it at a big event, much like the build event we're doing today, and showed the world like languages, frameworks, and tools all working together. And that was kind of really the unveiling of dot net and tools. And it was pretty critical for our success in the 2000s. You know, in the same way that VB really helped drive Windows client. Dotnet really helped.

Windows Server and SQL Server and, you know, really introduced Microsoft to a generation of server programmers. Yeah, and I think one of the most iconic, you know, videos and now memes is Steve Balmer yelling developers, developers, developers, you know, sweating in the t-shirt. And usually that's the only part that gets quoted and people think, you know, Microsoft was all about developers. But when you watch the whole thing, which I did, you know, the whole thing that he said, he starts out, okay, what's a $64,000 question? what the hell are we supposed to do with dotnet Steve? And then he goes developer. So as I understand, this was about before the dot net release, about how to reach developers with dot net.

Can you bring a little bit more behind the meme? Because I feel there's way more depth in this statement. Yeah, I wasn't at that event, so I don't have all the cutics. But I think the main point that Steve was trying to get across and you see it if you ever watch the video is just the passion you had around developers and his main point was just developers really matter and so when people say,

why are you doing all this? It's because of developers and developers, developers, developers. And I think that is kind of just a critical nature, which is, again, if you want to build a platform, if you want to have an ecosystem, you have to have developers. And ultimately developers are the ones that both build the most interesting

solutions and they also push the platform and apps the hardest. And, you know, I think that that was his main goal was just to get across to the audience, just how passionate he was around that. It wasn't about money. It wasn't about press. It's really around, are you winning the hearts and minds of developers? And I think that's a big part of why, you know, Microsoft Build is special is, you know, even take today's keynotes. It's, you know, tons of demos, lots of hands-on, live demos, you know, hands-on, lots of labs. You know, it really is an opportunity for developers to get together, and it's not about sort of chest pumping.

It's more around here's what you can do. And how do we, you know, have a good conversation and dialogue around, you know, what can we do better at Microsoft, but also how can we make you successful? And so dotnet was huge when it launched with Visual Studio hand in hand. But a third part of why I think it was really successful at this time was C-sharp itself. where does C-sharp come from? Well, it must have come from inside Microsoft, but was it before. Dotnet?

Was it during dot-net? Because I do remember that C-sharp kept evolving as well with new features. Well, Hanenham with Dotterling, for example, was a good example where it's both the language feature, but you needed framework support as well? Well, you know, the real genius behind C-sharp is Anders-Hilesberg, especially in the early days. And, you know, Anders is still at my...

Microsoft, he's still building languages, and he also was responsible for TypeScript. And before Microsoft, Anders worked at Borland, which is a name that most people, if you're not my age, don't remember. But it was an iconic developer tools company in the early 90s, late 80s, and built some amazing tools, one of which was called Turbo Pascal. And Anders was the guy who wrote Turbo Pascal. was the guy who wrote Turbo Pascal. And he wrote it originally from Denmark.

I think he wrote it when he was in Denmark and sold it or licensed it to Borland. And, you know, part of what made Turbo Pascal revolutionary, this even came out before, I think, B.B. Visual Basic was it was just lightning fast. And so you could literally on a PC with 256K of RAM, you know, it had an editor, it had a debugger. And if you had run, you know, in a few seconds, your Pascal app would. would work. And, you know, he added good language features into Pascal and really built that. And, you know, we were very fortunate. He joined Microsoft in the mid-90s, along with a bunch of Borland

employees and really brought both that developer ethos. You kind of really helped rejuvenate the developer ethos at the time. And then also just a language sensibility. And, you know, I've worked with Anders now for 25 plus years. And he's just, he's absolute genius in terms of understanding both what to add into a language and what not to. And there's a real aesthetic where it's easy to kind of just throw in the kitchen sink into a language. But how do you make these things make sense? How do you, you know, you mentioned Link, which was a language query technology. And, you know, part of what made the elegance of Link at the time so great was it built on generics,

which was also built into the language, which then composed. into the runtime. Yeah, and generics in C-sharp was very powerful. Yeah. And it was, you know, at the time, it was a very, it was a big differentiator versus Java, which didn't have generics, um, when it, when C-sharp first introduced it. And just the way that Anders kind of saw over multiple generations, okay, we're going to add generics into the CLR.

We're going to add it into the language. And then the next verse, we're going to come up with link. And, um, you know, it's just, it's, it's been sort of a mastery to see. And I think versus other languages, there's, there's, great continuity throughout it versus, you know, different languages I think sometimes have taken kind of a left turn or right turn and not always a kind of linear progression. And they've taken detours. And I think it's been great to see the way Anders is, both with C-charp and also with TypeScript has kind of had a vision that he's built on top of that really has a bunch

of consistency and sort of common direction over time. And then in the early and mid and late 2000s, the Microsoft ecosystem was really special in the sense. When I worked at one of my first companies, we were paying $1,000, $2,000, $3,000 per developer to access Visual Studio together with C Sharp, ASP.net, getting access to the different software like SQL server and IIS so we could develop and use them

because licenses were very expensive otherwise. And to MSDN library. Now, I just want to pause on the MSSDN. in library because I've never really seen a company do this before or after where this was before Stack Overflow and even before having good things on the internet, we would pay to access really, really good documentation. Earlier on it was sent out on CDs because they were so big. Do you remember, like, how or why did Microsoft get this idea of like, let's just invest in

documentation, especially because as a developer, I'm going to be honest. You know, like, it's usually one of the last things I come around to. Yeah, it's, it's, I feel like I'm dating myself on this podcast, but, you know, I think for a lot of listeners, you know, the idea of like buying documentation sounds weird. These days, yes, but back then, back then it was pretty revolutionary. And part of it was, you know, back, like when I joined Microsoft or was an intern, you know, the internet was still very, very new. And there wasn't like a search engine out there that was very good. And this was all pre-Google, pre-bang. And, you know, HTML was still pretty rudimentary. You know, it's, I remember up until about 2002, 2003, you know, a lot of sites did not even rely on JavaScript or at most used very, very minimal JavaScript because some browsers didn't support it.

You know, it was pre-cSS. And so as a result, you know, the idea of searching for documentation and reading it in HTML and a browser was just not done. And so, you know, the original impetus, I think, between MSDN in the 90s, was this subscription service. And you got... Every quarter, every month, you got the CD. Yeah, you got a lot of CDs. I remember it was, you know, 50 CDs sometimes. Yeah.

You know, it would have all the updated applications. So it would have all the Microsoft operating systems, databases, developer tools, I think even office at one point was included. Yeah, more and more things came into it. And then you had, like, tons and tons of CDs with the documentation. And so you could kind of, you could kind of, you could kind of, you know, install it and then you could search and that coupled with Intellicense, which is or statement completion, which is another thing that I think a lot of people take for granted now.

And then the other thing that I think we also take for granted is debuggers. You know, I remember when I was in university, you know, the debugging experience was often print F statements and or a command line debugger that was very rudimentary. You know, you could kind of dump your, your symbols or registers, but it wasn't like debugging today.

And so, you know, as a result, the MSDN was for a different time, I guess. It's a little quaint. But it evolved over time. And part of it also became this notion of a subscription service where your apps were always up to date. And so I think at some point, the documentation just turned on to be on the internet.

But, you know, the notion of the apps was still. But I think one of my takeaways is that when I think back, like I was at a startup. like a small company, 50% company. It was actually in Hungary. You know, we didn't have that much like revenue or income compared to the US. And my employer still paid that $1,000 or $2,000 per developer per year because the developers were so much more productive using this whole Microsoft stack.

And all things have changed. But to me, that point in time is a bit of a reminder that there is a big premium on just being so much more productive than anything else. Because back then, you know, everything was already taking. Together, I think we take these days, it's so, like, everything that we're amazed about having documentation of working debugger, you know, like software that you can use for free, like for database software, like that was SQL server back then. But it was all there. And I wonder if, you know, we'll move this notion that, like, a company that everything's so much better and built an ecosystem that just worked, it was really valuable. It probably applies today as well.

Like, maybe not in, you know, like a multi-thousand-dollar subscription. But something is there. I just vividly remember how no one forced anyone to use Microsoft. And it was not about Microsoft. It was just about like there was this thing. It just were working faster, especially when we were building either the first websites because ASP.comnet was still. There was a point where 25% of all sites were ASP.combed based on various things after launch.

It just went up on this thing. And I assume this must. Do you have theories on why that was? I mean, your ASP.com was your baby a little bit. Well, I think the general thing, I think it's true for pretty much every field, in fact, when it comes to technology is, you know, people like things that make them more productive and let them do more faster, cheaper. Yeah, I think it's always worth reflecting because like on just, you know, imagine 10 or 15 years ago what the world looked like. You know, if you were going to an event like this, you would either rent a car or, you know, you'd stand in line. or a long taxi, whether it would get you there, whether you get ripped off.

Now you have Uber or Lyft, you know, similarly coffee or a coffee maker, you know, you'd go and find a store and try eight of them and you'd search a job. You know, now you can order on Amazon and it will show up same day or next day delivery. And so, you know, I do think we kind of overlook the productivity that's changed in just 10 years on a regular basis. It's not baseline, right? Yeah, when you step back and think about what the world is. look like back then, even five or ten years ago, it's completely different. And I think that's

going to be very much true for AI. And when we look at the kind of productivity that's a GitHub copilot as or, you know, other AI assistance tools provide, you know, it's going to be like that printf and the debugger kind of story I told earlier or, you know, it's going to be also kind of a quantum leap in terms of productivity. And, you know, at the end of the day, if you're getting more productive and saving time, you know, companies and developers are willing to pay for it. If the developer can make more money because of using those tools. We see from the past, like very hard money. This episode is brought to by Modal, the cloud platform that makes AI development simple.

Need GPUs without a headache. With Model, just add one line of code to any Python function and boom. It's running in the cloud on your choice of CPU or GPU. And the best part, you only pay for what you use. With subsecond container start and instant scaling to thousands of GPUs, it's no wonder companies like Suno, Ramp, and Substack already trust Model for their AI applications. Getting an H-100 is just a PIPP install away.

Go to modal.com slash pragmatic to get $30 in free credits every month. That is M-O-D-A-L.com slash pragmatic. Now, I just wanted to touch on, just briefly on Windows phone. Windows phone was, I was a Windows phone developer. In fact, I think that's where we connected on one. of the events when Microsoft was about to launch Windows phone. There was pre-launch events. And to this date, when people ask me what I think about, development on iOS, development on Android,

I tell them the best development experience I've had was on Windows phone. So Windows phone, many listeners will have not used it for obvious reasons. But I was a huge fan. Not, again, and not because of Microsoft or anything, but it had some really forward-looking features like live tiles, which are now kind of a given everywhere, but it was years ahead of it. the development experience was so smooth. We had that first class debugger. We had the simulator that just worked. And in the end, Windows Phone is now history.

But you were there when Windows Phone was born throughout its rise. And then in the end, when Microsoft decided to discontinue it, what are some learnings that you have on building platforms and delighting developers and what works and what doesn't? Yeah, there was some great tool. I ran the Windows Phone Development Tool team at one point. I mean, amongst other things. But so I was involved

on the developer tool side for Windows phone. I didn't work on the Windows phone team itself, but we kind of took dot net and C-sharp and Silverlight technology and Zammel and Visual Studio. And I think, to your point, I think we had some really great tools that were pretty different.

The tools were really good. I think that there were two or three lessons from Windows phone, for me, at least from a development perspective. I think one was, which is true, I think in technology in general, which is if you're not number one, you've got to be number two. Because it's really hard to be number three and number four in the market and have ever catch up. And so in some ways, the Windows phone project started after the iPhone was released and or the modern Windows phone that you like.

And I think Windows phone would have had a shot other than Android came out and came out beforehand, a show. sort of amount of time. And, yeah, I think it was really a question of whether Android or Windows phone was going to be the number two in the market. And I think if we'd been a year earlier, maybe it would have turned out differently. I think the other thing is the need to kind of connect with developers broadly. And that means, you know, we supported Windows phone, Windows as the development experience. But it didn't work on the Mac. And if you think about to 2009, 2010, if you went to a developer conference, a huge number of people were using Macs. They're using open source. And so, you know, basically saying, okay, you got

to install Windows on your Mac and use it in order to build an app, you know, was a huge issue. And then I think also at that time, you know, designers were exclusively Mac. And to some extent today, they still still are. But, and so, you know, that combination was also headwind. And that combination, I think, was the reason why ultimately it didn't get the escape velocity. And that's why I think speed matters in platform shifts. And that was true for Windows. That was true. You know, even the context of Azure, when we first launched Azure, I think we were number seven in the market on cloud providers.

And thankfully, we're able to become number two. Yeah. And let's talk about Azure, because after Windows, or maybe during Windows Phone, you, you, As I understand, you were a big part of the Azure which we've been creating Azure. How did this is your start and how, especially, I think we just need to remind ourselves that. This was back then where Windows was everywhere. The internet was just, I guess, starting up. Some visionaries might have seen it, but it was not that obvious.

It will be as big as it would be. Microsoft was making so much money from Windows licenses and selling developer tools. You know, CDs were arriving on the mail. And then, you know, there was some big investment, lots of people starting to work on this thing called Azure. which didn't, now we know what's big, but back then it wasn't. Like, what was your conviction? And how did this whole project get off the ground? Especially, as you said, you were number seven when you started.

Well, you know, I think we introduced Azure to the world in the 2008 PDC, so it's the equivalent of build, so in 2008. And I think it went general availability in 2010. So the 2008 was kind of a preview. And, you know, back then in 2010, cloud was still very new. I mean, Amazon was the leader. But there were lots of, I call it hosting companies, you know, Rackspace and Joyant and a whole bunch of companies that probably are less familiar namewise today that different companies had cloud solutions. But they were really kind of more hosting solutions.

And, you know, Azure did have, when it came out, it pioneered this idea of platform as a service, meaning kind of some higher level services that made it easier for development. to build solutions. But, you know, I would say the platform is, you know, it had some usability issues in that time frame. And it also, uh, did not support Linux or open source at all. And the tooling was not great. And, you know, I'd say by 2010, when it went general availability, it was, it wasn't doing super well in the market.

And I think we were like number seven or number eight or number six. I can't remember what it was. But beginning in 2011, I think Satya took over. what was in the server and tools business where Azure lived. And it was about three or four weeks later, two or three weeks later, you kind of wandered into my office and said, hey, how would you like to work on Azure? And at the time I was in the developer division, you know, for some reason I said yes. And at the time, you know, a lot of people, you know, emailed me and they're like,

what are you doing? This is career suicide, you know, this is not going to go anywhere. And so after we announced it, and I got lots of mail from people telling me I'd made a huge mistake. There was a brief moment. I was like, well, maybe I made a mistake. I don't know. But this idea of having kind of this cod-based computer that you could build platform, you know, build solutions on top of and run them at scale. And dramatically change the curve of productivity as well as success for startups and small companies and big companies.

you know, it was enticing. And so, yeah, I think I started in 2011. You know, one of the first things we did was that's kind of gone down in lore was, I kind of worked on the project for maybe 60 days, played with the product a lot, and said, gosh, we have a lot of things to fix. And so we had sort of this off-site where we brought together all the senior leaders and architects into a room. And I went to a Safeway and bought these sort of visa,

credit cards that were like prepaid and gave one to each table. And we mixed the teams up and we said, you're going to build an app. And we have two days to build an app together, starting with signing up. And, you know, half the people couldn't figure out to sign up. And, you know, half the people struggled to get the tools installed. The documentation was out of date. It didn't work. And, you know, the idea was just, you know, can you build a Hello World app?

And it was an eye opener, I think, to a lot of people of like, oh, I thought my part was great, but no one can use it. And we use that off-site at the end. I kind of went to the whiteboard and said, okay, let's list all the things we need to fix over the next year. We kind of created a punch list. Starting as a new user who wants to.

Starting with a website and sign up, start with documentation. Let's start with the developer tools. Hey, we probably need to support open source. Yeah, we created this punch list and 12 months later, we relaunched Azure in 2012, started to get some good

traction. As part of that, we also supported Linux. We supported VMs, which... That was a huge change. I still remember. We originally didn't do. And then in 2014, we renamed Azure to be Microsoft Azure. Back then, before that, it was Windows Azure. And then as part of that, we also very much focused on businesses, because we realized Amazon really owned the consumer startup space, which was the biggest market in cloud at that time. And, yeah, yeah, it was, you know, I think one of the things that was part of my lessons from watching the Windows Phone Project was, if you simply try to do exactly what your competitor does and they're ahead of you, it's hard to catch up.

You know, pick something, pick a beachhead that is small enough to win, big enough to matter. And we sort of said, let's be the cloud for modern business. It was kind of the tagline. It was a hybrid, take advantage of cloud, you know, use cloud, connect to the existing enterprise you already have. And we were able to kind of build differentiation in Azure that, um, went after a segment that was still pretty small at the time and Amazon wasn't great at. And that was the key thing that kind of took us from like number seven to number two was people said,

okay, I get why I might use Amazon and Azure. And it helped us get some of that escape velocity and put us in second place. And then we've kind of grown every year since then. And now we have done, you know, hence Chad Chibati and we have lots of other, yeah,

not we're going to water market. But it helped us in 2014 to 2016 or 17. that we were kind of great in hybrid cloud and Amazon kind of didn't want to go after that space and as a result, that really helped us accelerate and become relevant. And this is probably a good lesson for even like startups, small startups who are in a very crowded space,

let's say with AI, like, you know, look at the places that might be a bit more opportunity. If you can find an underserved market where people are desperate for a solution, that's a great place whether you're a startup or you're an established company to kind of build a new product. If all you're doing is building the same thing that your competitor is doing,

but you're coming out later without as much share, it's really, really hard the history of computing to catch up. So you mentioned open source, and a big shift in the 2010 was open source. Microsoft did have a bit of a felt to me a half-hearted attempt with something called Codeplex. A lot of people will not remember it. It was basically like, hey, host your stuff on Codeplex.

You can choose your license or you can not do a license, but most projects were like non-permissive licenses. You could see the source code, but the license was just not there. And then something happened. So the weird thing was that Microsoft did have this solution, COPlex, and it was popular with Microsoft, one of my old companies used it. And then Microsoft started to just, like, first embrace GitHub. Obviously, there was an acquisition of GitHub.

But even before, I think Microsoft already started to do a lot more permissive open source. I think the Ajax toolkit might have been one of the first ones to go out there. What happened then? Like, was this coming from internally from below? Was it, you know, like, like, leaders like yourself saying, all right, we should just, you know, like just be a lot more serious about open source, like proper open source. Yeah, I think it was, it was very much a cultural shift in the company and then also a business model shift. I mean, I think ultimately there, you know,

was philosophical things about open source, but I think a lot of Microsoft's early hesitation around open source was really around business model. And I think it's true today, even if you if you look at any company and what they're doing, you know, start with what is their business model. And often what they do is driven by the business model. And so if you are social media, you care a lot about advertising because that is your business model.

And so when you think about privacy or you think about data protection, you know, your position on that matters a lot as to whether you could monetize and, you know, pay the rent. And, you know, Similarly, I think if you are a hardware company, you care a lot about the hardware and your business model is really around selling the hardware. And so you care about a different set of things.

And we were at the time in the early 90s or the late 90s and in early 2000s, you know, most of our money came from commercial software licenses. And so the idea that like you could buy one copy and give it to everyone, you know, for free. For free was kind of a scary thing at that time. And so, you know, I think so part of it, part of our. kind of concern around open source was really grounded, frankly, in business model. And then I think there was also kind of a misunderstanding of what is open source. And, you know, back then there was sort of GPL and, you know, if you checked in one line

of code, would it, you know, the license mean that like you just gave away all your IP. And so there was still, in those early days, there was a little bit of misunderstanding. It was before, you know, GPL kind of modified the license a little bit and clarified a little bit what it meant. But I think there was also some fear, uncertainty, and doubt that a lot of companies, not just Microsoft kind of had around it. And so, you know, that was in the 90s. I think what changed in the late 90s, and I probably played a big role in this, was just recognizing, but if you're a new developer trying to say you need to pay us money for everything, whereas something else, and that you can't see the code, you can't help contribute to the code, you can't

participate in the development, you know, you're swimming against the tide. And, uh, you're, You know, at the end of the day, if you are a new or an old developer in that time frame, you kind of want to be able to see the code. You want to be able to contribute. And so, you know, we took some early steps. And it was a little bit, you know, as you mentioned, he's been on an Ajax toolkit. I think it was the first thing we open source. I think it was.

I talked to some folks at Microsoft. And I remember another big step we did was we added JQuery, going back, Memory Lane, which was at the time one of the most popular. I think actually prototype was the most popular and JQuery was the up and coming because it was really streamline. Yeah, it overtook it. It overtook it. But we kind of added it into

the ASPNNet template inside Visual Studio. And that was also considered groundbreaking at the time. In hindsight, this all sounds trite, I guess. But at the time, it was a big thing because suddenly we were taking licenses like it was MIT or BSD license and incorporating it into our commercial product. And it was

a bit of a, we crossed a bridge or a Rubicon and people said, okay, I guess the sky didn't fall in, and maybe we could do more. And so, you know, it was a bit of a journey to kind of take the company through it, but probably my team in particular helped a lot with that. And then the other thing that really changed in the kind of early 2000s, or 2010, 2011, 2012 was just recognizing that also in the cloud world, you could be very successful if all your customers only use Linux and open source. Yeah. Because the business model did also change. change. And now people are paying for compute, for resources, for services, for, you know, all the

add-the-ups fractions if you needed. And we also then recognized at the time that if you didn't really have developers' hearts and minds, you know, they weren't going to pay any attention to the cloud platform you put out or the tools you put out or the databases you put out. And so, you know, we kind of went through the shift over a couple years where I think both culturally we kind of brought the company along of like, hey, this is not scary. this is good. And then also business model-wise,

we had permission to kind of experiment and take risks where you could say, okay, let's make it free or let's make it open source. Which leads us into Visual Studio code. In 2015, if you would have asked me like,

you know, what is unlikely to happen? I would have said like that people use more of Microsoft's ID, which was Visual Studio again. You still had to pay a bunch of money. It was amazing. I came from that world.

But when I moved to new companies, they were like, let's use open source, let's use free stuff. We use Atom or Sublime or maybe. we might have paid for jet brains, but people usually like to use a worse experience,

but it was open source, hackable. And then out of seemingly nowhere, VS code came out, which is it's free to use. There's no, like, tricky things around it. And it just felt, again, a bit incredible to me because just knowing how Microsoft used to base their all developer business on pay

for quality tools, it just seemed impossible. How did that happen inside? What was it thinking? Now, of course, most developers use, Vs code or a fork of VS code. Yeah, so I'd been out of the developer division when I took over Azure. So from

2011 to say 2014, I hadn't been in the developer division. I've been focused on Azure. And then when Sate took over a CEO in 2014, the same day I kind of took over his old job. And that included dev-div.

And so that kind of came back into my world. And I think one of the things that we did in the early days, of 2014 was I kind of just looked around and said, you know, I think we have an opportunity to make a couple of choices that will be bold and aggressive that give us a shot to ruin relevance with developers of the world. And if we don't, we're going to be on an iceberg that's going to slowly melt.

And at some point, we're going to be swimming. And so, you know, we kind of had a set of meetings in, you know, in spring of 2014 and kind of on the whiteboard, let's be bold and came up with kind of three big things. We said, okay, let's, what can we do to become more relevant? The first one was we actually introduced a community edition of Visual Studio. So previously, if you wanted to like use Visual Studio and take advantage of the features that customers loved, you had to pay a minimum of about $1,000 to do it. And we said, okay, let's make it free.

And, you know, it was, it was scary. for a lot of people at the time. But we said, look, we can make it for small projects, for startups, for, you know, independent developers that want to build something. And let's make the full feature set available. And so that was, you know, decision number one. And decision number two is let's open source.net.

And let's make it cross-platform. With mono. And it was less with mono. We actually took our base library. Oh, sorry, sorry. say mono was before, yeah. Mono was before. Yeah, because there's no alternative.

And now there's no need for mono. And then we said, let's open source it and do it right. Yeah. Not meaning just open source where, you know, where we can contribute code. But like, no, true open source. We want the community to contribute code and do it under the right license and put it on GitHub. And, yeah, that was big decision number two. And we make it and have a great Linux and Mac port and make them first class.

is that was going to decision number two. And then decision number three was, as much as we love Visual Studio, the IDE, let's also recognize increasingly web developers and those that are not using a compiled language are looking for something that's much more of a lightweight code-optimized editor. And there was a great project that had been started.

It was basically a web-based editor, written in Node, written in TypeScript, but you ran it in a Vs Online, I think is what we called it. Oh, yeah, VS Online, yes. And it was great technology, but at the time, people weren't really looking to write code in a browser. And people would say, it's great if I want to edit five or six lines of code. But like, it's not a, you know, it doesn't have a debugger, it doesn't even tell sense. It doesn't, you know, it wouldn't scale for a large project.

And, you know, we said, what if, you know, I think I kind of said, why don't you take this? And is there a way that you could package it up in a Mac and Windows and Linux shell and add file system support? And why don't we take this open sort debugger we're about to do in dot net and port it and make it work with it? And really don't have a project system was kind of one of the mantras and really focus on streamlining editing. And let's make it open source. and the three different decisions we made, and we kind of made all those decisions, I think, in about an hour and a half.

So it was a good meeting. That was good one. And honestly, if you asked, what was the risk probability of each one succeeding? I thought the first one, which is making the tools free, was going to definitely drive more developer usage and whether it was going to destroy the Visual Studio revenue,

I don't know, but I said, like, let's take that risk. I think the dotnet being open source, I thought it would help. And it certainly did. And then the VS code one was the most, I would say, speculative, where I thought like, I think this could help, but I don't know. There's a lot of other editors out there. There was Adam.

There was sublime. There was, gosh, a couple other ones that were only Mac. And then later new ones are like new Wem, et cetera. Yeah. And so, you know, it was, but it was, you know, of the three decisions, they were all very big. I think the ones that we remember the most would be VS code and then the open sourcing at .net. And ironically, the one that I thought would have the biggest impact was probably the one that had the least impact, although it helped a tremendous amount.

Yeah, it just comes to tell you you can never know, even from the inside. But basically, I think later in that year, we kind of launched, announced all three. And, you know, that really, I think, helped us with our next kind of, I'll call it, rejuvenation with the developer community. And in some ways, also the VS Code, I remember doing events in 2015, 2016, with, a lot of the GitHub team, which was then an independent company. And, you know, VsCode also was that bridge that I think earned us the credibility to talk to GitHub and to be sort of in the developer community at large. And, you know, it was the bridge that kind of started the conversation around ultimately GitHub becoming part of Microsoft,

which, you know, if you went back to 2010, it was impossible. Impossible. It would be the most crazy thing. solution, suggestion ever. And then frankly, I think it, beyond the fact that the GitHub team wouldn't want have been bought, or be part of Microsoft, I think the developer community would have left immediately. And yet we, you know, fast forward to 2017, I think, was when we did the acquisition.

People were still had some concern, but they said, no, let's tell you what, you've earned the right, we're going to give you a chance. Yeah, there's a lot of skepticism as well. I agree. But, but yeah, and then now it brings us today, actually, to build, where co-pilot, you built by the GitHub team, we know the AI system with a bunch of Adan's capabilities is now open source as well together with VS code. Sure.

So not that we're here, just like looking ahead. We are where we are with lots of exciting new tools, lots of new ways to work, and I think we're going to figure out their agents are the hot thing. Personally, what are you excited about in terms of developer tools and also cloud? When you look at, may these be projects, may these be. be directions or things that need to be figured out? I think the thing I get excited most about is, certainly on the developer tool side, I do think this notion of having an agent that works with us, and that's some of the demos we showed

today and yesterday of, you know, how can you assign an issue in GitHub to your copilot? I think a lot of us have used, whether it's GitHub co-pilot, whether it's ChatGPT or N.35 co-pilot or a cursor. People are used to kind of a request response. model where you type something you get in a response immediately, and that's super powerful. So that's not going away. But this notion as the models get richer that you can just assign a task to effectively a coworker that is AI that can do something over maybe 10, 15, 20 minutes and then assign it back to you, I think that is super profound. And so the ability to say, hey, take this Figma or take this screenshot that I've sketched out, you know, turn it in,

do a nice HTML with CSS or, you know, create for me, you know, a Kubernetes deployment file and a basic microservice architecture that has these five dimensions and is connected to these three resources and make it scalable and secure, like assign it to the co-pilot, grab a coffee, come back and get something back. Yeah, that, I think, is really profound. And then how do you extend that so that in addition to development, a lot of kind of what you might think of as the operation tasks or SRE, things like, hey, is there anomaly detection in my logs? You know, is the performance dropping? Why? You know, can you ask it, what changed in the environment? What changed in the codebase? What's changed in terms of the user behavior? You know, how do you have an AI agent that can kind of

assist you in that? I think that's really about kind of giving every developer superpowers. And And, you know, it's kind of like the Marvel Ironman. You know, suddenly you have a suit that gives you kind of this amazing superpowers. You know, I think to some extent these types of co-pilots are going to do that. And then when you combine it with a cloud like Azure, where, you know, if you've got a great idea and you're going into, you know, business as a startup or whether you're a big company, you know, the ability to run it in 70 regions around the world. And, you know, certainly right now when you think that.

about whether it's tariffs or whether it's geopolitical, you know, this like, okay, how do I meet every country's local residency requirements on data? You know, cloud is the way to do that. Similarly, if you think about, you know, how do you target the growing markets in the world? Cloud is the way you do that. And then when you start thinking about, you know, how do I actually build my own AI application and take advantage of the latest models? How do I use diffusion or fine-tune my own model that's based on, say, my own data or do post-training, you know, the cloud's going to be the way you do that. And so I get excited in terms of when you take these sort of tools, you know, tying it back

to the beginning of the conversation, going back to MFC and Visual Basic, you know, I think this is the same level of kind of exponential jump, but probably even more profound in terms of the impact because it's not just development, it's also runtime. And then it's that feedback loop of, okay, now I get something out there. there. I'm learning from my user behavior. Let me improve it. And that's the thing that always motivates me is can you ultimately make someone more successful? And if you can allow them to take an idea and run with it faster and do it faster, better, cheaper. You know, you can change their life and you can bring to life this great idea. And if you can do that at scale, it's a fun

journey. And as closing, hearing about like AI colleagues can be a little scary for as engineers. I think it's a similarly big shift as back, if you think back in the 90s, oh, anyone can program with like dragging and dropping and doing similar stuff that I'm doing right now. What would your advice be for software engineer today, like, you know, mid-level or experience engineers who want to be the, you know, standout engineers of tomorrow on on how to approach and how to think about the fact that now they can, a lot of the work that they have been valuable for until now can potentially be offloaded.

It's a little bit, you see what I mean? It kind of messes with your mind a bit. It does. I mean, I think the thing I'd probably say, encourage is, like, I'm a big student of history. Like technology history, I've been part of and I have studies in them, but I also like to look back in, you know, the last 500 years of history and read lots of biographies.

And, you know, history is a way of repeating itself. And, you know, like, just going back to the development community for a while, I remember in the early 2000s, people would come to developer conferences and they would literally have t-shirts that said intelligent, Intellisense rots the mind. Oh. Because like no real developer. And it was a really good auto-complete. Oh, yeah. Like no real developer would use auto-complete was, you know, the statement at the time.

You know, real developers, you know, knew the name of the method and the parameters. Yeah. And, you know, similarly, I think, type-same. when Dotnet was introduced, you know, Cable's host developers were like, type safety is for wimps. I mean, like, you know, it's just, all you need is a Voidstar pointer and, you know,

if you got it wrong, you'd crash, but, you know, like, who needs type safety? You know, and similarly, I think, you know, even when JavaScript emerged in HTML5, you know, people would say like, well, you can't really let a real app with HTML and JavaScript. We had the thing, it's not a real language JavaScript. I remember this one.

And so, you know, all these parallels, And then going back to, you know, the days of debuggers, you know, real developers don't use debuggers or profilers. And so it's, you know, I've heard these things before where people say, you know, you can. And similarly with cloud, I've certainly heard lots of people say, well, you know, I can run my private cloud cheaper and faster and better than you can. It's like, okay, you know, most of those companies are not in business anymore. But sure, go for it. And so I do think, you know, that would be. my only kind of history lesson I'd pass on, which is generally these things are frightening

sometimes because they do make it look like, wow, could this automate me, could this replace my job. But ultimately, if you embrace the productivity, you suddenly discover you can do a lot more and you can deliver a lot more. And that is really what makes you valuable. It's not whether or not you know the name of the method and are proud that you remember the 18 parameters to it. It's It's, you know, what does the method do? And does the application calling the method accomplish some value? And so to the extent that we can leverage AI to kind of make developers more successful, I think we, in the limit, it's going to create more jobs, not less.

And I think ultimately it means those jobs are going to be higher paying because the business value you're delivering to the company or the startup or, you know, your app that you're building becomes even greater. So, you know, it's not always a perfectly linear progression, but I think that's, if I look, again, back in history, garbage collection, telosense, debuggers, type safety, even open source. You know, those are all things that were proven right and the naysayers were proven wrong over time. Yeah, and I guess it's just good to remind that open source, I think from the outside, we would not think it's scary. But from the inside, like Microsoft, it was, and it turned out pretty good. It worked out pretty well. So thank you very much, Scott. This was so much fun.

This was a lot of fun. Thanks so much for having me. Thanks to Scott for this trip down memory lane and for his advice on how software engineers can keep growing in an industry that changes as fast as software engineering does. For more details about Microsoft's developer tools evolution, check out our deep dive into Pragmatic Engineer, linked in the show notes below.

If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks, and see you in the next one.