Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I’ve got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it’s more than just hipster monitoring.

Corey: This episode is sponsored in part by Liquibase. If you’re anything like me, you’ve screwed up the database part of a deployment so severely that you’ve been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We’ve mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn’t have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you’ll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I’m joined this week by Jason Warner, the Chief Technology Officer at GifHub, although he pronounces it differently. Jason, welcome to the show.

Jason: Thanks, Corey. Good to be here.

Corey: So, GitHub—as you insist on pronouncing it—is one of those companies that’s been around for a long time. In fact, I went to a training conducted by one of your early folks, Scott Chacon, who taught how Git works over the course of a couple of days, and honestly, I left more confused than I did when I entered. It’s like, “Oh, this is super awful. Good thing I’ll never need to know this because I’m not really a developer.” And I’m still not really a developer and I still don’t really know how Git works, but here we are.

And it’s now over a decade later; you folks have been acquired by Microsoft, and you are sort of the one-stop-shop, from the de facto perspective of, “I’m going to go share some code with people on the internet. I’ll use GitHub to do it.” Because, you know, copying and pasting and emailing Microsoft Word documents around isn’t ideal.

Jason: That is right. And I think that a bunch of things that you mentioned there, played into, you know, GitHub’s early and sustained success. But my God, do you remember the old days when people had to email tar files around or drop them in weird spots?

Corey: What the hell do you mean, by, “Old days?” It still blows my mind that the Linux kernel is managed by—they use Git, obviously. Linus Torvalds did write Git once upon a time—and it has the user interface you would expect for that. And the way that they collaborate is not through GitHub or anything like that. No, they use Git to generate patches, which they then email to the mailing list. Which sounds like I’m making it up, like, “Oh, well, yeah, tell another one, but maybe involve a fax machine this time.” But no, that is actually what they do.

Jason: It blew my mind when I saw that, too, by the way. And you realize, too, that workflows are workflows, and people will build interesting workflows to solve their use case. Now, obviously, anyone that you would be talking to in 2021, if you walked in and said, “Yeah, install Git. Let’s set up an email server and start mailing patches to each other and we’re going to do it this way.” They would just kind of politely—or maybe impolitely—show you out of the room, and rightfully [laugh] so. But it works for one of the most important software projects in history: Linux.

Corey: Yeah, and it works almost in spite of itself to some extent. You’ve come a long way as a company because initially, it was, “Oh, there’s this amazing, decentralized version control system. How do we make it better? I know, we’re going to take off the decentralized part of it and give it a central point that everything can go through.” And collaboratively, it works well, but I think that viewing GitHub as a system that is used to sell free Git repositories to people is rather dramatically missing the point. It feels like it’s grown significantly beyond just code repository hosting. Tell me more about that.

Jason: Absolutely. I remember talking to a bunch of folks right around when I was joining GitHub, and you know, there was still talk about GitHub as, you know, GitHub for lawyers, or GitHub for doctors, or what could you do in a different way? And you know, social coding as an aspect, and maybe turning into a social network with a resume. And all those things are true to a percentage standpoint. But what GitHub should be in the world is the world’s most important software development platform, end-to-end software development platform.

We obviously have grown a bunch since me joining in that way which we launched dependency management packages, Actions with built-in CI, we’ve got some deployment mechanisms, we got advanced security underneath it, we’ve Codespaces in beta and alpha on top of it now. But if you think about GitHub as, join, share, and see other people’s code, that’s evolution one. If you see it as world’s largest, maybe most developed software development platform, that’s evolution two, and in my mind, its natural place where it should be, given what it has done already in the world, is become the world’s most important software company. I don’t mean the most profitable. I just mean the most
important.

Corey: I would agree. I had a blog post that went up somewhat recently about the future of cloud being Microsoft’s to lose. And it’s not because Azure is the best cloud platform out there, with respect, and I don’t need you to argue the point. It is very clearly not. It is not like other clouds, but I can see a path to where it could become far better than it is.

But if I’m out there and I’m just learning how to write code—because I make terrible life choices—and I go to a boot camp or I follow a tutorial online or I take a course somewhere, I’m going to be writing code probably using VS Code, the open-source editor that you folks launched after the acquisition. And it was pretty clear that Atom wasn’t quite where the world was going. Great. Then I’m going to host it on GitHub, which is a natural evolution. Then you take a look at things like GitHub Actions that build in CI/CD pipelines natively.

