Simplifying Dev Environments With the Right Tools

Developers often face challenges in setting up their development environments and experience a lot of time wasted on customization. In this episode of GOTO Unscripted, Julian Wood interviews Christian Heilmann, former principal program manager for developer tools at Microsoft. Christian emphasizes the need to break free from the traditional monolithic IDE and debugging tools by leveraging the power of web technology and standardizing extensions. By highlighting the importance of contextual tooling, where interfaces learn from user behavior and provide automated suggestions and simplified workflows, he aims to streamline the development process and make it more accessible, empowering developers to focus on writing code rather than navigating complex environments.

Introduction

Julian Wood: Welcome to another episode of "GOTO Unscripted." We're here at GOTO Copenhagen, and I'm super happy to be joined by Chris Heilmann. Chris, how are you today?

Christian Heilmann: I'm good. Just came in. Really enjoying the area. It's good fun to come back to Denmark and see how expensive things can be.

Julian Wood: Yes, absolutely. I mean, I live in London and I know you lived in London before, so when living in London, it's interesting to go to places that are more expensive,  In the whole global scheme of things. And no, we're not talking politics, but the currency has changed recently, so things are more expensive here.

Christian Heilmann: But everything works. That's the really nice thing here as well.

Julian Wood: I know. No, it's lovely.

Christian Heilmann: It's easy to get around. Even if you don't speak the language, it's just signatures, really easy to understand. It's good fun..

Julian Wood: It's embarrassing for me, because my Danish is obviously terrible. It's incredible how, not just how well Danish people speak English, but how good they are at it.

Christian Heilmann: It's unfortunate. I mean, as an English person, you never get a chance to actually learn another language, because as soon as you speak English, especially with British accent, people wanna talk to you in English.

Julian Wood: They wanna practice.

Christian Heilmann: They don't practice their own language with you. They would just wanna talk to you. That's really unfortunate.

Julian Wood: Well, we could be talking on a travel guide, which we could wax on lyrical forever. But I know your passion is developer tools and browsers. Tell us about what your sort of current thinking, and then what you do.

Christian Heilmann: I'm a principal program manager for developer tools in the Edge browser in Microsoft. And that's a Chromium browser, so that's the same that powers Brave, Chrome, Vivaldi, all the others that are based on it, and also all the Electron apps out there, and all the bits and bobs. We really got a deep dive into that code base, and changed it around a bit, and did some things to the developer tools that we thought were quite not there yet. For example, we made them accessible to people who can't use a mouse, who can't see. We made them localizable in other languages. And above all, I want them to break out of that black box. I want to make it better for developers to go from, to not just context switch all the time. Right now, we actually, we code, then we go and deploy it on the command line, and then we go to the browser, debug things, and all the changes that we do in the browser are lost. That's something that I found really, really wasteful and really, really weird.

Also, if you give people three different contexts to work in, they're gonna spend a lot of time customizing each of them, rather than writing code. That's the other thing that I didn't like. What I loved is that the Visual Studio Code editor is also based on Chromium, so we basically have the same codebase. What we wanted to do was bring the developer tools inside Visual Studio Code, and also the terminal in Visual Studio Code, and version controlling, so you don't have to jump between all these tools all the time. But at the same time, we didn't wanna build another IDE. We didn't wanna build the new Xcode, or Visual Studio, that's 16 Gig of installation, and we wanna keep it interchangeable with smaller components.

And I think we succeeded quite well with that, doing an extension. I'm gonna talk about that tomorrow as well. And I think that's just the tip of the iceberg. I think it's gonna be interesting what services we can do in the future to give developers the chance to not do the same things over and over again. The automation that we do for our services, for our servers, for our APIs, we could do for developers as well. But it's a weird thing because you do something for developers and they're always quite wary about it, like, "Don't do it for me." But then, once they use it, they're like, "Oh, my god. How did I work without that?"

Breaking the Monolith: Rethinking IDEs and Debugging Tools 

