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, Cory.
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 duck bill 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 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 gonna 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, do 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.
I, 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,
you, 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,
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 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, you know, we launched, um, dependency
management, uh, packages, actions with built in CI.
We've got some deployment mechanisms.
We've got advanced security underneath it.
We've, uh, 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 1.
If you see it as world's, you know, largest, maybe most
developed software development platform, that's Evolution 2.
And in my mind, it's natural place in 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.
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 to lose.
But I can see a path to where it could become far better than it is.
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.
One hundred percent.
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 stacked, 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.
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 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'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, you know, 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, it's very, very true.
I mean, we've entered a different spot with
cloud computing and 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, 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, 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 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'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.
It's, 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 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, uh, well, 20 years before previous to Satya joining.
And I was one of those people in the late
90s who would write M 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, uh, honestly, it was well deserved, right?
Like they had anti competitive practices and they did some nefarious things.
And, you know, I talk about, you know, 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 it well deserves 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 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 independently.
You know, we got LinkedIn, 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, it's Microsoft's the landmass underneath the water that
binds them all in 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 on 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 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 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.
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.
Okay.
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 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, all the hyperscalers there.
I mean, I'm basically insulting everyone, which is kind of my shtick.
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 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, 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, 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, uh, 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, you
know, a little bit 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 an independent.
It was bringing that in and helping us.
They got a lot of that stuff done.
Microsoft 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, uh, 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 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, we'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 hyper clauses, 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 exercise 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
here at the duck bill 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.
Back in the before times, and ideally the after times, whenever
I travel around the world, 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, 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 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's 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 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, 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 gotta, we gotta 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, 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, 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, it 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, uh, the, the
way you approach it and, you know, how you design it.
Sorry, you just said something that, 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, but 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 go on vacation, and literally just throw a finger on the map.
You have to have some sort of vague idea that like, Hey, I wanna
have a beach vacation, or I wanna have an adventure vacation.
And then you can kind of pick a destination and say, I'm going to Hawaii.
I'm going to San Diego.
And if you're standing on the East coast knowing that 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.
Well, 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 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.
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 had, 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,
you know, 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, um, 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 in, they start talking about topics
like I'm I never liked Star Wars, never liked Star Trek,
never got into anime, bored 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.
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 wanted to take advantage of my newfound
height and, uh, 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 like in most engineering circles.
You might expect that 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 boot camp
and don't understand much about the business world yet.
They, 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.
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, 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.
Like, I literally didn't get my first computer until I was 18 years old.
And I started programming when I got to high school co op with IBM at 17.
It was Lotus Programming at the time.
Had no exposure to it before.
What I did though in college was, IBM's 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, I'm from heaven type of deal, like, you'll 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?
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 that 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's 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 uh, it'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 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.