All that’s missing is a ‘Deploy to Azure’ button that is the next logical step, and you’re mostly there for an awful lot of use cases. But you can’t add that button until Azure itself gets better. Done right, this has the potential to leave, effectively, every other cloud provider in the dust because no one can touch this.

Jason: One hundred percent. I mean, the obvious thing that any other cloud should be looking at with us—or should have been before the acquisition, looking at us was, “Oh, no, they could jump over us. They could stop our funnel.” And I used internal metrics when I was talking to them about partnership that led to the sale, which was I showed them more about their running business than they knew about themselves. I can tell them where they were stacked-ranked against each other, based on the ingress and egress of all the data on GitHub, you know, and various reactions to that in those meetings was pretty astounding.

And just with that data alone, it should tell you what GitHub would be capable of and what Azure would be capable of in the combination of those two things. I mean, you did mention the ‘Deploy to Azure’ button; this has been a topic, obviously, pre and post-acquisition, which is, “When is that coming?” And it was the one hard rule I set during the acquisition was, there will be no ‘Deploy to Azure’ button. Azure has to earn the right to get things deployed to, in my opinion. And I think that goes to what you’re saying is, if we put a ‘Deploy to Azure’ button on top of this and Azure is not ready for that, or is going to fail, ultimately, that looks bad for all of us. But if it earned the right and it gets better, and it becomes one of those, then, you know, people will choose it, and that is, to me, what we’re after.

Corey: You have to choose the moment because if you do it too soon, you’ll set the entire initiative back five years. Do it too late, and you get leapfrogged. There’s a golden window somewhere and finding it is going to be hard. And I think it’s pretty clear that the other hyperscalers in this space are learning, or have learned, that the next 10 years of cloud or 15 years of cloud or whatever they want to call it, and the new customers that are going to come are not the same as the customers that have built the first half of the business. And they’re trying to wrap their heads around that because a lot of where the growth is going to come from is established blue chips that are used to thinking in very enterprise terms.

And people think I’m making fun of them when I say this, but Microsoft has 40 years’ experience apologizing to enterprises for computer failures. And that is fundamentally what cloud is. It’s about talking computers to business executives because as much as we talk about builders, that is not the person at an established company with an existing IT estate, who gets to determine where $50 million a year in cloud-spend is going to go.

Jason: It’s [laugh] very, [laugh] very true. I mean, we’ve entered a different spot with cloud computing in the bell curve of adoption, and if you think that they will choose the best technology every time, well, history of computing is littered with better technologies that have failed because the distribution was better on one side. As you mentioned, Microsoft has 40 years, and I wager that Microsoft has the best sales organizations and the best enterprise accounts and, you know, all that sort of stuff, blah, blah, blah, on that side of the world than anyone in the industry. They can sell to enterprises better than almost anyone in the industry. And the other hyperscalers—there’s a reason why [TK 00:08:34] is running Google Cloud right now. And Amazon, classically, has been very, very bad assigned to the enterprises. They just happened to be the first mover.

Corey: In the early days, it was easy. You’d have an Amazon salesperson roll up to a company, and the exec would say, “Great, why should we consider running things on AWS?” And the answer was, “Oh, I’m sorry, wrong conversation. Right now you have 80 different accounts scattered throughout your org. I’m just here to help you unify them, get some visibility into it, and possibly give you a discount along the way.” And it was a different conversation. Shadow IT was the sole driver of cloud adoption for a long time. That is no longer true. It has to go in the front door, and that is a fundamental shift in how you go to market.

Jason: One hundred percent true, and it’s why I think that Microsoft has been so successful with Azure, in the last, let’s call it five years in that, is that the early adopters in the second wave are doing that; they’re all enterprise IT, enterprise dev shops who are buying from the top down. Now, there is still the bottoms-up adoption that going to be happening, and obviously, bottom-up adoption will happen still going forward, but we’ve entered the phase where that’s not the primary or sole mechanism I should say. The sole mechanism of buying in. We have tops-down selling still—or now.

Corey: When Microsoft announced it was acquiring GitHub, there was a universal reaction of, “Oh, shit.” Because it’s Microsoft; of course they’re going to ruin GitHub. Is there a second option? No, unless they find a way to ruin it twice. And none of it came to pass.

