Episode 14: Jonathan Carter (LostInTangent), Visual Studio Live Share, GitHub Codespaces, CodeTour

Transcript

If you notice any errors in this transcript, you can propose changes to the source.

Beyang Liu: All right. I'm here with Jonathan Carter, Principal Program Manager at Microsoft, where he works on Codespaces, VS Code, Live Share, and IntelliCode. And he's also the author of several VS Code related personal projects including Gistpad, CodeTour, and GitDoc. Jonathan, welcome to the show.

Jonathan Carter: Thanks so much for having me. I'm excited to chat.

Beyang: Awesome. So you have quite the developer tools repertoire. But before we get into all of that, I always like to kick things off by asking folks, how did they get into programming? So what was your first introduction to this strange world that we live in?

Jonathan: Yeah, that's a great question. So I didn't have a computer in my house until I was 16. And my best friend and I, this was before everybody had cell phones and connectivity. Really just caught wind of building webpages and being able to use that to share ideas. And so the moment that we had gotten a computer in my house and I recognized that I can start sharing music and pictures and ideas with some of my friends by means of GeoCities and other free web hosting solutions. It just became a passion for me that quickly devolved into building more complex applications and, "Hey, what's CSS?" And like, "Hey, what's SQL? I need a database for this." And then quickly realized that there was some interesting opportunities from a professional perspective beyond just tinkering around with friends.

Jonathan: My uncle worked at the courthouse for the local town that I'm from. And he ended up offering me a couple of side jobs, helping build some software. There really wasn't many ways. Just a reflection of back in the day, if you knew how to write any sort of code, you could make money. So yeah, I just started building some very simple line of business applications. And then while I was in high school, I had enough credits that I was able to start doing dual enrollment classes at a local community college. And so I just snowballed from there where I really, like I said, got started as a means for me to share stuff with my friends and then quickly that turning into a passion that I realized I was able to... There was a long road of things to learn and I was super eager to learn it. So the rest is history.

Beyang: Awesome. And from those early beginnings, what was the rough path from there to Microsoft?

Jonathan: I mean, I worked a lot of terrible jobs and had to write a lot of terrible code along the way. I did have a stint where I wrote code fusion professionally for a good while. And in some ways that's kind of a badge of honor that anytime I ever meet somebody that did that, it's like immediate kinship of shared experiences. And so I was a developer for probably five or six years. And most of the jobs that I worked looking back were things that I wouldn't necessarily say were amazing, but they were the stepping stones for me to get the experience I needed building a bunch of different kinds of applications. And I don't know, I probably had five or six different jobs along my journey. Working across PHP and CodeFusion and did a little bit of Java and C++ and pretty much anything that would pay.

Jonathan: And then I ended up working at a company that was a Microsoft partner, and they really were keen to have folks on the team be what's called an MVP in Microsoft, Most Valuable Professional. And that person tends to be quite in close communication with different product teams at Microsoft. And so I ended up becoming ASP.NET MVP, which was the tech stack that company was working on. And as part of that, I ended up visiting Redmond to participate in a design discussion for some upcoming versions of the dominant framework. And while I was up there, somebody approached me and was like, "Hey, would you be interested in interviewing?" And I was living in a smallest town in Florida, and so I thought the idea of moving to Seattle was pretty cool.

Jonathan: And so I ended up interviewing and actually the position I interviewed for was for Developer Relations, which was actually quite a big departure from what I was doing. And that wasn't really something that I had been seeking, but I had started doing some public speaking kind of user studies and code camps, and I liked it. I liked the idea of helping distill new information to people and see a broader perspective on what different companies and developers were trying to achieve and be a part of that conversation. And so I hadn't really ever thought about DevRel but I got the offer and thought, "Hey, I would not mind moving out of Florida." Nothing against Florida, but the Pacific Northwest in Seattle seemed a bit cooler.

Jonathan: And also .NET was a huge in the... I was living in the Tampa Bay area of Florida and it was very much a very heavy .NET kind of economy at that time back in 2006. And so it seemed like a really huge opportunity to go work at Microsoft and be a part of something. And so, yeah, that was how it started. And then I did that for about two years and then decided I wanted to get back closer to the product team. And after having done DevRel for a couple of years, made the decision instead of going back to being a developer, tried my hand at product management. And that's what I've been doing for the last 11 years.