Julian Wood: It's a very interesting point because I think developers are very wedded to their IDE. And in days gone by, I'm not a historical Linux person, but the Emacs versus Vim debates, and how all that config was set up, now that is now transported into VS Code, which I use and absolutely love. It is interesting how it's not just the coding environment, but the development practices that people are very insistent on when they're using their IDE. I mean, I work with AWS, with a cloud environment, and how people sometimes struggle to reimagine how they can use their IDEs to interact with the cloud or interact with other kinds of services where they want to do everything locally, yet that means they maybe miss out on some of the advanced features that other services can provide.

Christian Heilmann: For sure. And also setting up their own computer all the time is really messing it up. I mean, as a program manager, when you have to work on five different projects that all have different technical setups, my laptops are a mess. I'd rather use a virtual machine to set these things up and do that. I love that we have systems like Live Sharing, where actually one person can set up their editor, and share with another person and they can just code with them without actually having to set up theirs the same way. Or you can do even the service that is now coming out where you can actually set up your editor at home, you can go to the cafe and keep working in your editor, with all the extensions and everything installed, rather than having to install it on a laptop that you have with you in a cafe. Seems like a first-world problem, but at the same time, syncing machines is still a big thing for developers where we waste a lot of time. We talked a bit about that earlier. We had just had interns, and it took us five days to get them all set up so they can start coding. We should be better than that. It should not need to have that much customization of the machine itself for somebody to get started.

Julian Wood: Is your sort of current thinking that people have a lot of different tools, and you want to aggregate them all in something like VS Code? Or should people be removing tools and changing their practices? Or how do you see sort of developers evolving to be more efficient, yet have a simpler environment?

Christian Heilmann: I wanna break up the monolithic idea of IDEs and debugging tools. We have an IDE, we have an editor, we have a debugging environment, we have a browser. These are all the same things. They're all made up of components as well. You could use the developer tools inside your editor. You could use the editor inside the developer tools, which we already do in the Sources panel, or even the Console is quite an editor in itself. You can take any browser and turn it into an editor with Visual Studio Code dot dev, or GitHub Codespaces, where any GitHub repo, you press the full stop button, and Visual Studio Code will open with that repository already open for you. Rather than you having to clone it down on your machine, open it there, you can do that on an iPad, you can do that on any machine out there. And I think that understanding that these tools that used to be written in C# and Java and everything are actually written in web technology as well, and thus interchangeable and mixable is something that is really exciting to me because I always found the web to be like a remix platform to me. And it was always about content, but it's also about functionality and tooling. I think that we could be doing much better, and making them much more lightweight, rather than these huge, monolithic things you have to install. And nobody wants to do that any longer.

Standardizing Extensions: Streamlining the Developer Experience

Julian Wood: Is the lightweight thinking using VS Code extensions and that kind of example or there are other ways that you can think of that would help?

Christian Heilmann: I think VS Code is a very good example because it started as one good editor. And the rest was basically you make it the editor that you want to have. It could be a JavaScript environment, it could be a Python environment, could be a Ruby environment, or whatever you wanna do. They spent the most time making a really good editor, and a really good extension platform. And that's something that is actually missing for a lot of tools out there. Most browser extension platforms are not as good as they could be. Most IDEs allow you to write extensions with an own SDK or something like that, rather than just as a manifest and some HTML and CSS. That should be enough nowadays to actually make an app. PWAs show that. But it's not in that space yet. It's still the, like, "Oh, this is the editor, and if you wanna extend it, you have to learn that API," rather than having standardized as well.

I'm very happy that we getting better at standardizing extensions as well, for the web, on different browsers. That's something W3C has been taking on lately in more earnest than before as well. And I think that's a really good way to get to an environment where I only need to have what I have at the time. My biggest bugbear right now with my job is the developer tools in Chromium have been growing constantly for 10 years, and it's a typically engineering-led project, like, "Oh, I need this tool. Let's put it in there. I need this tool. Let's put another panel in there and hide it behind a door that says 'Beware of the Leopard.'" And trying to find the thing navigating through it and doing user testing on developer tools is absolutely atrocious. People use 3 of the 37 tools because they can't find the other ones and don't know what they're doing. We should be better in UX and UI for developers, and not just expect, as we talked about earlier, that everybody just wants a command line, and that's all they need. To make developers more efficient, I think it makes sense to see them as users, and not just as somebody that builds software.