It is uniformly excellent, and there’s a strong argument that could be made by folks who are unaware of what happened—I’m one of them, so maybe I’m right, maybe I’m wrong—that GitHub had a positive effect on Microsoft more than Microsoft had an effect on GitHub. I don’t know if that’s true or not, but I could believe it based upon what I’ve seen.

Jason: Obviously, the skepticism was well deserved at the time of acquisition, let’s just be honest with it, particularly given what Microsoft’s history had been for about 15—well, 20 years before, previous to Satya joining. And I was one of those people in the late ’90s who would write ‘M$’ in various forums. I was 18 or 19 years old, and just got into—

Corey: Oh, hating Microsoft was my entire personality.

Jason: [laugh]. And it was, honestly, well-deserved, right? Like, they had anti-competitive practices and they did some nefarious things. And you know, I talked about Bill Gates as an example. Bill Gates is, I mean, I don’t actually know how old he is, but I’m going to guess he’s late ’50s, early ’60s, but he’s basically in the redemption phase of his life for his early years.

And Microsoft is making up for Ballmer years, and later Gates years, and things of that nature. So, it was well-deserved skepticism, and particularly for a mid-career to older-career crowd who have really grown to hate Microsoft over that time. But what I would say is, obviously, it’s different under Satya, and Scott, and Amy Hood, and people like that. And all we really telling people is give us a chance on this one. And I mean, all of us. The people who were running GitHub at the time, including myself and, you know, let Scott and Satya prove that they are who they say they are.

Corey: It’s one of those things where there’s nothing you could have said that would have changed the opinion of the world. It was, just wait and see. And I think we have. It’s now, I daresay, gotten to a point where Microsoft announces that they’re acquiring some other beloved company, then people, I think, would extend a lot more credit than they did back then.

Jason: I have to give Microsoft a ton of credit, too, on this one for the way in which they handled acquisitions, like us and others. And the reason why I think it’s been so successful is also the reason why I think so many others die post-acquisition, which is that Microsoft has basically—I’ll say this, and I know I won’t get fired because it feels like it’s true. Microsoft is essentially a PE holding company at this point. It is acquired a whole bunch of companies and lets them run independent. You know, we got LinkedIn, you got Minecraft, Xbox is its own division, but it’s effectively its own company inside of it.

Azure is run that way. GitHub’s got a CEO still. I call it the archipelago model. Microsoft’s the landmass underneath the water that binds them all, and finance, and HR, and a couple of other things, but for the most part, we manifest our own product roadmap still. We’re not told what to
go do. And I think that’s why it’s successful. If we’re going to functionally integrate GitHub into Microsoft, it would have died very quickly.

Corey: You clearly don’t mix the streams. I mean, your gaming division writes a lot of interesting games and a lot of interesting gaming platforms. And, like, one of the most popularly played puzzle games in the world is a Microsoft property, and that is, of course, logging into a Microsoft account correctly. And I keep waiting for that to bleed into GitHub, but it doesn’t. GitHub is a terrific SAML provider, it is stupidly easy to log in, it’s great.

And at some level, I wish that would bleed into other aspects, but you can’t have everything. Tell me what it’s like to go through an acquisition from a C-level position. Because having been through an acquisition before, the process looks a lot like a surprise all-hands meeting one day after the markets close and, “Listen up, idiots.” And [laugh] there we go. I have to imagine with someone in your position, it’s a slightly different
experience.

Jason: It’s definitely very different for all C-levels. And then myself in particular, as the primary driver of the acquisition, obviously, I had very privy inside knowledge. And so, from my position, I knew what was happening the entire time as the primary driver from the inside. But even so, it’s still disconcerting to a degree because, in many ways, you don’t think you’re going to be able to pull it off. Like, you know, I remember the months, and the nights, and the weekends, and the weekend nights, and all the weeks I spent on the road trying to get all the puzzle pieces lined up for the Googles, or the Microsofts, or the eventually AWSs, the VMwares, the IBMs of the world to take seriously, just from a product perspective, which I knew would lead to, obviously, acquisition conversations.

And then, once you get the call from the board that says, “It’s done. We signed the letter of intent,” you basically are like, “Oh. Oh, crap. Okay, hang on a second. I actually didn’t—I don’t actually believe in my heart of hearts that I was going to actually be able to pull that off.” And so now, you probably didn’t plan out—or at least I didn’t. I was like, “Shit if we actually pulled this off what comes next?” And I didn’t have that what comes next, which is odd for me. I usually have some sort of a loose plan in place. I just didn’t. I wasn’t really ready for that.