Beyang: Awesome. And these days you're Principal Program Manager for a variety of products including Live Share Codespaces and IntelliCode. So I'd like to start with Live Share, because that is a really interesting product that's built into VS Code that allows developers to share their working state inside the editor. So essentially, the way I describe to people, it's like Pair programming through your editor. Is that a good way to describe it? What would be the way that you would introduce people to Live Share?

Jonathan: I think your description was really good. Usually what we often see is that folks think about collaboration based on existing tools that they already know. And so we often hear folks say, "Oh, Live Share is that Google docs for developers is this like a better screen-share?" And so in some ways those can be valuable ways to orient what Live Share is, because when you think about Google docs, nobody customizes the Google client, we're all looking at it from the same color scheme. And most often folks aren't theming Google docs, they are tricking it out with extensions to look super pleasing. But as developers, that's not the case at all. We spend a long time customizing and curating our font sizes. Which side of the editor is your file tree on? What color theme? And even within dark and light color themes, there's a million permutations.

Jonathan: And then you have things like accessibility settings. So we see folks where maybe I am using a magnifier or you're using a screen reader. And so with Live Share, it became very clear that the collaboration from a tool or from an environment that was so highly tuned for individual preference and ergonomics and visual familiarity and enjoyment, that it felt like a big miss for collaboration to have to occur by means of one person effectively looking at the world to the other person's lens, which is what happens with screen sharing. And so with Live Share, instead of opening up a screen share or pushing changes back and forth maybe via a gate branch that you're using for asynchronous collaboration, it allows you to just at any time push the share button, get a URL, and then send that to someone.

Jonathan: They can then effectively connect their individualized instance of the VS or VS Code to your session and then share just the context of the code base that you have open, and any of the supporting editor or runtime state needed to collaborate on it. But you're both within your own individual setup. And so for example, I could be in the VS Code on a Mac using a light theme, you could connect to my session from Visual Studio on Windows and in a totally different theme, we could just have completely different setups, but be able to work together without there being any divergence of what we're able to achieve. And so with Live Share the other thing that's quite different with the analogy of Google docs for developers, is that when you're working on a Google doc, it's a single file. Whereas with developers, we're working on multi file projects. And it isn't just about the text of the code files itself, it's also the runtime impact of those code files.

Jonathan: And so with Live Share, when you share with somebody you're sharing the entire scope of the project that you have open. You're able to share terminal output. If you're working on a web application, you're able to share the running local host servers securely with the guests and enjoying your session. You're able to share language services so that as the two or more developers are editing files, it isn't just editing texts, but they're getting error lightbulbs, they're getting auto-completion, they're getting refactoring suggestions so that it feels like a very rich development environment that just happens to be fully collaborative and without either developer having to sacrifice their individual setup.

Beyang: Yeah. I can say as a user of Live Share, the experience of using it especially first time, it almost feels like magic, because it almost feels like you have this portal to another person's editor. I used it over the summer. I had an intern for the summer and we would use it in these Pair programming debugging sessions. So she would share her, I don't know what you'd call it, like a Live Share session or instance with me, and we'd go through and I could see where her cursor was pointing at. And then we would individually go and explore our separate threads for maybe a little bit. But then one of us would find something and then the other person could instantly hop to where our cursor was. And you can both edit and it just felt very streamlined and very smooth.

Jonathan: Yeah. You actually just touched on one of the other key values that we've seen with Live Share and why we sought to build it. Which is, a lot of times when we've talked to developers about Pair programming, there are some folks that have a distaste for it because they perceive it as being this process by which one person is a passive spectator for the other, which if that works for folks, is totally fine. So we hear the traditional kind of driver or navigator model or ping pong Pair programming. There's quite a diverse set of ways that people can collaborate. But unfortunately, there's really not a great one size fits all model for how collaboration can be not only efficient for people, but actually something you enjoy to do. And with Live Share, because you're simply sharing context and one developers using your words, opening a portal to another developers kind of environment.

Jonathan: It allows each person in the session to work on entirely different things in parallel and then when needed resynchronize and focus on the same thing. But it also allows you to do both in parallel where I'm working in one file, but I have a second editor window open that lets me watch what you're working on and anywhere in between. And what we found is that that ends up being an experience that for people that had traditionally been not huge fans of Pair programming, all of a sudden are like, "Hey, I now enjoy doing regular Pair programming or regular collaboration." Because I can swarm or rally around a problem, get a person to help me with something, but not feel like one or the other person is, as I mentioned, just kind of a passive observer of the session.