Julian Wood: And I suppose feature creep must be a continual thing you're battling specifically in an IDE, which is targeting, I suppose, every developer on the planet, with their own unique and interesting needs.

Christian Heilmann: And, of course, as an open-source project as well, it's easy to extend it. And, I mean, most people underestimate that 90% of your work as an open-source maintainer is maintaining your audience and maintaining your community, rather than the code. You have to make sure that everything that comes in is in a certain quality. You have to make sure that people just don't put things in. You have to maintain the hierarchy of needs in there as well. It's kind of an interesting thing how we always think developers are these nerds in the corner that don't need human things, but we are very much human because we need more developers, for starters.

If we don't make it as exciting as any other interface that we build to start becoming a developer, then of course, people will not want to understand it. If I show somebody a command line and say  "Copy and paste these 15 things in that you don't understand," they're not gonna get started. If you give them  "Here's three buttons to get started, and this is some sample code," and then they get more interested into it. Most platforms do a good job with that, like AWS, and Azure as well. We all have these dashboards, where people can get started, and we give them a sample code, rather than saying  "Hey, you gotta learn the whole API before you even get started." That's something that we don't want to do any longer.

Contextual Tooling: Empowering agile software development with IDE

Julian Wood: And I suppose that paved path of different journeys that you can learn different services, and there's so many different services out there, and people are gonna have different use cases and different ways of exploring it. And you need to be able to expose that. And I suppose bringing that closer to the IDE, that some of that discovery can happen actually within the IDE, is super important. I'm thinking even from an AWS perspective, AWS tools for Visual Studio functionality keep getting added there all the time, and you can invoke a Lambda function and, "Oh, wow, the logs just tailback and they just appear there." And so that kind of visualization and functionality within your IDE, as you were saying earlier, you don't have to context switch and then integrate with other services, is, I think very powerful, and trying to trim it down, so people are not overwhelmed.

Christian Heilmann: I like the idea of also of interfaces learning from my usage. I mean, I would love to say any IDE that I do the same steps five times and it says  "Hey, do you wanna have a button to automate that? We realized five times in a row you did the same five steps. Do you wanna have a script for that? We can generate a script for you, Automator, like on macOS does something like that." But we're still just scratching the surface on these things. The interfaces are still like we are... I think, mid-'90s, we came up with a tabbed interface, and we said "This is what everybody wants," but not necessarily any longer. We might, actually, we can slim down these things and make them easier. And I think Apple has done some good things in the past where they said "Hey, burning a CD is basically a button, "Burn CD," and not  "Here's the 6,000 things to learn about what the format of a CD," what a Joliet format is, and these kind of things. Nobody wants that.

Julian Wood: Well, it's even the ribbon bar in Word is dramatically simplified because you don't need to have everything visible all the time.

Christian Heilmann: Contextual tooling is super important, I think. Giving you only the tool that you need at that moment for that task. And this is where I'm also very much pushing the developer tools in the browser right now to get out of the browser, on this sidebar. We found that emulation device emulation, that is in that, so we can simulate mobile phones, you can simulate different responsive designs, we found that a lot of people are using that that are not developers, and for nefarious and weird reasons. Sometimes you're not allowed to upload something to a website when you don't use a phone app, but you can simulate a phone in your browser and then you can upload from your desktop. We found there is a whole audience out there for these tools, for the functionality of these tools, but the interface and the integration are completely overwhelming them, so they don't use it. That's kind of sad that we have that much great code and functionality in there and people don't find it. I think there's an interesting concept in the near future where our interfaces should apply to the needs of the user, rather than just offer them everything and hope they find out their way how to get around it.

Automating Code with AI: The Future of Development

Julian Wood: It's interesting. And I know you've also been speaking about code generation, and I know you've got a big history in Node.js as well, and Node.js's history was all about making coding more accessible and successful for people. What are your thoughts on the actual coding part of, be it a browser within an IDE, how that can advance?

