In this episode, we talk about Visual Studio Code with, Jonathan Carter, principal program manager at Microsoft, and Cassidy Williams, director of developer experience at Netlify.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Nick Taylor is a lead software engineer with a focus on the front-end at Forem, the software that powers DEV. He does not get along with spiders.
Jonathan Carter is a project manager at Microsoft, and has had the privilege of working on a bunch of developer tools and services over the last 15 years (e.g. Visual Studio, ASP.NET, browser tools for IE, CodePush). He's passionate about developer productivity and collaboration, and in particular, helping to make it easier to contribute to projects, share ideas amongst your teams, the community, and supporting remote-first cultures.
Cassidy likes making memes, dreams, and software. But actually though, she's a Principal Developer Experience Engineer at Netlify, and makes developer-friendly content across the internet to help people learn and laugh.
[00:00:00] JC: The ecosystem is so strong because it’s actually built on top of web technologies and that makes it so accessible for other people. So that was definitely a bet that we took early on.
[00:00:23] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a Co-Founder of Forem.
[00:00:30] NT: And I'm Nick Taylor, Lead Software Engineer at Forem. Today, we’re talking about Visual Studio Code with Jonathan Carter, Principal Program Manager at Microsoft, and Cassidy Williams, Director of Developer Experience at Netlify. Thank you both for joining us.
[00:00:44] CW: Hey, thanks for having us.
[00:00:46] NT: Yeah, excited to be here.
[00:00:47] BH: Very excited to talk VS Code and all things developer experience as the topic is no doubt related. But before we get started, can we hear a little bit about both of your backgrounds as professionals in software development? And how about we start off with you, Cassidy?
[00:01:04] CW: Sure. I am currently at Netlify, mostly working with React and Next.js, and really just any technology they’ll let me use to improve the developer experience for developers using these frameworks and on the Netlify platform. And so that takes the form of writing tutorials, speaking on podcasts, writing blog posts, live streaming, that kind of stuff, and also just working on the Netlify product itself. And before this, I was teaching React full-time and I was an engineer full-time before that, and I’ve done various roles in dev advocacy and engineering throughout my career.
[00:01:42] NT: Okay. So what does your role as director of developer experience at Netlify look like? I know you switched to this role I think recently in the past month or so.
[00:01:50] CW: Yeah. Honestly, it didn’t change from when I was a principal engineer. I just have reports now. And so my group, we focus specifically on the developer ecosystem. And so we try to improve the developer ecosystem in ways where we say, “Okay, these open source projects are kind of a big deal or these ones are up and coming, these ones we need to fix the experience.” And we strategize based on that and then come up with content for those open source projects and stuff and write tutorials, blog posts, videos, et cetera, and just figure out how can we make that experience better for developers externally. And then internally we will work on the product and we’ll for example, say, “Okay, these particular things in serverless functions need to be improved because of how this framework uses them,” and that sort of thing. So it’s kind of a funky cross between user research and engineering and dev advocacy.
[00:02:48] BH: I’m curious how much time you in this role get to focus on small improvements versus overhaul proposals. I imagine it’s not just on you to make a call on an overhaul, but in terms of how you use your brain, focusing on listening to people and creating content, which helps the developer experience versus like the opportunity to make bigger changes that might break you out of a local paradigm, like a local maximum for developer experience.
[00:03:20] CW: It’s definitely a balance. I’d say that it leans more towards the former where I do tend to help individual developers more and groups more. And sometimes I might get on sales calls to see what pain points are and stuff, but they all kind of provide evidence for the bigger things. And so there’s a lot of small things that then lead up to the larger things. And so for example, we did a really big stretch of e-commerce improvements and being able to talk with a lot of customers about e-commerce, helping organize the Headless Commerce Summit, building with some of the new Shopify APIs, things like that. We’re able to see what pain points there might be. For example, even just this week, I finished building out this demo and I noticed that there were some kind of bumps in the road I had with serverless functions. And so I’ve been working with our serverless functions team to figure out how can we improve that experience overall so other developers who might not be as patient as me don’t have the same experiences.
[00:04:17] BH: Awesome. And Jonathan, I’d love to kind of like let you weigh in on that topic of like the small improvements versus wholesale changes a little bit as we get into your background. But first, can you tell us about what you do and how you got into where you are?
[00:04:34] JC: So I work at Microsoft. I'm within the Visual Studio Team. I’ve been at Microsoft for coming on 14 years, which is crazy to think about, because I never expected to be there more than like two or three, but I’ve worked on developer tools and platforms that entire time, almost always adjacent to the web as well. So I had joined the company and was working on ASP.NET. Before that I was a web developer. And so I was super excited to get to work on a new emerging, exciting web platform, have worked on mobile tooling. I’ve worked on the developer tools for Internet Explorer, which are now deprecated in favor of Chrome DevTools, which are amazing, but that was fun at the time. And then now, with the last few years, I’ve been working on a few things. One is GitHub Codespaces, trying to make it easier for folks to contribute to codebases and work from anywhere, and then I also focus a lot of my time on kind of collaboration tools and then the application of AI and ML to the developer experience. So my team works on something called IntelliCode. Before that, I did full-time ColdFusion Development in an older but fun times and PHP and built what seemed like 17 million CMSs when that was a hot industry back in the stone ages. So started my career as a developer, then got into kind of product management when I joined Microsoft. And that’s kind of what I’m still doing.
[00:06:05] NT: You mentioned Codespaces. So if you want to maybe just elaborate on what Codespaces is.
[00:06:11] JC: Yeah. Codespaces is an on-demand developer environment in the cloud. And then you can access that developer environment from your browser or using VS Code in your browser or VS Code desktop as well. We’re working on other clients that you can use such as Vim, but effectively its goal in life is to make it so easy for someone to contribute to a codebase or join a team or join a new company and kind of distill the traditional setup complexity down to a single button click, and then give you access to the cloud resources that you would need because maybe you need 32 cores to work on a complex project, but your laptop is a Chromebook or you want a more lightweight Apple M1 Air. So that’s effectively the crux of Codespaces, like how do we make set up and reading massive READMEs a thing of the past and then bring like the ubiquity and kind of developer experience of VS Code to folks in that cloud-based environment.
[00:07:18] BH: Jonathan, why don’t you kick us off with a high-level overview of what VS Code is for any of our listeners who just really never heard of it or don’t actually really know what the difference is between some of the alternatives?
[00:07:32] JC: So VS Code is a cross-platform editor that is open source, but really its focus is to be a lightweight text editor that can then be composed to be as rich or as simple as you need. Out of the box, it’s kind of focuses to nail really a few things. One is language offering experiences. So auto-completion, refactoring light bulbs, go-to definition, which in the past had been associated maybe more with larger IDEs or bigger tools. And so VS Code wanted to bring that level of language richness to an editor, but it also has integrated debugging as well as integrated version control. And those three things were actually kind of the original focus of how we wanted VS Code to be a boost forward in terms of productivity, beyond what people might typically associate with a text editor. That said, it tries to do not that much more beyond being really great at that kind of core set and then allow the ecosystem of extension authors because VS Code is very extendable to offer additional workflows or capabilities that then individual developers can choose to opt into to create kind of their own customized experience.
[00:09:02] NT: And to touch on that for those that might not be aware, the technologies that go into building Visual Studio Code are primarily web based. And I have a feeling that the initial team that worked on VS Code must have bet on web for the long game.
[00:09:18] JC: Yeah. So we very briefly mentioned Codespaces and how that provides VS Code in the browser. And from the very moment that the VS Code project was started, the team kind of always knew that betting on the web was the right thing to do. Not only for the distribution benefits of it, which we all appreciate, but also the prolific nature of the ecosystem of web developers. And so much of VS Code strength is its extension ecosystem, which a hundred percent, you look at MPM as another example, like the ecosystem is so strong because it’s actually built on top of web technologies and that makes it so accessible for other people. So that was definitely a bet that we took early on.
[00:10:07] BH: So Cassidy, when we talk about defining what VS Code is and what separates it from other environments and experiences, how would you sort of weigh in as a connoisseur of the developer experience, but less close to VS Code the way Jonathan is? How would you add on to this chat to sort of put VS Code in the context?
[00:10:28] CW: So I came to VS Code from Vim land. I was using Vim for a very long time and I was deep in that ecosystem. I had a whole setup going. It’s still open source. People still can use some of the plugins that I was using and stuff. And I was on a team that used VS Code so heavily at a new company I was working for and they were saying, “You know, you might want to try it.” And I was very snooty about it. And I was like, “Okay, fine. But I do love my Vim.” And so I did switch over and suddenly I was like, “Oh my gosh! What have I been missing?” Because when you install plugins in Vim, you can do anything, but you do have to really know what you’re doing and do some manipulation to get everything right. But then with VS Code, it’s so easy to add plugins. And like Jonathan was saying, the power in VS Code as an editor is the ecosystem of plugins and extensions. And the fact that I was able to say, “Oh, I can do like this GitLens and see who committed on each line. Oh, I can do this and do that.” Like every single plugin was just a quick click and it was done. I didn’t have to rebuild anything on my machine and I was able to install Vim mode so that way I could still type in the way I was comfortable, but have it built into VS Code. It was such a good developer experience that I had no reason to go back. I still occasionally open a file in Vim just because it’s fast, if I’m working from the terminal. But honestly, I’m all in on VS Code now.
[00:12:00] BH: So I think all of us are VS Code users in this conversation. Maybe Jonathan didn’t say that explicitly, but maybe I assume that’s the one you’re going to break out. I assume you’re not using JetBrains for your own work. But Cassidy came from Vim. And Nick, what did you work with before you got into VS Code?
[00:12:20] NT: Yeah. So about two thirds of my career so far has been in the Microsoft ecosystem. So Active Server Pages, ASP.NET. C#, all that stuff. SharePoint too, which I had to remove from my LinkedIn, but that’s another story.
[00:12:34] CW: Good times.
[00:12:36] NT: But my primary editor for the longest time was Visual Studio. And Jonathan touched on this, but in terms of web development, there’s been a pretty amazing debugger in Visual Studio and prior to Visual Studio, Visual Studio InterDev, which was tied tightly to Internet Explorer, but it was actually a really good debugging experience. So I was using that. And then also because I was doing .NET stuff, but I also dabbled in other editors. I forget the Mozilla Suite. There was SeaMonkey, I think, or there was an editor with the Mozilla Suite at some point. I forgot the name. I was using, shout out to Firebug, which kind of I think pioneered debugging tooling in the modern web ecosystem. That’s kind of where I came from.
[00:13:24] BH: That brings up Visual Studio for the first time in this discussion and to give context to all of this, it’s certainly in the name Visual Studio Code. Can we talk about what the difference is between these two products?
[00:13:36] JC: So I briefly mentioned the notion of an IDE when we were talking about VS Code. So folks might've heard this dichotomy of, “Oh, an IDE or a text editor.” And the definition of those is I think a little bit fuzzy. But at a high level, what an IDE is, is it stands for Integrated Developer Environment. That integrated part is very relevant because typically what it means in practice is that it’s a tool you install and it comes pre-bundled with everything you could possibly need to work on some type of application. So if I’m building C++, there might be a C++ IDE that I download and I have everything I need. I don’t need to think about an extension or doing a rebuild on my machine, as Cassidy mentioned. It’s kind of batteries included. And so Visual Studio is an IDE that is very focused on being the best developer experience for.NET and C++. And so commonly, if you talk with folks that are doing C# or F# or VB.NET or C++, it’s a very common tool in that ecosystem because it gives you everything you need from designers to rich debuggers without kind of putting the decision of how to get set up on a developer. Whereas as Cassidy was mentioning with VS Code, you install VS Code, and by default, it does a lot, but not that much because it’s trying to limit its opinion on what you as a developer want. And that’s kind of a characteristic of a text editor, which is why if you look on Twitter or DEV.to or any social network for developers, you see all the time people sharing, “These are the extensions I’m installing,” because that’s very much the step two after you install VS Code to go then configure it for yourself. So at a high level, VS is the IDE, it’s Windows only, very focused on .NET and C++ and then VS Code is in that text editor family of lightweight, but composable and very catered towards web technologies, scripting languages, cross platforms as well, like Go and Rust.
[00:15:52] CW: I used Visual Studio in college when I was doing C++. And when I first heard of VS Code, I was like, “Oh, no! That monster again.” So it was a very pleasant surprise when I realized they were very different.
[00:16:22] BH: Nick, since you migrated from Visual Studio to Visual Studio Code, along with sort of an adjustment in your specialization, how was that? Did VS Code help bring you into web development? You’re sort of more in the Microsoft Suite, how was that journey?
[00:16:41] NT: Well, I kind of made a conscious decision to move to just front end only in 2016. And so when I was working at this Microsoft shop that I was working on, which is full stack what I was doing, but we were working there. And in the early days, like Jonathan mentioned, it’s very extensible, but when I was using it, there were no extensions in Visual Studio Code. This came on, I can’t remember what year extensions or like even the ability to add an extension became available, but it wasn’t in 2016. I think it might’ve been 2017, maybe. So initially, it was pretty bare bones, but for the use case I had, which was primarily writing TypeScript and web dev, it fit well. But as soon as the ecosystem for extensions opened, like every developer, you got to, “Get me some fonts, get me this extension,” like all the things. And because I focused primarily on web-based technologies, it just really resonated with me. And it just got better and better. I know folks would use other editors, but I kind of stuck with it just because that’s what I ended up working with initially. I’m just happy the way it’s turned out. The ecosystem is so rich now. There’s extensions for themes and right now I’m using Sarah Drasner’s Fortnite theme, which is hilarious.
[00:18:02] CW: Nice! Same.
[00:18:04] NT: Yeah. It’s really nice. I think the thing that’s really cool about it is just how customizable it is really.
[00:18:11] BH: Cassidy, how much attention do you pay to VS Code as a platform for developer experience at Netlify? Do you pay attention for opportunities to invest into the plugin ecosystem as far as making your own developers and your developer ecosystem run more smoothly?
[00:18:33] CW: I don’t know what I’m allowed to talk about in terms of things that are coming out. So just know that I’m winking to everyone listening to the podcast and we’ll leave it with that.
[00:18:45] BH: So getting into comparing and contrasting VS Code and Vim, because Vim is still quite popular and Vim folks are probably not all jumping at the opportunity to get a whole new thing, even if there’s a plugin ecosystem, which can give a lot of Vim qualities. But what is it about Vim that would be very different from VS Code?
[00:19:10] CW: Honestly, so first of all, just the editing experience in general, you have to go into insert mode and then you’re also navigating and stuff and you don’t need to use your arrow keys if you’re in Vim. I don’t know why we subject ourselves to this, but we’re convinced that it makes us better because we don’t need arrows. So those whole modes of typing, that’s just not something you need in VS Code, unless you install the extension and then you can do that to your heart’s content. I know that I really like being able to navigate around without having to use a mouse. So the fact that I can jump to the end of the line, edit this, and then go back three words and do this and just kind of do quick commands to navigate around my codebase, that part is really, really nice. That being said, again, you can do that in VS Code. And so it’s not as much of a huge difference. I would say just running it from your terminal where you never have to navigate Windows. That part is really, really nice. I do like that there is just a terminal code command and so sometimes I’ll type out code. and it’ll open up the current folder that I’m in, in VS Code. And so that feels almost like it, but if I’m just like editing a quick string or a quick number or something in a file, I will almost always just use Vim because I don’t need to format it. I don’t need to do anything fancy. I’m just editing something small. Yeah. I think it’s just the feel of it being native or not. I like being able to know that I could SSH into any machine and do some Vim commands and be able to write something and then exit out and have it be a fully native experience. And I think that is probably a pretty big selling point for a lot of people still.
[00:20:48] BH: Yeah. And the folks that care about that are probably some of the last folks to maybe want to adopt VS Code and then there’s a whole swath of developers who never even consider SSH-ing into another machine. Right? So there’s going to be a matter of the type of work you’re doing.
[00:21:05] CW: Right. Exactly.
[00:21:07] NT: What would you say are potentially the biggest counter-arguments to somebody using VS Code maybe? What do people not like about it?
[00:21:16] CW: Jonathan might know this in deep detail compared to me, but I know for myself, if I open a really, really mega large file, it will definitely start to drag a little bit. But also, I should probably break my files up more. So a blessing and a curse, but there have definitely been times where, for example, I’ll volunteer to refactor some old file that is literally more than 10,000 lines of code. I don’t know why I do this to myself. But anyway, I’ll do that for a team or something. And doing that in VS Code has proven to be kind of slow in the past, but it has improved over time. So I can’t speak for it in the past six months. Luckily, I haven’t had to touch those kinds of files recently.
[00:22:03] JC: Yeah. I would almost venture to say if you’re having to touch that kind of file, the editor you’re using, it’s the least of your problems.
[00:22:09] CW: Oh yeah. Very true. Nightmares.
[00:22:14] JC: Yeah.
[00:22:14] BH: For me, this brings up how I got into VS Code. My path to VS Code was originally getting curious about the Atom Editor, which predates VS Code a little bit, or I’m not sure what the timeline is, but it rose to popularity with this idea of being hackable and extensible and web based. A lot of the same ideas. It was a GitHub thing. So I think the Atom versus VS Code, I don’t know, things must’ve died down in terms of the conflict once Microsoft acquired GitHub. I have to think that that like affected what resources went to Atom and really helped VS Code’s popularity. So I was very curious about Atom and into this idea, the flexible web-based stuff, the extensibility, the hackability. But Atom, like a few hundred lines of code seemed to make Atom stall. And VS Code for being a similarly, conceptual project immediately solved that problem for me. So I imagine that’s still a problem at a next level, but Atom had an issue with big files with a much, much smaller definition of what a big file was in those terms.
[00:23:29] JC: To that point, one of the other bets that the VS Code team made when they first introduced extensibility was that an extension was never going to get UI level access. And it was going to run in a separate process because it was super important that responsiveness of the editor couldn’t be impacted by some rogue extension that you got recommended on Twitter. And so when you install an extension with exceptions like themes and such, that’s in a separate process. And so there’s really not much it can do to hinder you. And then furthermore, with Atom, it was awesome because you could install an Atom extension that was like reaching into the DOM of the editor and doing God knows what, which was really cool. VS Code does not allow that. Right? It’s very much like a curated experience that offers up APIs that you can effectively declare capabilities and provide data, that tool then reflects kind of however it sees fit. And so that kind of gives that balance of hackability, but with stability as well. I mean, obviously, there’s caveats. I’m not saying that you can’t tank VS Code with an extension. But anyway, that was another bet that I think has been quite helpful for the growth of the ecosystem as well.
[00:24:52] NT: I know this isn’t a TypeScript podcast, but I’m bringing it up because I’ve heard so many folks before because TypeScript isn’t for everybody. Some people are pretty adamant about not using it, but it kind of makes me giggle sometimes because as we were talking about VS Code, it is web-based technologies. And one of those technologies is actually TypeScript. So all the IntelliSense and a lot of the refactoring tooling, it makes me chuckle because all of that is TypeScript doing that for you. So whenever I hear somebody say they don’t like TypeScript and they tell me they use VS Code, I just kind of go, “Oh, really?”
[00:25:30] CW: I like using TypeScript. I just don’t like writing it.
[00:25:33] NT: Yeah. I’m curious about your thoughts on using TypeScript for Visual Studio Code, Jonathan. That was another conscious decision, obviously. It was a new somewhat newer language. I think it came out in 2012, I believe. I'm not positive.
[00:27:48] BH: So can we talk about what VS Code is as technology and how it embeds elsewhere and how it sort of works into the ecosystem? So I understand that VS Code runs on a lower level engine that is a library that’s kind of more usable in different contexts, and if you want to provide a name to that and kind of get into the VS Code open source engine a little bit, and then maybe talk about how VS Code plugs into Codespaces as part of that stack and is also generally available and integratable in non-Microsoft led projects and it’s sort of part of a few different types of ecosystems.
[00:28:33] JC: So I think maybe you were alluding to this thing called Monaco, which is the core editor that powers VS Code. And that was actually the original project, like way before VS Code was a thing. The team built Monaco, which was a web-based text editor. And that’s an open source project. You see it all over the place embedded into other developer tools and services. because it’s, “Why rewrite the wheel there?” So Monaco was literally like just the editor. And so when you think of VS Code, it introduces the tab strip with debuggers and search and version control. And all of that is added on top of Monaco as part of VS Code, which is itself as we’ve discussed, a web application, then distributed as an electron app. VS Code itself is open source as well. So if you go to GitHub, whack Microsoft, whack VS Code, that’s that codebase. Monaco is a separate repository. So that’s kind of that lineage. In terms of Codespaces, Codespaces was interesting or the notion of kind of some of the remote experiences in VS Code as well because we have support for connecting VS Code to an SSH server, to WSL, to a Docker container. And all of those are manifestations of over the last few years, we decoupled the user interface of VS Code and the backend of VS Code such that you could be running that backend in arbitrary remote contexts and then connect to it from different clients as well. So in the case of Codespaces, we’re spinning up a container in the cloud, starting the VS Code server, which is the backend that is able to run extensions and handle editing buffers and a lot of the complexity of kind of the experience. And then you’re connecting to that from a client, which is either in the web browser or the desktop client. So that’s kind of some of the makeup of kind of VS Code and how those various pieces contribute. You mentioned a little bit about like other tools using it. Folks probably see Gitpod and other great developer services that are also taking advantage of VS Code and/or Monaco. CodeSandbox is another good one. So that’s another benefit of Monaco and VS Code is there’s quite a strong ubiquity in the ecosystem as a whole that helps people feel some level of familiarity when they use one tool versus the other because of the fact that Monaco and VS Code are open source, it’s enabled that ubiquity to exist.
[00:31:26] BH: Codespaces itself has come a long way. Do you want to speak to what’s new and interesting in Codespaces as far as what’s recently launched and what’s coming up?
[00:31:36] JC: Yeah. The big news was we released that as general availability for GitHub users. That was very exciting. As I mentioned earlier in the call, the team we’d been working on that for quite a while. And so there’s a really nice emotional response to finally shipping something and launching it. So that was exciting for everybody. So that is currently available to GitHub users in the team and enterprise skews. So yeah, we’re just spending a lot of time, working with folks who are, I was talking with Nick earlier about getting the Forem codebase onboard to the Codespaces. We’re just really excited to be working with folks to learn how we can push the onboarding experience, even farther to make contributions to projects as simple as possible. In addition to the Codespaces’ GA launch, we also launched a pretty cool thing, which we’re kind of referring to right now as the GitHub.dev Web Editor, where on GitHub, you can go to any repo or pull request or a file and hit the dot key and that will transition you into VS Code in the web in a serverless mode. So there’s no compute there. But in your browser, you are able to leverage the editor and we’re now engaging with the extension ecosystem to get more and more extensions to be able to run in a browser-only context, which is pretty cool because we’re only at the beginning of what potential is there for folks to achieve with that experience.
[00:33:15] NT: I can see the extensions being in that editor very beneficial. I can think of stuff like linting and formatting is typically when I would review a PR. And if I’m on the original GitHub site, if you’re going through the code and you want to suggest something, you type it out maybe with the suggestion mark down, but you can’t always have it auto format. We use Prettier, like a lot of folks use Prettier for web development. So if we had like the Prettier extension, for example, it would auto format when I’m reviewing the PR in that editor remote. So I can definitely see that being really exciting. The other thing I think that’s neat, because I’m a big fan of Live Share preparing and I think it works with Codespaces as well. You don’t have to be in the desktop editor to use it. Is that right?
[00:34:03] JC: That is correct. It works in Codespaces. In fact, one of the benefits of Codespaces is that it’s like a hundred percent full fidelity VS Code. And so any extension with like a very small set of exceptions will work in that context. That said, in that GitHub.dev browser-only context, there is no cloud backed compute. And so we are actually working on Live Share support for that right now, which is kind of neat because a lot of times when people think of Live Share, they kind of say, “Oh, is that Google Docs for developers?” Well, once you can go to any GitHub repo, hit a dot and then collaborate on a file directly from your browser with other people, that kind of starts to get towards that vision a little bit. We talked about how Atom was a hackable editor. Well, GitHub.dev and being able to hit dot and then install extensions almost kind of starts to provide a hackable surface for GitHub that developers haven’t had before. Where if you didn’t like the way that GitHub rendered AsciiDoc or LaTeX or some other file, they’ll build an extension and change it, which is pretty neat.
[00:35:15] BH: So as we talk about VS Code and what VS Code brought to the developer experience, how it appealed to web developers in a new way, how it leaned on web technology for its ubiquity, Cassidy, I’m wondering what your feelings are as far as what’s next in kind of necessary innovations in this space for overall developer experience? So what builds on some of the ideas of VS Code and what are you thinking about or your team in general about what’s next?
[00:35:49] CW: I think the big spaces that are growing a ton right now are developer tooling and productivity tooling. And VS Code is kind of a nice overlap of both. And I’ve seen so many people who have said, “I write all of my notes in VS Code and here’s how,” and stuff like that. And I very often see people build their own tools within VS Code and they build whole businesses based on plugins that they’ve made for editors and stuff. And so I think a lot of the innovations, they might branch off of VS Code or they might look a lot like VS Code because they are in developer tooling or productivity tooling spots.
[00:36:26] BH: So it’s a real feeling that VS Code, this specific platform is important as a platform and then even the idea of like VS Code and its siblings as a platform for future innovation.
[00:36:42] CW: Making something that is simple and extensible is so huge for so many people and it unlocks so many things. And for example, I use the note editor, Obsidian, which often as I use it, I’m like, “Man, this kind of feels like VS Code,” like a code editor, but it’s really just personal note taking and stuff. And it’s very similar and that it has a plugin ecosystem and stuff is open source and you can add all kinds of things to it. I see that with so many other tools where people are going, “It’s open source first, plus you can extend it.” And I see that often and I see it coming and I think it’s a real innovation that will continue to push a lot of ideas forward.
[00:37:23] BH: And Jonathan, so what’s on the horizon in terms of maybe stuff you’re already thinking of as a team, but are only in the early days? Or just generally you, as an individual, what’s on your mind as far as the future of developer productivity and innovation like as it relates to building on what we’ve got today?
[00:37:45] JC: There’s a few threads that I think are meaningful and also I’m very interested in. So if we kind of look at Codespaces, it’s currently very focused on solving technical onboarding. So making it such that if you’re new to a codebase or a team or a company, you can go from zero to a fully set up environment in a single click, but it’s not currently doing anything to help improve knowledge onboarding. And I think that that is still a big area of need for developer productivity where how do you really grok a codebase in like a deep and meaningful way? And not that every developer on the team has to understand every line of code, but build enough of an intuition or mental model that you can start to feel effective as quickly as you can. And so I think that there are some interesting companies that are doing stuff in that space. I have a side project called CodeTour that I’ve kind of been working on for a little bit that attempts to kind of compliment Codespaces and have this hypothesis of like, “What if a codebase also had guided walkthroughs that could kind of orient people to the codebase as well?” But I think there’s still so much to be done there. So I’m very interested in that space. I think another is better learning tools and learning platforms for building very developer oriented tutorials and content that don’t require bespoke websites every single time. Right? So when I look at things like CSS Diner or Flexbox Froggy, there are lots of amazing content creators that have a skill to know how to explain concepts in a way that can connect with other people. But I worry sometimes that a lot of those people don’t have the investment to go create a web property that has all of the infrastructure needed to take their content to market and also the tools to make it really easy to build. I think as we look at the number of people that are changing careers or the influx of developers, I think there’s big opportunities to kind of invest in having really compelling and feature rich tutorial, tooling, and platforms that can connect educators with learners in a way that we can really start to accelerate I think the fidelity of kind of knowledge acquisition. And then the last thing I would just quickly mention is I think now that the new normal for how the teams are going to look post-pandemic with hybrid work, I still think that we haven’t really cracked the nut of what is amazing collaboration look like that is a combination of real-time and async that is optimized for flow and mitigating distractions, but like somehow facilitating serendipity. And so I think that’s another area that I’m interested in seeing what tools and services can help in.
[00:41:13] BH: Thank you both for joining us today. It’s great to have you.
[00:41:16] CW: Thank you. Thank you for having us.
[00:41:18] JC: Yeah. Thank you. This was awesome.
[00:41:28] BH: This show is produced and mixed by Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join us for our DevDiscuss Twitter chats every Tuesday at 9:00 PM US Eastern Time. Or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.