Beyang: Mm-hmm (affirmative). Yeah, totally. How was Live Share born? Where did the idea come from? And how did you develop it in the initial stages?

Jonathan: It was really the inception of myself and a couple of other colleagues effectively taking some time to do some research into what were some of the biggest challenges that developer teams were having as they were beginning to become more geo distributed, and as they were looking to increase their velocity to ship faster, and as they were evolving their tech stacks and becoming 'more modernized.' And therefore everyone on the team was learning. In some ways the rate of change is so high nowadays that regardless how many years you've been a developer, you're still like a newbie to something. And we really just found, and we'll speak to this and some of the other things that my team is working on, a couple of key areas that felt like they were deserving of attention.

Jonathan: One of them was collaboration. And the fact that really developer collaboration hadn't really been innovated or given much love for a long time. And that screen-sharing was for all intents and purposes, kind of the state-of-the-art. And speaking to some of the comments that I made previously, what we found is that there were a lot of folks that wanted to collaborate more or did collaborate a lot, or teams, like I mentioned, that were becoming more geo distributed and were re asking themselves how to enable a culture of collaboration remotely. And everybody was effectively solving that by means of screen-sharing and encountering the problems that I discussed in explaining Live Share, which was, "Oh, I just can't stand to stare at this person's screen all day long. I respect their right to configure their editor like that, but I can only handle it for so long."

Jonathan: Even things like you're collaborating with someone in another part of the world where their keyboard layout is totally different. So as they press a key, it ends up being sent to your machine and turned into an unintended character. And so there were all these little paper cuts that really it just became clear to me or to our team that there was an opportunity to help improve collaboration for developers and in a way help teams embrace these trends and hopefully help people. So, long before the age of COVID where everybody is now working remotely, it was clear that that was something that was becoming more prevalent and we wanted to help support dev teams to be successful. And collaboration is just so critical to that.

Beyang: Makes sense. Do you have a sense of who is using Live Share heavily? Is it the people working in open source? Is it people working inside companies? Is it people working on side projects?

Jonathan: Yeah, I mean, great question. I would say Pair programming within companies is definitely one of the top use cases. And I would say it is most useful for teams that are geo distributed. But we also see lots of use of Live Share within teams that were all co-located. Because in many ways the benefits that we talked about actually have little to do with whether you're in the same office or not. We also see a lot of use of Live Share for educational settings. And so if you're in CS class, we see a lot of students that are using it for group projects or TA assistance, whether it's Boot Camp or higher education. We also see a lot of use of Live Share within hackathons. We've also begun to see and foster the use of Live Share for interviewing which depending on the way you want your interview to be performed, can end up looking a bit like a Pair programming session.

Jonathan: And then I would say within open source, we definitely do see a lot of that as well. Where folks that are maybe first-time and contributors to a project, or folks wanted, let's say rally around like, "Hey." This week is a doc bash where the communities looking to put some extra attention on improving the documentation for our project. We'll see instances where they'll use Live Share to collect their efforts together and help include folks in the broader community into a session that they might not otherwise have been immediately comfortable with knowing how to start contributing on their own. Yeah, there's a pretty diverse set of use cases. I would say the primary are Pair programming within teams and then classroom collaboration for group projects. Those represent the bulk. And then there's a bit of a tale of these other adjacent collaboration scenarios that we see quite a bit as well.

Beyang: Awesome. I feel like we could spend an entire episode probably more on just Live Share alone, but there's a bunch of other interesting stuff I want to get to. One of those being Codespaces, which is another product that's under the purview of your team. And I think a lot of people know what Codespaces is, but just in case we have listeners who are unfamiliar with it, can you give us a quick intro?

Jonathan: Yeah. Codespaces really is a one click developer environment in the cloud so that folks can get started contributing to a project in theory instantaneously. We have quite a bit of ways to go to achieve that promise. But as you join a team or as you want to contribute to an open source or an Inner source project within a company, we want to make it so easy to do that that you're more likely to actually do it versus not do it. And so what Codespaces is really is a service that, like I mentioned, lets you from a repo or a pull request on gethub.com. Click a button and within a minute or so, be connected to a fully set up developer environment that clone the repo, looked at the code base set itself up for all of the requirements needed to start working on it. And then giving you access to a full fidelity version VS Code directly from your browser.

