Listen to the Changelog: https://changelog.com/podcast/459 (15mins in)

Transcript

You said something interesting about the preciousness of our development environments… And I’m with you that we’ve commoditized the servers, but we definitely have not commoditized dev, because it’s so intricate, it’s so set up… Sometimes it’s like “There be dragons. Please don’t touch my laptop, because it works right now, but I’m not sure if it’s gonna work tomorrow.” I do hate that. I think it’s almost a different skillset, of maintaining that. There’s overlap between development and the maintenance of a development environment in terms of things that you need to learn… But it’s almost a different task altogether. So I don’t like that about it, but it’s still very true that our development environments are precious to us, and they’re tweaked, and configured, and customized, and all the things. So I’m sure there’s probably lots of resistance to this…

[00:11:59.29] We talk about our setup - we have probably tens of thousands of lines of code, and very few dependencies in our stack, but GitHub is 14 years old, and there’s a million plus commits, and I’m sure the dependency list is very long… What kind of effort was this? Tell us the story of bringing it along.

CORY WILKERSON

It is. These are all very, very true points. You know, the last thing I wanted to do was kind of be the vessel that went out to GitHub and said “I wanna change your development environment”, because these things are so precious. Like, I’m an engineer, too. I think my environment is very much precious. And here I was, kind of the face in GitHub of saying “Well, we think we have a better way. Come join us over here.”

And I started off on this journey as a skeptic. I think I shared some of this, too… I didn’t think this would be a fruitful journey necessarily. I was just gonna go do my level best as an employee, see if I could make it happen, build moment etc. and see if I could find something out there. Now, on the other side of this journey, I feel like I’m completely on the other end now, where I’m just like “This is the future. This is the way that we will absolutely build software…”

But going back to the core of the story, it was literally just me out there, calling on my friends to begin with, inside of GitHub. I’d been there for five years, and the first few years were just me tapping into relationships, saying “Hey, can you give this thing a shot? Can you try this out? I wanna get your feedback and feelings about where this is at.” And no one could yet use it on our core repository. We call it github/github - the organization is GitHub, the repository is GitHub. We didn’t have this thing standing up in a Codespace yet, but we had other repositories that were compatible with Codespaces.

So I’d go out and ask favors of friends, and just be like “Can you try this out and give me some feedback?” And generally, the feedback I would get back was – first it was resistance, like “Why would I do this? It’s productivity lost; tax on productivity. I don’t trust HTTP. There’s gonna be lag”, that kind of feedback. But then people would try it and they’d come back and be like “Huh. That was maybe better than I thought.”

At the same time, as I hacked in this space too, I was starting to get some of that “Well, there’s something here.” The big a-ha moment for me was connecting VS Code into my Codespace out in the cloud and still retaining that local development experience. So it felt to me like it was still very local. The magic is the synchronization that’s happening between the local environment and the cloud. It feels totally transparent.

But that aside, it started with just a very small number of users. So we would go back to leadership in GitHub and talk about progress we were making… And the early days, the story was “I have five people that have responded positively to Codespaces.” So not much of a story, but starting to kind of make a little bit of progress. And then maybe it was ten people.

Then, the next iteration on this was like “Well, let’s go find a team. Let’s get a full team on Codespaces. How can we get a single team - 6 to 8 people - committed to using Codespaces, and stick in this thing?” At this point we’d had this other effort running on the side to get github/github, the core github.com repository, compatible with Codespaces. And we’d gotten it to a point – we detail how we did this in the blog post - where performance was mostly acceptable. So now we could go shop this with a team that worked primarily on GitHub.com and see what their experience was. And we’re making progress there. So we’re ramping in – I think y’all have talked to Kyle Daigle in the past. Kyle was the leader of that effort that got this team spun up inside of Codespaces on GitHub core. And again, it was somewhat retentive. People were sticking, and going like “Wow, this is not what I thought. It’s better than maybe what I thought.”

[00:15:59.11] But I think the real breakthrough moment came when we stopped calling this dogfooding. You hear this term all the time, dogfood… I think it actually originated – I looked up on Wikipedia; I think the term originated inside of Microsoft a number of years ago.

ADAM STACOVIAK

Is that right?

CORY WILKERSON

But GitHubbers, my colleagues don’t respond well to that term. Dogfooding doesn’t inspire anyone to go do anything. Just like “Eat the dogfood? Who feels good about that?” And so what we did was we launched what we called the GitHub Computer Club, and I would love to dedicate a full episode on this. It’s a really interesting concept, and something I hope to bring out to the industry. But we asked people to join the GitHub Computer Club. And in doing so, they took this commitment or oath. I wrote up this script, “I do solemnly swear to never – no shadow compute, not desktop compute. I’ll ...