Screaming in the Cloud - Summer Replay - What GitHub Can Give to Microsoft with Jason Warner

Episode Date: August 6, 2024

In this Summer Replay, we revisit our conversation with Jason Warner, where he explained to us how to “Git” on it. Since this episode’s original airdate, Jason has since went on to become the CEO and co-founder at poolside, but his time at GitHub has given him the expertise to inform folks about all the exciting things GitHub has going on. Listen as Jason offers insight into GitHub’s successes which have led to their acquisition by Microsoft. He breaks down his own history at GitHub and its vision to become the “worlds most important software company.” Jason dives into some of the details of GitHub acquisition and the possibilities for what they want to achieve, and where they expect to go within Microsoft. Jason and Corey discuss how to talk about the cloud for its current, and importantly, future clients. Jason talks about what GitHub will bring to Microsoft, and perhaps how it’ll be for the better. Tune in, because the getting is about to “git” good.Show Highlights:(0:00) Intro(0:27) Duckbill Group sponsor read(1:01) The role of GitHub(4:46) How GitHub and Azure can coexist(7:08) When to adopt to the cloud(9:55) GitHub’s impact on Microsoft(13:24) Experiencing acquisition(19:34) Misconceptions of GitHub(21:36) Duckbill Group sponsor read(22:20) Practicality of Codespaces(25:34) Designing software with a purpose(28:40) Dispelling nerd culture in software(30:55) Starting in a non-technical direction(33:52) Where you can find more about JasonAbout Jason Warner:Jason Warner is the co-founder and CEO of poolside. He serves on the operating board of Bridgewater Associates. He has previously worked at GitHub as their CTO.Links:GitHub: https://github.com/@jasoncwarner: https://twitter.com/jasoncwarnerGitHub: https://github.com/jasoncwarnerJasoncwarner/ama: https://github.com/jasoncwarner/amaOriginal Episode:https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/what-github-can-give-to-microsoft-with-jason-warner/Sponsor:The Duckbill Group: https://www.duckbillgroup.com/

There's a reason why TK is running Google Cloud right now, and Amazon classically has been very, very bad at selling to the enterprises. They just happen to be the first mover. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jason Warner, the Chief Technology Officer at Jithub,

although he pronounces it differently. Jason, welcome to the show. Thanks, Corey. Good to be here. This episode is sponsored in part by my day job, the Duck Bill Group. Do you have a horrifying AWS bill? That can mean a lot of things. Predicting what it's going to be, determining what it should be, negotiating your next long-term contract with AWS,

or just figuring out why it increasingly resembles a phone number, but nobody seems to quite know why that is? To learn more, visit duckbillgroup.com. Remember, you can't duck the duckbill bill. And my CEO informs me that is absolutely not our slogan. 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 I, 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 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 copying and pasting and emailing Microsoft Word documents around isn't ideal. 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, can you remember the old days when people had to email tar files around or drop them in weird spots? 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. What if it may be involve a fax machine this time? But no, that is actually what they do.

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 shuttle you out of the room, and rightfully so. But it works for one of the most important software projects in history, Linux. 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 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. 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 do you, what could you do in a different way? And, you know, social coding as an aspect and maybe turning into a social network or the resume and all of 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 we've built in CI. We've got some deployment mechanisms. We've got advanced security underneath it. We've got code spaces 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 in where it should be, given what it has done already in the world, has become the world's most important software company. I don't mean the most profitable, I just mean the most important. 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 bootcamp 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.

100%. I mean, the obvious thing that any of the 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 stack ranked against each other based upon the ingress and egress of all the data on GitHub, you know, and various reactions to that. And 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. And 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 it, 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 people will choose it. And that is to me what we're after. 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. It's very, very true. I mean, we've entered a different spot with cloud computing and the bell curve of the 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 all that sort of stuff, blah, blah, blah, 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 is running Google Cloud right now. And Amazon classically has been very, very bad at selling to the enterprises. They just happen to be the first mover. 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. 100% 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. And they're all enterprise IT, enterprise dev shops who are buying from the top down. Now there is still the bottoms up adoption and it's going to be happening. 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. We have tops-down selling still, or now. 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.

Obviously, the skepticism is 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 dollar sign in various forms. I was 18 or 19 years old and just got into it. Oh, hating Microsoft was my entire personality. And it was honestly well-deserved, right? They had anti-competitive practices and they did some nefarious things. And I talk 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 bomber years and later Gates years and things of that nature. So we all deserve 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 were 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. 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 dare say, gotten to a point where if 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. I have to give Microsoft a ton of credit too 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

is 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 has acquired a whole bunch of companies and it 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.

It's 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. 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, 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 there we go. I have to imagine with someone in your position, it's a slightly different experience. 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 the 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 or VMware's or IBM's of the world to take us 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'd 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. It 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. 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 the idea of would anyone even want to buy us? And then, duh, of course they would. And you look at the hyperscalers, for example, you have, well, you could sell it to Amazon and they could pull another cloud nine 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's like, it sounds like something they might have done, but cloud nine sounds way too inspired for an AWS service name. So maybe not. And it is real.