Jonathan: And so we also have support for connecting to Codespaces from the Visual Studio and Visual Studio Code desktop clients as well, which really is there to speak to making sure that folks can make use of the tools that they know and love and prefer. But yeah, really Codespaces is about how do we completely eradicate the complexity and time required to get set up to contribute to a project and help enable folks to go directly to actually writing code and contributing whenever they want to?

Beyang: Awesome. And I understand from a branding point of view, there's Visual Studio Codespaces, there's GitHub Codespaces, but I believe those are the same things in the back end, right? Or are they perhaps subtly different in some way?

Jonathan: Yep. So my team had, when we first built Codespaces, we built it as a service that was available and usable through Azure. That way, folks that were already familiar with using Azure and had subscriptions, and had established billing relationships, they had a really straightforward way of starting to use the service. And then we ended up partnering with GitHub to build a native experience through github.com so that folks that were using GitHub had an extremely low barrier of entry to starting to use the product, which for folks that were already hosting their code on GitHub. You just couldn't make it any simpler than giving you a button right there on the repo or PR page. So over time, what we learned was, just from enough feedback from folks, that we wanted make sure that we had a super simple and clear product acquisition experience that didn't give folks unnecessary or potentially confusing choice. And so we recently made the announcement that we're consolidating the Codespaces experience into just the GitHub native offering.

Beyang: Got it.

Jonathan: So yeah. There was always the Codespaces service that was available via two different kind of front doors, so to speak. Whereas now we're in the process of consolidating that to become just to get hub native experience.

Beyang: Got it. It seems like the Holy grail experience that you're after is, I visit a repository and GitHub. It looks interesting. I want to contribute in some way or maybe I found a bug, but I don't have a development environment set up and it's such a hassle. It's always a big question mark. Like, "Okay, if I..." Cloning is easy enough, but actually setting up a dev environment and my editor with auto complete and installing all the dependencies and making it work, that is like a rabbit hole. Right? And so your aim is to make it possible for someone to just go to any GitHub repo, click a button, and instantly they have this dev environment in their browser that allows them to easily make the change they're trying to make. Is that the thing that you're after?

Jonathan: Yup, yup. 100%. Yeah. I mean, we often, as you see with open source projects or any project for that matter, there's always some form of documentation that explains, "Here's how to get set up working on this repository." And so what Codespaces really wants to do is exactly like you just said, by how can we make it such that the documentation for how to get set up can be replaced with configuration that is stored in the repo itself along with the code base, and then allow a service to effectively use that to spin up and do all of the setup for you knowing exactly what the requirements of that project are so that you don't have to go through the guesswork doing it. So, yeah. We've talked to so many teams where they express the sentiment of wanting to do more open source contributions or wanting to contribute to, not even just open source, but as I mentioned, Inner source. So like large companies that have a lot of intra company projects where they invite or want to foster cross team contributions.

Jonathan: And it does on the surface seem like, "Well to clone and set up my machine and install this version of Java or whatever, is it really that much work?" But in practice, the thing is, is that we're all so insanely busy that even something that takes five to 10 minutes, like let's assume that a project is just a beacon of efficiency and that it is not that convoluted, like this is going to take half a day to get going. Even if it is just five to 10 minutes, the reality is that that is enough to kill a lot of opportunistic situations where somebody, like you were saying, might see a bug or they see an opportunity in an open source project, they'd love to contribute, but it's just enough friction to break the impulse in them to kind of move on.

Jonathan: And that's just, like I said, a function of, we have to respect our time and our focus. And so with Codespaces, really the hope is like, how do you make contributing to projects? 'Why not now easy?' And that was actually somebody who was one of our earliest users of Codespaces referred to it as that, and I've latched onto it. Because it's like that notion of, "Hey, I see something I can help contribute to here." And you almost have an internal dialogue with yourself of, "Why not now? Is today the day that I send a PR to the react JS code base?" And if we give you a single button click that within seconds, you can actually turn that idea into reality. We hope that that can actually improve folks workflow and enable more collaboration as a result.

