Screaming in the Cloud - What GitHub Can Give to Microsoft with Jason Warner
Episode Date: October 7, 2021About JasonJason is now the Managing Director at Redpoint Ventures.Links:GitHub: https://github.com/@jasoncwarner: https://twitter.com/jasoncwarnerGitHub: https://github.com/jasoncwarnerJason...cwarner/ama: https://github.com/jasoncwarner/ama
Transcript
Discussion (0)
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.
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? I've got five bucks on DNS, personally. 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 slash screaming in the cloud.
Observability, it's more than just hipster monitoring. got code deployment solved for, but when it comes to databases, we basically rely on desperate hope
with a rollback plan of keeping our resumes up to date. It doesn't have to be that way.
Meet Liquibase. It's 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 that
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.
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.
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 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. 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, Linux, 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. Maybe 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 social coding as an aspect, and maybe turning it 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 with 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
of 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 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.
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.
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,
in my opinion.
And I think that goes to what you're saying is if we put a deployed Azure button on top of this and Azure's 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 happened
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.
They're all enterprise IT, enterprise dev shops who are buying from the top down.
Now, there is still the bottoms-up adoption that'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 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-
Oh, hating Microsoft was my entire personality.
And it was honestly well-deserved, right? Like they had anti-competitive practices and they
did some nefarious things. And, you know, 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 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, 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 interesting gaming platforms.
And 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 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 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 VMwares or IBMs 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.
OK, 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 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's like, it sounds like something they might have
done, but Cloud9 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 would 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 has 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 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 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 unindependent.
It was bringing that 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 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 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++
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 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 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, 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. This episode is sponsored by our friends at Oracle HeatWave, a new high-performance query
accelerator for the Oracle MySQL database service, although I insist on calling it MySquirrel.
While MySquirrel has long been the world's most popular open-source database, shifting from transacting to analytics required way too much overhead and, you know, work.
With HeatWave, you can run your OLAP and OLTP,
don't ask me to pronounce those acronyms ever again,
workloads directly from your MySquirrel database
and eliminate the time-consuming data movement and integration work
while also performing 1,100 times faster than Amazon Aurora
and two and a half times faster than Amazon Redshift at a third the cost. My thanks again
to Oracle Cloud for sponsoring this ridiculous nonsense. 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. Back in the before times, and ideally the after times,
whenever I travel, 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 the 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 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, again, if we want to become
the software development 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 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 cloud nine 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 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 in San, 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, it's you can
you have to have an end to end view and you 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. 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, ah, funny story
here. But, you know, 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,
you know, human systems as well. But when people dig dig in they start talking about topics like i'm
confounded like i never liked star wars i 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 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, you know, some interesting facts that people end
up being surprised by with me is that, you know, I, 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, 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.
Even if we take a look at people who 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 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, 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, 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 say,
I started programming at three years old or five years old or whatever. And I 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 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. And 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 nineties 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 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.
My name is 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 in your podcast platform of choice anyway, along with a comment that includes a patch. If your AWS bill keeps rising and your blood pressure is doing the same, then you need
the Duck Bill Group.
We help companies fix their AWS bill by making it smaller and less horrifying.
The Duck Bill Group works for you, not AWS.
We tailor recommendations to your business, and we get to the point.
Visit duckbillgroup.com to get started.
This has been a humble pod production
stay humble