Christian Heilmann: Well, I'm very much happy with the idea of machine learning-aided autocompletion that we have right now. GitHub Copilot came out. And then the Amazon CodeWhisperer came. There's a few IDEs that come out right now that actually automate code for you. And I talked about this earlier this morning. It's fascinating how fast that Gartner graph of...

Julian Wood: The hype cycle.

Christian Heilmann: ...had the hype curve. We did that with a week with that stuff. First of all, it's "Oh, my god, this will make developers obsolete." And it also means that big corporations just wanna scrape the web for content and use the code. And then the first people started prodding the project and basically, it's like, "It's showing insecure code. It's showing terrible code. I would never do it that way." And then the problem is any machine learning-based system gets better with usage. Of course, it will give you random results up front, but the more you use it, the more it actually mimics your own development state and development style. I'm really fascinated by having used GitHub Copilot for a year now, or how long it is, I don't know. But, I mean, I get these autocompletion things that I would write that way. And, of course, I've written them half a year ago that way, and I would write them again this way, and I would write them by hand, completely wasting my time. But as the machine is actually seeing all my other code on my computer and in my GitHub repo, it knows what I want to write. It actually gives me an auto-completion.

And saying that developers become obsolete because of machine learning autocompletion is a bit like saying writers become obsolete because Word just gives you underlines when you write something wrong. I don't want as a developer to do the scaffolding all the time. I don't wanna write the same code all the time. I wanna get the stuff out of the way and get to the meaty and interesting bits that we have to write code from time to time. And we cannot let the machine write the code itself, because it still needs a human to actually check what's going on there. And what I love about these systems is the more I use them, the better the code gets. You're basically saying "Okay, this is not what I want, and it should go down the list. This is what I use, and it should go up the list." And now, think about a product team of many developers. They're all using that system. And this way, all of a sudden, automatically you would come up with a code standard and you would come up with a reusable code library because people actually teach the machine, the whole team teaches the machine, what the team would need.

And that's, I think it's a very, very interesting thing because one of the biggest problems I have ever seen is consistency in teams. You cannot enforce a code standard on people. They hate it. And they hate it with good reason. And we're all very opinionated people. We're very happy to point out why that thing is not good. But if we keep using a system, and a system actually monitors what we do, and gives us that autocompletion that feels good because, "Oh, I would have done that anyways, and now I don't have to type those five lines," that would also automatically generate a code standard and a reusable components library for you.

Julian Wood: Which is evolving.

Christian Heilmann: Yeah.

Using AI-Driven Code Generation and Real-Time Analysis

Julian Wood: I think the code generation, as an assistant, and it's not... I also, always wanna add that it's writing the code for you, but it's a suggestion for writing the code for you, and it still needs a human to check it. And I was astounded looking at Amazon CodeWhisperer, where it's not about, oh, well, just doing autocomplete and checking your variables and everything. You write a comment in your code, saying, "Oh, I want to pull something from an S3 bucket," or that kind of thing, and from your code comment, it then infers, "Oh, that's what I want to write." And it gives a selection of some code samples that you can use. That is just amazing. And never mind me, with sometimes my poor coding practices and bracket matching and which variables you need.

The code sample is there, and I think it just makes it so much more accessible for even people who are learning about it, or from people who are learning about it. Write a code comment, and the code is just gonna appear there, and then you can iterate and do it. Your best practices, your input sanitization is gonna be there, and then also for your more advanced programmers to be able to use, as you say, that continuously evolving team standards and organizational standards are just gonna be enhanced in code. And it's while you're writing your code. It's not in a CI/CD pipeline, where 5 steps away and 10 minutes away, it says, "Oh, well, this is not... Your code example doesn't comply with our practices." As you write your code, it's just telling you, "No, this is the way we need it."

Christian Heilmann: We had a step before that, where we integrated webhint into the Visual Studio Code extension. In the browser, you have this issues panel that any website, it shows you  here's accessibility issues, here's performance issues, and so on and so forth. And people actually like that, because developers like it. But I had product managers complain to us that we shouldn't show these things because it shows the bad quality of the product and they don't have time to fix it. And I'm like, "Well, we cannot block it from your use." That makes no sense.