Beyang: Yeah. Actually the way that you just described the value proposition of Codespaces, is all similar to the way that we described value proposition of Sourcegraph in a lot of ways. In that if you're doing a search over code, Sourcegraph is not the first thing that allows you to search over your code base. There's many different ways. You clone it to your local machine and search with grep or just search inside your editor. And a lot of people ask that question in the early days. What new capabilities does this give you? And it's like, "Well, none." But how many of those searches are you doing now? And how many of those are you not doing? There's this little thing inside your brain that triggers on like annoyance or extra effort and lowering that kind of friction. Or activation energy will actually yield a result that lets you do a lot more of that action. So yeah, that's interesting.

Jonathan: Yeah. It's interesting. This is like a super lame and uninteresting anecdote. But I did this experiment one time where we usually store our vacuum cleaner in our basement because that's where there's space for it. But there was one time where I was vacuuming our main floor carpet and after I was done, I just had to just leave the vacuum out right there in the living room. And what happened is, because that the vacuum was there, it became easier to always vacuum. And so whether it was me or my wife or even my kids, they were like, "Hey, let's vacuum." You know I like it. It would have been so simple to just walk down the staircase to get the vacuum had we wanted to vacuum.

Jonathan: But there's something very powerful about having something within arms reach and enabling that to help you with behavior change that you might otherwise also want to do. And so yeah. Like with Codespaces or Sourcegraph, how do you make it such that when you have a question or you have a thought or an idea that it's directly within arm's reach for you to do so that it's so simple to actually take action on it in a way that is likely to happen?

Beyang: Yeah, totally. So there have been attempts to do something like Codespaces in the past. They go under various names, usually under the banner of some like online IDE or ready-made development environment in the cloud, cloud-based development environments. What do you think is really setting Codespaces apart from these previous attempts? Why do you think Codespaces is really going to click and take off where prior attempts, I don't think any of them have reached the level of adoption that their creators envisioned?

Jonathan: When we had first set out to research and learn whether there was actually value in us doing Codespaces. What we found was that most people that had developed a distaste for cloud IDEs or some sort of remote developer environment solution, was that they found it required them to sacrifice more than they were getting in return. For example, maybe they had tried a web editor or a web IDE in the past, but it was significantly different from what they would otherwise have used, or it was significantly fragmented from the ecosystem that they otherwise wanted to be a part of. That it just seemed like they were having to choose between their developer tool or a turnkey, easy onboarding service to make it rapid to get started working on a project.

Jonathan: And as we were just chatting about with Live Share, any time that you take a bet on something that requires developers to have to sacrifice their individual set up and personalization, you're probably going to fail. It's just a bad bet to take. Like I'm not interested in that, somebody else can do it. And so with Codespaces, because the editing experience is literally full fidelity 100% Visual Studio code, in your browser, we believe that it changes a huge reason why people were originally very hesitant to even explore web-based editors. Because all of a sudden, every extension that you're using today or that you want to potentially use in the future, is going to work. Your theme, your key bindings, all of the muscle memory and ergonomics that you built up over time, continue to function exactly the same.

Jonathan: And then furthermore, as I was mentioning a moment ago, we built the service to not put all this emphasis on a web editor, but really the environment that provides you with a completely set up free onboarding experience. And by us also supporting connecting to Codespaces from Visual Studio code desktop, or Visual Studio IDE, all of a sudden I think that also changes a big part of why other tools maybe haven't worked is because many people don't want to work all day long in the browser. I happen to be a person that does. On my Mac, everything I use all day long, whether it's Outlook or Teams or Zoom or Zencaster, or Codespaces, I run it in the browser but I constantly get not made fun of, but people that are like, "That's strange." Right?

Beyang: Yeah.

Jonathan: And so by focusing on what is the actual problem that we're trying to solve? And then not requiring you to change something in order to achieve that, I think is a key part of why we've found Codespaces to be quite compelling. Because if you're already using Visual Studio or Visual Studio code and you want to have a better more lightweight contribution experience, you can achieve that and it look and feel identical to how you work today. And so if you look on Twitter, for example, and you search for Codespaces, you'll just see a sea of folks where their first reaction is, "Wow, I can't believe X works." Or, "This extension works." I would've swore this couldn't possibly work, but it does, which is great. Because that's folks echoing that sentiment that I mentioned of assuming that a cloud-based developer environment is going to be a facsimile or a shadow of what we normally would expect it to be. And so yeah. Having that kind of no sacrifices experience is a key part of it.