Corey: It’s got to be a weird discussion, too, when you start looking at shopping a company around to be sold, especially one at the scale of GitHub because you’re at such a high level of visibility in the entire environment, where—it’s the idea of would anyone even want to buy us? And then, duh, of course they would. And you look the hyperscalers, for example. You have, well, you could sell it to Amazon and they could pull another Cloud9, where they shove it behind the IAM login process, fail to update the thing meaningfully over a period of years, to a point where even now, a significant portion of the audience listening to this is going to wonder if it’s a service I just made up; it sounds like something they might have done, but Cloud9 sounds way too inspired for an AWS service name, so maybe not. And—which it is real. You could go sell to Google, which is going to be awesome until some executive changes roles, and then it’s going to be deprecated in short order.

Or then there’s Microsoft, which is the wild card. It’s, well, it’s Microsoft. I mean, people aren’t really excited about it, but okay. And I don’t think that’s true anymore at all. And maybe I’m not being fair to all the hyperscalers there. I mean, I’m basically insulting everyone, which is kind of my shtick, but it really does seem that Microsoft was far and away the best acquirer possible because it has been transformative. My question—if you can answer it—is, how the hell did you see that beforehand? It’s only obvious—even knowing what I know now—in hindsight.

Jason: So, Microsoft was a target for me going into it, and the reason why was I thought that they were in the best overall position. There was enough humility on one side, enough hubris on another, enough market awareness, probably, organizational awareness to, kind of, pull it off. There’s too much hubris on one side of the fence with some of the other acquirers, and they would try to hug us too deeply, or integrate us too quickly, or things of that nature. And I think it just takes a deep understanding of who the players are and who the egos involved are. And I think egos has actually played more into acquisitions than people will ever admit.

What I saw was, based on the initial partnership conversations, we were developing something that we never launched before GitHub Actions called GitHub Launch. The primary reason we were building that was GitHub launches a five, six-year journey, and it’s got many, many different phases, which will keep launching over the next couple of years. The first one we never brought to market was a partnership between all of the clouds. And it served a specific purpose. One, it allowed me to get into the room with the highest level executive at every one of those companies.

Two allow me to have a deep economic conversation with them at a partnership level. And three, it allowed me to show those executives that we knew what GitHub’s value was in the world, and really flip the tables around and say, “We know what we’re worth. We know what our value is in the world. We know where we sit from a product influence perspective. If you want to be part of this, we’ll allow it.” Not, “Please come work with us.” It was more of a, “We’ll allow you to be part of this conversation.”

And I wanted to see how people reacted to that. You know how Amazon reacted that told me a lot about how they view the world, and how Google reacted to that showed me exactly where they viewed it. And I remember walking out of the Google conversation, feeling a very specific way based upon the reaction. And you know, when I talked to Microsoft, got a very different feel and it, kind of, confirmed a couple of things. And then when I had my very first conversation with Nat, who have known for a while before that, I realized, like, yep, okay, this is the one. Drive hard at this.

Corey: If you could do it all again, would you change anything meaningful about how you approached it?

Jason: You know, I think I got very lucky doing a couple of things. I was very intentional aspects of—you know, I tried to serendipitously show up, where Diane Greene was at one point, or a serendipitously show up where Satya or Scott Guthrie was, and obviously, that was all intentional. But I never sold a company like this before. The partnership and the product that we were building was obviously very intentional. I think if I were to go through the sale, again, I would probably have tried to orchestrate at least one more year independent.

And it’s not—for no other reason alone than what we were building was very special. And the world sees it now, but I wish that the people who built it inside GitHub got full credit for it. And I think that part of that credit gets diffused to saying, “Microsoft fixed GitHub,” and I want the people inside GitHub to have gotten a lot more of that credit. Microsoft obviously made us much better, but that was not specific to Microsoft because we’re run independent; it was bringing Nat in and helping us that got a lot of that stuff done. Nat did a great job at those things. But a lot of that was already in play with some incredible engineers, product people, and in particular our sales team and finance team inside of GitHub already.

Corey: When you take a look across the landscape of the fact that GitHub has become for a certain subset of relatively sad types of which I’m definitely one a household name, what do you think the biggest misconception about the company is?