You could go sell it 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. 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 will try to hug us too deeply or integrate us too quickly or things of that nature. I think that just takes a deep understanding of who the players are and who the egos involved are. And I think egos is actually played more into acquisitions than people will ever admit. What I saw was based upon 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 Launch is 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 the clouds. And what 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, it allowed 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 to 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, I got a very different feel and kind of confirmed a couple of things. And then when I had my very first conversation with Nat, who I've known for a while before that, I realized like, yep, okay, this is the one. Drive hard at this. If you could do it all again, would you change anything meaningful about how you approached it? You know, I think I got very lucky doing a couple of things. There was very intentional aspects of, you know, I tried to serendipitously show up where Diane Greene was at one point or 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 try to have, 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 running independent. It was bringing Nat

in and helping us. I 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 particularly our sales team and finance team inside of GitHub already. 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? I still think the biggest misconception of us is that we're a co-host. Every time I talk to the Red Monk 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++ 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 and 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. And 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. 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. It's quite interesting because I think that everything breaks at scale, as we all know about from the hyperclause, 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-sized 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 ways, you're just like, well, I think that we'll have that conversation at some point, you know, but we got a hundred plus million repos and 65 million developers using us on a daily basis. It's a very different world. Here at the Duckbill Group, one of the things we do with, you know, my day job is we help negotiate AWS contracts. We just recently crossed $5 billion of contract value negotiated. It solves for fun problems such as how do you know that your contract that you have with AWS is the best deal you can get? How do you know you're not leaving money on the table? How do you know that you're not doing what I do on this podcast and on Twitter constantly and sticking your foot in your mouth?

To learn more, come chat at duckbillgroup.com. Optionally, I will also do podcast voice when we talk about it. Again, that's duckbillgroup.com. One of the things that I really appreciate personally, because, you know, when you see something a 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. The only computer I've 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 CodeServer 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 I, at least from my perspective, that the world may not have fully wrapped its head around yet. Great observation. Before the acquisition, we were experimenting with a couple of different editors that we want 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's a bunch of people on side 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-Hiroku person as well. And he was just obsessed with it. And he said, if it works on my iPad, it's got a of product design. His name's Max. He's an ex-Hiroku 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 up on the weekend, working on it, came back and just, yep, this is going to be the one. Now we've got to work on the sanding the stones and those fine edges and stuff. But it really does unlock a lot for us because, you know, again, if we want to become the software development platform for everyone in the world, you got to go end to end and you've got to have an opinion on certain things and you've got to enable certain functionality. You mentioned cloud nine before

with Amazon. It was one of the most confounding acquisitions I've ever seen when, when they bought it, I was at Heroku. And 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 that 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, OK, maybe something else changed. Maybe we were wrong about that assumption too. But I think that we're onto it still. I think that it just has to do with the way you approach it and, you know, how you design it.

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'm only half kidding on some level where it's, if you take a look at any modern software product that is deployed into the world, it is, it seems impossible for even small aspects of it to have been part of the initial founding design. But as a counter argument, it would almost have to be for a lot of these things. How do you square that circle? 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 in 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 the 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 that 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 likely 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 at 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've designed 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. Oh, yeah. When I first started working in the AWS space and looking through the console, it's like, what is this? It feels like every services interface was designed by a different team, but that would, oh, and then the light bulb went on.

Yeah, you ship your culture. It's exactly, 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 like 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, very strong opinion about what 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 it maps back and snaps into the horizontal workflows. And that's how it can work together. 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? I am 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, ah, funny story here. But I joke that I'm not actually supposed to be in tech in the 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 it turns out I had an aptitude for distributed systems and complex human systems as well. But when people dig in, they start talking about topics like I'm confounded. Like, I never liked Star Wars Wars and never liked Star Trek, never got into anime board games. I don't play video games. You are going to get letters. When I was at canonical, oh my goodness. The, uh, the stuff I tried to hide about myself and like learn like, so who's this Bobo Fett dude. And, uh, you know, at some point, obviously you don't have to pretend anymore, but

you know, people still assume a bunch of stuff because, quote, nerd, quote, geek culture type of stuff. But some interesting facts that people end up being surprised by with me is that I was very short in high school and I grew in college. So I decided that I want 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 at one point, and I ended 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. 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 who profess otherwise, we take a look at folks who are fresh out of a bootcamp and don't understand much about the business world yet. They have transformed their lives. Maybe they're fresh out of college. Maybe they 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 and then 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?

No, it's about right. People say, hey, when did I start programming? And it's very in vogue, I think, for a lot of people say, I started programming at three years old or five years old or whatever, and I got my first computer. Like, I literally didn't get my first computer until I was 18 years old.

And I started programming when I got the 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, we'll guarantee you a job, which for a kid who grew up the way I grew up, that is man from heaven type of deal. Like you guarantee me a job inside where I 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 uber geek type of thing. So what I did is I tried to hack the system. What I said was, what is a topic that nobody else has an advantage on for 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 systems 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, just, you know, different types of inputs and outputs. But if you think about organizations at scale, they're really just really, really, really complex and kind of irrational distributed systems. 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? Twitter is probably the best place at this point. Just Jason C. Warner on Twitter.

I'm very unimaginative of my name. It's my GitHub handle. It's my Twitter username. And this is 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 Jason C. Warner slash 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. And we will, of course, include links to those things in the show notes. Thank you so much for taking the time to speak with me today. I really appreciate it. Thanks, Corey. It's been fun. Jason Warner, Chief Technology Officer at Jithub. 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 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.