Beyang: I think I'm similar to you in that I run basically everything in the browser. Like Slack is in the browser or the calendar is in the browser, emails in the browser. I really prefer, if I can run in a browser versus like a native app, I think I'll opt for the browser with one exception, and that is my code editor. So it is great that I can connect to a Codespace through the VS Code native app in addition to opening it up in a browser tab.

Jonathan: Yeah. Which I think is really keen to me. Like Live Share is very much speaks to the same way where I think there's a lens that I look at through every product that I'm ever involved in which is, how do we solve only the problem we're trying to solve and not introduce new ones for people? And so in your case, you already have VS Code desktop on your machine and you're enjoying it. So I don't have any reason to want you to change. And same thing with Live Share. How do you collaborate in a way that doesn't require you to change anything? I just think, for developers we've continued to find that's a pretty meaningful benefit for folks to gain something without losing anything in return.

Beyang: I want to turn now to one of your personal projects. So everything we've talked to so far is stuff that you do in your official capacity at Microsoft. But you have a number of interesting personal projects and one of these is CodeTour. So it's an extension that allows you to build tutorials and onboarding experiences to code bases that people can use writing VS Code. And I think it's really cool, you've tweeted about it a bunch. When I first saw it, I was like, "Holy crap." Like, "I want this." Like this would help me, it would have helped a lot of people that we've onboarded to the code base at Sourcegraph. So yeah. I guess I'll turn things over to you and let you describe what it is.

Jonathan: Yeah. I mean, the kind of inception point for CodeTour was, as our team was building out Codespaces and we thought to ourselves, "Hey, if we're successful in enabling developers to have a one-click experience that gets them from a code base into a fully setup environment that they can start coding. What's the next problem that that developer is going to hit in terms of being successful? And how do we embrace onboarding from a holistic sense versus just thinking about it from setting up a dev box in the cloud." And so with CodeTour, that became an exploration into how could we move onboarding or developer documentation closer to the code itself so that it became immediately recognizable and immersive once somebody had jumped into a code space or clone to repo and opened it in their editor. And was effectively guided through a story or a tour, as we call it, that helps walk them through an orient themselves with that code base.

Jonathan: And because of the fact that it's happening within your editor, the belief or the hypothesis was that people might be more likely to actually do it and read it. Whereas if you have companion documentation, it's very easy for that to be out of sight, out of mind. But also once you have this code base walkthrough within the editor, the documentation itself could then potentially become much more interactive. So each step could not just explain a part of the code base, but it could then actually have mechanisms for guiding you through doing a build of the project, or automating beginning a debugging session, or helping show here's where you would create a file to add a new component to the repository for, let's say, a react JS application.

Jonathan: And so yeah, really CodeTour, it currently writes an extension for VS Code that lets you record and then playback multi-step guided walkthroughs of a code base. And it has a visual recorder, because to me it, it felt important that the act of creating these tours or these walk-throughs was itself very easy to alter as well as edit. And so the way that it works is you just click a button to start a new tour, and then within VS Code, you can then navigate files and start adding annotations to lines of code with the necessary pros much like you might add comments to a pool request. And so those steps are ordered and you can rearrange them. And behind the scenes, the tour itself has persisted as just adjacent file in the repository itself, which makes it easy to do code reviewing on it, to collaborate.

Jonathan: Right now CodeTour only supports VS Code. But as I mentioned, because the Tour is really just an artifact in the repo that really sets it up to become something that other editors could light up and become aware of as well. So yeah. CodeTour was really an expansion of the head space of, how do we make onboarding better? How do we make collaboration and the sharing of knowledge better in a way where we accept that documentation that is a secondary asset outside of your editor is easy to ignore, easy not to maintain? And so if we put something in the editor, there's this belief that folks would be more likely to curate it and groom it and actually use it. And so, yeah. It's been pretty exciting to see the response from the community. That's far for sure.

Jonathan: Because it wasn't clear to me and some of my colleagues when we first started talking about it. It was very much like, "This is maybe a terrible idea, but let's try it." And it was by far the most, I would say from a pure vanity metric perspective, it was one of the most successful things I've ever worked on by virtue of engagements on hacker news and on Twitter. And GitHub repos just surpassed a thousand stars, which is minuscule compared to a lot of projects. So yeah, it's been exciting to see the interest in folks. The thing to me that was the most exciting was people coming by large to really express their excitement and seeing attention being given on these kinds of problems, which is in many ways really my passion, is like, while there's Live Share Codespaces or CodeTour or other thing. It's like where are there areas that just feel really ready for a bit of love. It's just something that we've gotten used to as developers of dealing with the current status quo, but like, "Maybe we could rethink this and do it in a different way." And so yeah.