Jason: I still think the biggest misconception of us is that we’re a code host. Every time I talk to the RedMonk folks, they get what we’re building and what we’re trying to be in the world, but people still think of us as SourceForge-plus-plus in many ways. And obviously, that may have been our past, but that’s definitely not where we are now and, for certain, obviously, not our future. So, I think that’s one. I do think that people still, to this day, think of GitLab as one of our main competitors, and I never have ever saw GitLab as a competitor.

I think it just has an unfortunate naming convention, as well as, you know, PRs, and MRs, and Git and all that sort of stuff. But we take very different views of the world in how we’re approaching things. And then maybe the last thing would be that what we’re doing at the scale that we’re doing it as is kind of easy. When I think that—you know, when you’re serving almost every developer in the world at this point at the scale at which we’re doing it, we’ve got some scale issues that people just probably will never thankfully encounter for themselves.

Corey: Well, everyone on Hacker News believes that they will, as soon as they put up their hello world blog, so Kubernetes is the only way to do anything now. So, I’m told.

Jason: It’s quite interesting because I think that everything breaks at scale, as we all know about from the [hyperclouds 00:20:54]. As we’ve learned, things are breaking every day. And I think that when you get advice, either operational, technical, or managerial advice from people who are running 10 person, 50 person companies, or X-size sophisticated systems, it doesn’t apply. But for whatever reason, I don’t know why, but people feel inclined to give that feedback to engineers at GitHub directly, saying, “If you just…” and in many [laugh] ways, you’re just like, “Well, I think that we’ll have that conversation at some point, you know, but we got a 100-plus-million repos and 65 million developers using us on a daily basis.” It’s a very different world.

Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don’t ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.

Corey: One of the things that I really appreciate personally because, you know, when you see something that company does, it’s nice to just thank people from time to time, so I’m inviting the entire company on the podcast one by one, at some point, to wind up thanking them all individually for it, but Codespaces is one of those things that I think is transformative for me. Back in the before times, and ideally the after times, whenever I travel the only computer I brought with me for a few years now has been an iPad or an iPad Pro. And trying to get an editor on that thing that works reasonably well has been like pulling teeth, my default answer has just been to remote into an EC2 instance and use vim like I have for the last 20 years. But Code is really winning me over. Having to play with code-server and other things like that for a while was obnoxious, fraught, and difficult.

And finally, we got to a point where Codespaces was launched, and oh, it works on an iPad. This is actually really slick. I like this. And it was the thing that I was looking for but was trying to have to monkey patch together myself from components. And that’s transformative.

It feels like we’re going back in many ways—at least in my model—to the days of thin clients where all the heavy lifting was done centrally on big computers, and the things that sat on people’s desks were mostly just, effectively, relatively simple keyboard, mouse, screen. Things go back and forth and I’m sure we’ll have super powerful things in our pockets again soon, but I like the interaction model; it solves for an awful lot of problems and that’s one of the things that, at least from my perspective, that the world may not have fully wrapped it head around yet.

Jason: Great observation. Before the acquisition, we were experimenting with a couple of different editors, that we wanted to do online editors. And same thing; we were experimenting with some Action CI stuff, and it just didn’t make sense for us to build it; it would have been too hard, there have been too many moving parts, and then post-acquisition, we really love what the VS Code team was building over there, and you could see it; it was just going to work. And we had this one person, well, not one person. There was a bunch of people inside of GitHub that do this, but this one person at the highest level who’s just obsessed with make this work on my iPad.

He’s the head of product design, his name’s Max, he’s an ex-Heroku person as well, and he was just obsessed with it. And he said, “If it works on my iPad, it’s got a chance to succeed. If it doesn’t work on my iPad, I’m never going to use this thing.” And the first time we booted up Codespaces—or he booted it up on the weekend, working on it. Came back and just, “Yep. This is going to be the one. Now, we got to work on those, the sanding the stones and those fine edges and stuff.”

But it really does unlock a lot for us because, you know, again, we want to become the software developer platform for everyone in the world, you got to go end-to-end, and you got to have an opinion on certain things, and you got to enable certain functionality. You mentioned Cloud9 before with Amazon. It was one of the most confounding acquisitions I’ve ever seen. When they bought it I was at Heroku and I thought, I thought at that moment that Amazon was going to own the next 50 years of development because I thought they saw the same thing a lot of us at Heroku saw, and with the Cloud9 acquisition, what they were going to do was just going to stomp on all of us in the space. And then when it didn’t happen, we just thought maybe, you know, okay, maybe something else changed. Maybe we were wrong about that assumption, too. But I think that we’re on to it still. I think that it just has to do with the way you approach it and, you know, how you design it.