Julian Wood: You can't hide the bad stuff.

Christian Heilmann: You have to fix it. And these tools are now available as live analysis in your code as well. While you're writing something wrong, it actually gives you a squiggly underline, much like when you write something wrong in Word, and you can then automatically get it fixed for you, or you get explanations why it's an issue when you hover over it. And I think that's also another point that we have been doing not well the last few years. We always write great documentation, we give talks, we go to conferences, and we give workshops, but in our IDE, while we're doing it, that knowledge should be immediately available to us. And that it already is. It's, in this case, in a very obvious fashion, because it actually is a linter, and it tells you "That's wrong, and you should do it that way, and here's because why." And I think that "because why" is very important, because we just say it's wrong, it's really frustrating. Or, in the inferred way, if the code that gets generated by a machine learning system, then it's already not an issue because the machine learned how to write good code, as you said, like with input sanitization already being built in there.

That's something that I think is very exciting to see, to make people more efficient, that they're actually unlearning bad things while they're writing code. As I said, generating from a comment the rest of the code, I also found the thing in GitHub Copilot in the labs right now, it's not in the main thing yet, where you can highlight a piece of code and says  "Explain to me in English what that does." And that is just incredible because that actually means you don't have a junior developer that has to actually call you up and say "Hey, what does that thing do?" I mean, it's already a warning sign if people don't know what the code does. But I think just having a machine explain to you why something is written that way, and I've done that with Copilot, with a lot of back-end developers that hate CSS. And I love CSS to bits. Basically, when you highlight CSS, it explains to you why something was written in CSS the way it was.

And the CSS syntax is weird to somebody who comes from a higher language. I love that basically, I don't have these emails any longer where I have to defend CSS to people. They can just highlight it and say  "Explain it to me," and then they understand, "Oh, that's why it does that." It's really a natural language processing. It really says, "This is using that right-hand weird pixel percentage because it needs to have a 16 by 9 aspect ratio." And so it knows all the tricks, and sometimes it even showed you URLs of blog posts that explain that kind of thing. And I think that's incredible that we have this on our fingertips now. And it feels always so insincere when people say "Oh, it feels like this is odd because this means we're getting lazy as developers." And I'm like, "Let's face it, 90% of the time, when we get stuck, we go to Stack Overflow, we copy and paste the first result, we change some numbers around, and when nothing breaks, we submit it." The amount of...

Julian Wood: That's my coding. Have you been watching my coding?

Christian Heilmann: Because the amount of people, the people that keep saying they write new code all the time, I don't buy it. I mean, I've been writing code for 25 years, and I've been doing my own snippets libraries, my own reusable components. Then, later on, we had component libraries. We're always about reuse, but at the same time, we're just basically  "Oh, if the machine tells me that something is going on there," it feels like, "Oh, I should be able to read that up in Stack Overflow and copy and paste it by hand." How is that different? But, then again, I just got a new car that has all kinds of fancy things, and it does see you're not driving in the middle of the lane, and it actually shakes my steering wheel, and it drives me nuts. But at the same time, I will not drive not in the middle of the lane anymore, because it annoys me. I guess if the machine tells you that you're wrong, it annoys you first of all, but then you get better at it.

Leveraging Browser-Based Tools for Code Generation

Julian Wood: You're obviously doing a lot of work within the Edge browser, using Chromium, and with extensions, with VS, Visual Studio Code, and bringing the focus back into the IDE in terms of development, avoiding context switching. We've been talking about machine learning. If you had to have your crystal ball, and, in a way, it's unfair talking to you, since you're actually building the crystal ball of the future, how do you see this playing out? Or what's the sort of next steps that people can look forward to?

Christian Heilmann: I would look forward to, not necessarily making it only easier for developers, but for everybody out there. I kind of feel it's so weird that we have a lot of tooling that is in the browser and off the web. It's written in CSS, JavaScript, and HTML, and the tools are written in them themselves, and the output of it is written in that. My favorite example is Figma. Figma is basically, was eye-opening to me, and some of the others as well that are similar, that are actually in the browser. Back in the days when I was still an HTML developer, I got, like, Illustrator files or Photoshop files and then I had to find out somehow how to turn that into CSS. But as Figma and other systems are already in the browser, and sometimes some of them are canvas-based, so they're not, but they're already generating web code, and you can right-click and copy the CSS, why do we still have that extra step to write code from that?