Beyang: Have you been able to use CodeTour at all for any sort of onboardings or tutorials to the code that you are gone. Either on your personal time or at Microsoft?

Jonathan: So I would say at Microsoft, a big percentage of the developer teams that I work with use a mix of Visual Studio and Visual Studio Code. And so I think for sure one learning that, is very clear, is in order for something like that to take up broad adoption or be successful in the team is, you need to make sure it-

Beyang: Editor coverage.

Jonathan: Supports tools that people... Yeah, you have the right editor coverage. That said, within my side projects and amongst some of the open source work that I do with some of my frequent collaborators, so to speak, yeah. We have started using CodeTour for doing documentation, so to speak, of like, "Hey, I just added this new area of the code base. And while it's fresh in my mind, let me go ahead and just create a quick Tour." And so a lot of the refinement that we've done over the last few months trying to improve or streamline the offering experience, was based on actually using it. And then I've also been pretty keen on collaborating and chatting with other folks that are actually using it in practice. Where we have a few learning platforms that have started to express some interest in looking at CodeTour as a means for providing a bit more interactivity for their content within the editor versus having a documentation page and then asking somebody to switch to their editor and then switch back to the docs, and maybe lose some of their contexts in the process.

Jonathan: And so I would say CodeTour is very early in its stages of validating whether or not this is the right approach. And so right now I'm very focused and keen on looking to get more success stories from folks. We have a lot of interests right now, but I think there's still a couple of interesting challenges ahead, which is good. Because that's one of the reasons why I like doing extra curricular explorations is because sometimes there's only so much you can predict or learn through research versus... To me, I like open source because it's almost like having a conversation with the ecosystem by means of a MVP or a prototype or something where if you try to explain it in the abstract, it would be maybe a little bit less clear what you were talking about versus being able to illustrate or demonstrate the beginning of an idea that you then want to use to see the discussion around, getting to something that is truly achieving the goal that it has. So I think there's quite a bit of room for improvement with CodeTour, but we've seen some pretty exciting early usage of it in education and training and team onboarding that I think for us to scale it up a bit more within Microsoft, we would need at a minimum Visual Studio support. And so that's something that I'm interested in looking at pretty soon.

Beyang: Awesome. One last thing, Jonathan, if there's one thing that you're most excited about, that you're currently working on, that's going to be released or coming out in the next couple months, what is that thing?

Jonathan: One of the other things that my team works on that we didn't get to is this product called IntelliCode, which is really all about how can we up level what we traditionally think of as productivity tooling in the IDE by taking all of the features that typically work based on static analysis and augmenting them with insights that come from learning all of these best practices from the open source community and GitHub. And so one thing that we've been working on that I'm pretty excited about is this feature with IntelliCode called suggestions where it will actually observe patterns and 'repeated edits' that you're making while you're coding and then suggest other locations within the code base that you can make similar changes. For example, if you're making a refactoring or making a kind of a style change, it's a very common bug we've observed where folks maybe aren't aware of all the other locations that they could make that change or if they tried to do a find across the code base to regular expression they would need to write would be sufficiently complex that they just don't do it.

Jonathan: Whereas with this kind of capability that we're working on, we are excited to be able to turn your intent. Like I made this change a couple of times, I've signaled intent that I want to adopt this pattern. And then we can translate that into something that you can replicate across your entire code base. And then also in the long-term be able to codify in a way that maybe becomes almost like de facto style or best practice guidelines for your team, that you can help each other remain more consistent and make the code base more maintainable over time. So that's definitely something that I'm pretty excited about just because I think there's a lot of energy and interests. The whole GPT-3 thing didn't help. But people are very keen on how can AI and ML help up level developer productivity in a very practical way. So yeah, I'm excited about some of the things we're doing in that space.

Beyang: That sounds incredibly interesting. And if you're up for it, I might have to ask you back on the show to talk about that. Because it sounds like a whole another show of interesting discussion.

Jonathan: Yeah. Just let me know when.

Beyang: All right. Cool. Thanks Jonathan, for coming on the show today and I'll be watching your Twitter feed with great anticipation.

Jonathan: All right. Thanks so much.