Corey: Sorry, you just said something that took me aback for a second. Wait, you mean software can be designed? It’s not this emergent property of people building thing on top of thing? There’s actually a grand plan behind all these things? I’ve only half kidding, on some level, where if you take a look at any modern software product that is deployed into the world, it seems impossible for even small aspects of it to have been part of the initial founding design. But as a counterargument, it would almost have to be for a lot of these things. How do you square that circle?

Jason: I think you have to, just like anything on spectrums and timelines, you have to flex at various times for various things. So, if you think about it from a very, very simple construct of time, you just have to think of time horizons. So, I have an opinion about what GitHub should look like in 10 years—vaguely—in five years much more firmly, and then very, very concretely, for the next year, as an example. So, a lot of the features you might see might be more emergent, but a lot of long-term work togetherness has to be loosely tied together with some string. Now, that string will be tightened over time, but it loosely has to see its way through.

And the way I describe this to folks is that you don’t wake up one day and say, “I’m going on vacation,” and literally just throw a finger on the map. You have to have some sort of vague idea, like, “Hey, I want to have a beach vacation,” or, “I want to have an adventure vacation.” And then you can kind of pick a destination and say, “I’m going to Hawaii,” or, “I’m going to San Diego.” And if you’re standing on the East Coast knowing you’re going to San Diego, you basically know that you have to just start marching west, or driving west, or whatever. And now, you don’t have to have the route mapped out just yet, but you know that hey, if I’m going due southeast, I’m off course, so how do I reorient to make sure I’m still going in the right direction?

That’s basically what I think about as high-level, as scale design. And it’s not unfair to say that a lot of the stuff is not designed today. Amazon is very famous for not designing anything; they design a singular service. But there’s no cohesiveness to what Amazon—or AWS specifically, I should say, in this case—has put out there. And maybe that’s not what their strategy is. I don’t know the internal workings of them, but it’s very clear.

Corey: Well, oh, yeah. When I first started working in the AWS space and looking through the console, it like, “What is this? It feels like every service’s interface was designed by a different team, but that would—oh…” and then the light bulb went on. Yeah. You ship your culture.

Jason: It’s exactly it. It works for them, but I think if you’re going to try to do something very, very, very different, you know, it’s going to look a certain way. So, intentional design, I think, is part of what makes GitHub and other products like it special. And if you think about it, you have to have an end-to-end view, and then you can build verticals up and down inside of that. But it has to work on the horizontal, still.

And then if you hire really smart people to build the verticals, you get those done. So, a good example of this is that I have a very strong opinion about the horizontal workflow nature of GitHub should look like in five years. I have a very loose opinion about what the matrix build system of Actions looks like. Because we have very, very smart people who are working on that specific problem, so long as that maps back and snaps into the horizontal workflows. And that’s how it can work together.

Corey: So, when you look at someone who is, I don’t know, the CTO of a wildly renowned company that is basically still catering primarily to developers slash engineers, but let’s be honest, geeks, it’s natural to think that, oh, they must be the alpha geek. That doesn’t really apply to you from everything I’ve been able to uncover. Am I just not digging deeply enough, or are you in fact, a terrible nerd?

Jason: [laugh]. I am. I’m a terrible nerd. I am a very terrible nerd. I feel very lucky, obviously, to be in the position I’m in right now, in many ways,
and people call me up and exactly that.

It’s like, “Hey, you must be king of the geeks.” And I’m like, “[laugh], ah, funny story here.” But um, you know, I joke that I’m not actually supposed to be in tech in first place, the way I grew up, and where I did, and how, I wasn’t supposed to be here. And so, it’s serendipitous that I am in tech. And then turns out I had an aptitude for distributed systems, and complex, you know, human systems as well. But when people dig in and they start talking about topics, I’m confounded. I never liked Star Wars, I never like Star Trek. Never got an anime, board games, I don’t play video games—

Corey: You are going to get letters.