There's a few systems, a few startups that I'm playing with that I'm talking to as well, that actually generate code from Figma. Of course, this is not gonna be perfect code for final production. But for throwaway click-throughs, for throwaway reusability, it's great. And, I mean, I'd rather have a React component generated from the design that the proper React developer then can actually optimize and make better, than just have a design, and they have to rewrite from scratch to make React do the rendering that the designer, who's got a better eye for it, and a better user research background, has done already. That job has already been done, and it's being wasted again. Much like when I said earlier, when you do any changes in the developer tools, they're not actually changing your source code. But with the plugin that we've written, or the extension that we've written, it does it now. I think, from graphical user interface or from graphical design to final product, this should become much, much shorter. And I think it will be in the very near future because there's a lot of good stuff happening in that place.

Julian Wood: I think the accessibility, everyone's talking about a lack of software engineers in the world. And I think that's very acute. One of the most powerful and probably highly scalable and most-used software development platforms is macros in Excel. And you think how many... I've worked in financial institutions where it would be horrific if audit and compliance people realize how much of the world runs on Excel. But why? Because it's really simple for business people to code their business processes in something like Excel. And it's really accessible right whether it is. I see and understand your comment of trying to make coding as accessible to everybody.

Christian Heilmann: Lately, I've seen content management systems based on Google Docs, and also on Word, of course. And, I mean, that makes total sense. Why would anybody who has no idea how to structure a document in HTML or in Markdown have to write it in Markdown or in HTML? Use the stuff that people are already using, and then generate what you need out of it. I remember, god, in 2001 or something, I wrote a plugin for Word to actually generate clean HTML rather than the...

Julian Wood: XML HTML.

Christian Heilmann: ...the MHTML that was the part of Outlook back then. Back then there was a real issue. It was interesting when you talked about accessibility, because that's a big thing for me as well making the developer tools available for everybody out there, and making them available for people that cannot see well and cannot see contrast, that cannot use a mouse, makes it so much better for everybody else as well. It's incredible. I mean, my favorite example with that is Photoshop. Photoshop back then had a problem that it was mouse-based only, and keyboard users that basically couldn't use a mouse or couldn't see the arrow were basically asking, "What's going on there?" So they added keyboard support, and all of a sudden, I could move a selection in Photoshop pixel-by-pixel, which I could not do with my mouse. As I now had the keyboard support that was needed for several people out there, the whole product got better for everybody else out there as well. I think it's very exciting to understand that people of all needs are gonna use your product, and not only the one with the coolest, fastest machines that can see perfectly. I mean, we're all getting older, so I realize it myself as well.

Julian Wood: Definitely. I'm gonna have to put my glasses on. And in parts of the world where you've got less bandwidth and you've got less computing power, which also has a sustainability aspect to it, to try and make things simpler to use.

Well, Chris, it's been amazing talking to you today, to really speak to someone who's at the forefront of IDE development and browser development. It's a pleasure. Thanks so much for joining us here at "GOTO Unscripted." It's been in Copenhagen. It's been fascinating to speak to all the speakers, and learn from the community as well, and see how we can all make our jobs better and brighter as we learn more things.

Christian Heilmann: And talk to each other, teach each other. That's the best way to do it. If you really wanna learn something, teach somebody else it, because that means you have to understand it first.

Julian Wood: That's literally my job, and I think I'm sometimes one page ahead of the book to try and help somebody else to explain that. Chris, how can people get hold of you? Sort of, any social media, or your book?

Christian Heilmann: I'm @codepo8 on Twitter. I'm christianheilmann.com is my blog, and Christian Heilmann on LinkedIn as well. That's basically the biggest ones. [inaudible 00:28:37] on email, I got Gmail at christianheilmann.com.

Julian Wood: Okay, excellent. Thank you very much.