Jason: [laugh]. When I was at Canonical, oh, my goodness, the stuff I tried to hide about myself, and, like, learn, like, so who’s this Boba Fett dude. And, you know, at some point, obviously, you don’t have to pretend anymore, but you know, people still assume a bunch stuff because, quote, “Nerd” quote, “Geek” culture type of stuff. But you know, some interesting facts that people end up being surprised by with me is that, you know, I was very short in high school and I grew in college, so I decided that I wanted to take advantage of my newfound height and athleticism as you grow into your body. So, I started playing basketball, but I obsessed over it.

I love getting good at something. So, I’d wake up at four o’clock in the morning, and go shoot baskets, and do drills for hours. Well, I got really good at it one point, and I end up playing in a Pro-Am basketball game with ex-NBA Harlem Globetrotter legends. And that’s just not something you hear about in most engineering circles. You might expect that out of a salesperson or a marketing person who played pro ball—or amateur ball somewhere, or college ball or something like that. But not someone who ends up running the most important software company—from a technical perspective—in the world.

Corey: It’s weird. People counterintuitively think that, on some level, that code is the answer to all things. And that, oh, all this human interaction stuff, all the discussions, all the systems thinking, you have to fit a certain profile to do that, and anyone outside of that is, eh, they’re not as valuable. They can get ignored. And we see that manifesting itself in different ways.

And even if we take a look at people whose profess otherwise, we take a look at folks who are fresh out of a boot camp and don’t understand much about the business world yet; they have transformed their lives—maybe they’re fresh out of college, maybe didn’t even go to college—and 18 weeks later, they are signing up for six-figure jobs. Meanwhile, you take a look at virtually any other business function, in order to have a relatively comparable degree of earning potential, it takes years of experience and being very focused on a whole bunch of other things. There’s a massive distortion around technical roles, and that’s a strange and difficult thing to wrap my head around. But as you’re talking about it, it goes both ways, too. It’s the idea of, “Oh, I’ll become technical than branch into other things.” It sounded like you started off instead with a non-technical direction and then sort of adopted that from other sides. Is that right, or am I misremembering exactly how the story unfolds?

Jason: No, that’s about right. People say, “Hey, when did I start programming?” And it’s very in vogue, I think, for a lot of people to say, “I started programming at three years old,” or five years old, or whatever, and got my first computer. I literally didn’t get my first computer until I was 18-years-old. And I started programming when I got to a high school co-op with IBM at 17.

It was Lotus Notes programming at the time. Had no exposure to it before. What I did, though, in college was IBM told me at the time, they said, “If you get a computer science degree will guarantee you a job.” Which for a kid who grew up the way I grew up, that is manna from heaven type of deal. Like, “You’ll guarantee me a job inside where don’t have to dig ditches all day or lay asphalt? Oh, my goodness. What’s computer science? I’ll go figure it out.”

And when I got to school, what I realized was I was really far behind. Everyone was that ubergeek type of thing. So, what I did is I tried to hack the system, and what I said was, “What is a topic that nobody else has an advantage on from me?” And so I basically picked the internet because the internet was so new in the mid-’90s that most people were still not fully up to speed on it. And then the underpinnings in the internet, which basically become distributed systems, that’s where I started to focus.

And because no one had a real advantage, I just, you know, could catch up pretty quickly. But once I got into computers, it turned out that I was probably a very average developer, maybe even below average, but it was the system’s thinking that I stood out on. And you know, large-scale distributed systems or architectures were very good for me. And then, you know, that applies not, like, directly, but it applies decently well to human systems. It’s just, you know, different types of inputs and outputs. But if you think about organizations at scale, they’re barely just really, really, really complex and kind of irrational distributed systems.

Corey: Jason, thank you so much for taking the time to speak with me today. If people want to learn more about who you are, what you’re up to, how you think about the world, where can they find you?

Jason: Twitter’s probably the best place at this point. Just @jasoncwarner on Twitter. I’m very unimaginative. My name is my GitHub handle.
It’s my Twitter username. And that’s the best place that I, kind of, interact with folks these days. I do an AMA on GitHub. So, if you ever want to ask me anything, just kind of go to jasoncwarner/ama on GitHub and drop a question in one of the issues and I’ll get to answering that. Yeah, those are the best spots.

Corey: And we will, of course, include links to those things in the [show notes 00:33:52]. Thank you so much for taking the time to speak with me today. I really appreciate it.

Jason: Thanks, Corey. It’s been fun.

Corey: Jason Warner, Chief Technology Officer at GitHub. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review in your podcast platform of choice anyway, along with a comment that includes a patch.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.