Matt and Phil are joined by Matthew Reinbold, director of API Ecosystems and Digital Transformations at Postman, to talk about Postman's State of the API 2021.
Show Notes
Matt and Phil are joined by Matthew Reinbold, director of API Ecosystems and Digital Transformations to discuss Postman's State of the API 2021 report, detailing various data points from around the API world from which specification people turn to, to how confident people feel deploying their APIs. They also discuss various topics around remote work, how APIs enable more remote work and what will happen in the next few years for APIs.
Notes:
Matthew on twitter: https://twitter.com/libel_vox
Postman's State of the API
Notes:
Matthew on twitter: https://twitter.com/libel_vox
Postman's State of the API
Creators & Guests
What is APIs You Won't Hate?
A no-nonsense (well, some-nonsense) podcast about API design & development, new features in the world of HTTP, service-orientated architecture, microservices, and probably bikes.
Matt Trask: Cool.
Welcome back to APS.
You won't hate episode 17.
I have Phil with me and we're joined by a very special guest today.
Matthew Reinbold, fresh from postman, who is a director
of API ecosystems and digital transformations here to talk
about their report, the 2021 state of the API ecosystem.
Matthew, how's it going?
Matthew Reinbold: It is going.
I am happy to be here first time, caller, long time listener.
Is that how we say that?
Matt Trask: I think that's yeah.
It's how you say it.
Yeah.
So I mean, for those of you, like in the off chance that
someone doesn't know who you are in the API ecosystem
world can you give us a little bit kind of about yourself?
Like you manage two different newsletters, at least
as well as a pretty prolific Twitter presence as well.
But if someone hasn't run into you, like.
Matthew Reinbold: Well, yeah, well, first off, thanks for calling it prolific.
Some people would call it annoying, but yeah, I I manage a fair number
of tweets over at Twitter slash L I B E L underscore Vox, reliable Vox.
That's where I talk about digital transformation
and APIs and a lot of technology stuff.
Occasionally.
Fights with blockchain and NFT enthusiastic.
But then I also manage, I also manage a newsletter called net API notes,
where for almost 200 issues, going back to 2015, I've covered the landscape.
I've shared essential bits of information.
I've tried to boil down the, the.
Current climate and get it right into just the most essential
things that decision makers need to know and care about.
And then I do a fair amount of blogging on a blog.
That's very imaginatively named Matthew reinbold.com.
In there, I talk about a fair number of things as well, but in,
in, in short my passion is really about coaching people, helping
people, teaching people to get better with their API ecosystem.
Matt Trask: That's really cool.
So one thing that kinda stuck out to me cause it's, so
we're going to be talking about the 20, 21 Sidi APR report.
However, I'm curious since you've been doing it
now since 2015, you've been keeping notes on.
The API world.
How does your kind of, I hate to say this phrase, the 30,000 foot
view of everything that, you know, from 2015, how does that kind
of line up to what you saw with the 2021 state of the API report?
Matthew Reinbold: Oh, that's interesting.
So there's definitely.
Maturing as a industry, we've gone through a number of phases.
Those of us that have been around the block a few times, see trends come.
And most often they, they tend to roll away.
And over that time we have to develop models so that we can kind of.
Pick the, the, the wheat from the chaff, you know, what, what are
the properties of something new, some kind of buzzword, some kind of
hyperbole that we can latch onto and say, yes, this is worth investing in.
This is worth our interest in our effort versus, yeah, this is some
marketing system, some spin as I'm looking at the 20, 21 postman report.
I see.
Where we've come.
It's gone from being single point to point integrations.
One-off bespoke API APIs to where we're now talking about things as ecosystems.
We're now talking about collections of
these things and how entire organizations.
Manage these as, as something that's beneficial, something
that's collaborative and, and managed as a separate entity
rather than, than each individual unit I've got Phil here.
So I have to use the forest for the trees analogy
rather than just managing the individual API trees.
There's now a greater awareness of what the forest, what
the forest role is in the company and how to manage that.
In a unique way, as opposed to the individual pieces.
I will say for those that are listening, like I'm one of the things I want to
highlight right up front here is that you don't have to enter an email address.
It's not behind the page.
We really felt strongly at postman that we had to get this information out to
the most number of decision-makers so that they could make better decisions so
that they could be informed as they're developing their strategies and roadmaps.
So if you go to postman.com/state-of-api, you'll be able to download.
With out any worry about having somebody from sales follow up
with you later, or getting spam in your inbox, it's free for all.
We want this information to be used.
We want the dialogues to happen.
We want the discourse to be rich and for me and frothy.
And so please, you know, don't let past marketing spam.
Stop you from checking this out.
We want this in the hands of people.
Phil Sturgeon: Fantastic.
That's good to hear.
I mean, that's I haven't got around to reading
it as you might have seen from Twitter.
Life has been a bit of a mess recently just spending far too much
time in the field, as opposed to in the field doing APA stuff.
But, yeah, that's definitely always been a concern of mine, of, you know,
you hear about these white papers and reports and you just know so many
of them like should have just be in the blog post, but instead that like
a PDF that and you've got to enter information and then you just get
like that fifth email, like, why didn't you reply to my previous four?
I was like, I don't know who you are.
I just want to read this thing.
So yeah, I'm glad you folks are going in a different
direction, but Maybe just taking a step back.
Like, what is the state of API is report all
about where are you getting your information from?
What sort of research is being done?
And what's the hospital.
Matthew Reinbold: Great question.
So this is, as far as I know, the largest survey of its kind, we
had more than 28,000 people respond to our latest in a series.
What we tend to do is try and track where the industry is at.
And typically that's been around certain areas.
Like how much time do you spend developing API APIs?
What kind of tools are you using?
Really good stuff there tracking the growth of, of
the industry and the maturation of the industry.
What I brought to the table this year.
Was an interest on finding the behaviors that
lead to sustainable, healthy API ecosystems.
Like so much of what we talk about when it
comes to API ecosystems is still very anecdotal.
We tell stories about the Bezos Amazon memo, where we
talk about like Twilio or Stripe, but when it comes to
decision makers in large organizations, they're still.
Trying to pull at what are decent KPIs, what are the behaviors I
should be grooming or promoting within my company to make sure that I
can keep producing quality API experiences again and again and again.
And so what we did with this report that I'm really proud of is
dig deep and discover, like, what are the correlating behaviors
in organizations that lead to good things happening for companies?
Phil Sturgeon: Okay.
That's interesting.
Cause I think.
There's always this question around, like,
what's a good API and what's a bad API.
Right.
And that's just such a nebulous, almost pointless topic so
often, because you're just going to end up with opinions about
camel case versus kebab case and opinions about rest versus
graph UI, and all the nonsense that we love to fight about.
And there's going to be someone with a fever at HTTP status code.
And none of that actually matters, but you're talking about more of the
business level stuff or what, what sort of things have come up as like.
Really interesting results from, from your survey about how to
build a good API what's what's, what's new and what's interesting.
Matthew Reinbold: Right.
Well, one of the things I wanted to look at was some of the
insights that popped out to me when I was reading accelerate.
So accelerate is like from.
The previous decade, but it was written by Nicole Forsgren, Jess humble, Jean
Kim, they came together and tried to figure out like, what was it about dev ops?
That was so powerful.
And they wanted to do it in a, in a way that
quantified things, not just like, Hey, this is awesome.
You should be doing it, but like get to the meat and potatoes
of why is this powerful and why should businesses adopt dev ops?
And as they went through their research they ended up discovering
that there was really four things, four metrics that showed how dev.
Made for better organizational performance.
And those things were lead time, deployment, frequency, meantime to
restore, or how quickly you recover and the change fail percentage.
And I thought, huh, that's really interesting.
Now that's for dev ops, but if these things are so
instrumental in having organizations outperform.
Their peers.
Can we find the same correlation with API APIs?
If we have the same behaviors, can we therefore then draw a line and
say, if you have these things, if you have positive aspects of these four
attributes, can you then have a more sustainable, more powerful API program?
And based on our survey results, the answer is yes.
So I can, I can go in and how we, how we drew that correlation.
Phil Sturgeon: I'm curious, what sort of metrics are We, looking at?
Matthew Reinbold: yeah.
So first off we asked people on a 10 point scale.
What, how, how well do you think that you've become API first?
So out of our 28,000 respondents, they looked at this 10 point
scale and they, they put themselves, you know, how they felt
approximately 8% of the people that responded said, yes, we are
either a nine or a 10 on the scale for API first, we said fine.
And then we went through and we said, okay, you
know, how long does it take you to make an API?
Are we talking hours, days, weeks, so on and so forth.
And we also said, okay, you know, not just time to produce, but how
frequently you deploy and how many times do you have a deployment failure?
Meaning like you put something in production, but it didn't work.
Right.
So you have to roll back and then like, what was your time to recovery?
Like when an outage does occur and let's be.
And outage always occurs at some point.
Like how, how quickly can you recover from those things?
So we got these nice, you know, bell curves and everybody
kind of clumped toward the center on these things.
And then we said, okay, Now the magic is we go back to that
first question, the people that say their API first that
have some kind of strong belief that they're doing API first,
let's see how they compare to their peers on these metrics.
And again, and again, all for these items, API, first people perform better.
So, you know, taking one example here.
API first people were able to deploy 17% faster
than their peers and you know, in a day or less.
So if you are API first and granted, there, there
might be some subtlety in how a company defines that.
But bottom line, if you are API first, you perform
better on these metrics than your counterparts.
Phil Sturgeon: Interesting.
And yeah.
Seeing, seeing as you raised it, what is API first?
There's, there's a lot of different definitions floating around.
Right.
And so just for listeners that might not have listened
to everything we've ever talked about and read every blog
post we've ever read ref ever wrote how do you define it?
Matthew Reinbold: Sure.
Well, first for people that haven't heard this and
haven't listened to every episode, shame on you.
Second, I define I defined API first and.
Making the API experience or the interface, the
primary means for the functionality exchange.
So not viewing, like I'm going to create this functionality
and then subsequently go and some other team or, or some
other project we'll be wrapping this thing in an API.
It's thinking of creating an API experience as
the primary exchange mechanism with dysfunctional.
Not a library, not a module, not a class, the API.
So this is slightly different than API design first, which is, I am going
to subsequently talk to stakeholders, create a model, whether that's in an
open API document or some other means, but I'm going to sketch that out.
Test my assumptions, and then subsequently only begin code after.
That's API design.
First, I do draw a line between those two.
They are very copacetic.
They, they work together like peanut butter and
chocolate, but there, there is a difference.
You can, you can do API first without necessarily being API design first.
Phil Sturgeon: For sure.
Oh, well, we've got you on a roll.
You're doing these really well.
What is API as a product?
Matthew Reinbold: Ooh, API API as a product.
So that is creating an API with the.
Awareness that it will have a roadmap.
It will have ownership beyond just being put into a production
environment that it will grow and change and subsequently
necessitates the kind of modeling responsibilities and, and
awareness that it will be growing and changing over time.
Phil Sturgeon: Okay.
So instead of, yeah, API first is your product should have an API.
And that will be managed by the team who was making this product.
And API as a product is a slight variant of API.
First, that kind of takes that API out of that generic
functionality team and says the API itself is the product.
And another team potentially on the same
team will be making a product using that
Matthew Reinbold: Right.
I, I would, I would, I would venture there's a lot
of large enterprise environments for which API for.
It's about a project that gets the thing into production.
And then that thing is left to operate and run on its own.
Perhaps there's some monitoring, perhaps some observability,
but the actual team that made it is off doing the next thing
and the next thing and the next thing there's not the idea that.
This is a long lived item that, that produces
some kind of business functionality value that is
competing in a complex dynamic marketplace like that.
That's the API product side of the house.
Phil Sturgeon: Hm.
Matt Trask: So the, I guess like the, the big question to bring up,
I think right now is what did the pandemic do for the API ecosystem?
Matthew Reinbold: Well, you know, first of all, I want
to just stress that, that this thing that we kind of hand
wave is the pandemic was actually like multiple congenital.
Crises all at once.
Right.
You know, I, I want to, for the audience, like we're talking social
unrest and political upheaval and supply chain disruption, and the, the
pandemic was really a catch all for a tremendous amount of business stress.
And what we've seen in the report is the
usage of APIs, the number of API APIs the.
Amount of focus and care on API.
APIs has increased tremendously with that pandemic because
business leaders, technology leaders are struggling
with this amount of change, this amount of disruption.
And so having architectures that are slow to change,
difficult to change is just not cutting it in this.
Set of multiple crises.
So any kind of architectural advantage that allows them
to change rapidly change quickly to do different things
with how their development investment is deployed.
So, you know, for example, taking that one dev team that was altogether
in the office and being able to break it down into microservices
to allow for greater asynchronous operation, greater flexibility.
Those are the architectures that are being sought right now.
Matt Trask: Yeah, that makes sense.
I mean, it always here in America, I don't know
if it feels sing, but you know, like there's.
At the core level there.
So like the whole, did we go back to the office
and be Sandy the office upheaval as well.
So it makes sense that there is kind of like a, a struggle on rapping,
like getting non-technical CEOs, CTOs, CFOs their heads around the
game-changing, this of APIs that doesn't surprise me at all to hear
that they're still kind of, I don't want to say struggling, but unsure.
Maybe like,
Matthew Reinbold: Well, and, and, well, I, I think that's an
interesting perspective because it assumes that leaders were in
command and control positions of how the labor was divided anyway.
And I would actually, I would actually posit that it's the opposite.
It was everybody immediately going and running to their
home offices and working in a remote work environment.
The change in the communication paths changed the
architectures that were subsequently produced by those teams.
It's Conway's law in effect.
And therefore, as we, as we look forward, as we look forward to what's going to
happen, I would, I would venture that the organizations that pull people back
to centralized locations, for whatever reason, I'm not going to debate whether
that's good or bad, but the people that pull the development teams back to.
see, like the Terminator two bad guy they'll reform remold because there
will be more efficient communication patterns when everybody's face to face.
Whereas those organizations that continue to have a
distributed workforce will have more distributed architectural
patterns because that's how communication is happening.
Phil Sturgeon: That's really interesting.
I haven't really thought about it before, but I, I, I bet there's been
an uptick in kind of API design first, specifically due to this as well.
Right?
Because my experience working we work was, was pretty awful as far as like
API planning goes and as a result, APA architecture and API performance and
Matthew Reinbold: You don't say you should blog about that.
Fail.
Matt Trask: Yeah.
Phil Sturgeon: 25.
I'm going to do a book about that shit.
Matt Trask: Have you tweeted about this yet?
Phil?
I'm not sure if anyone knows your true
Phil Sturgeon: I did a talk.
I did a talk recently.
But yeah, there was, there was such an element of like, we're real
in an open plan office, playing ping pong together and shooting each
other with nerves that there was never any effort on API contract being
written down in any shape or form because you're all sitting about.
And you're just like, what's that end point?
Cool mate.
Oh, if slash whatever.
Oh, is that a, is that property of booty?
It's a string called true with QuoteWerks and then you didn't have a need
to write it down because you just show it over, over the top of Nerf fire.
And I, I do wonder if remote work, well, not necessarily remote work, but
quarantine remote work has helped push people more towards it because if
you can all be sitting around asking each other, you're going to be typing.
The contract over slack.
And if you're going to be typing it out over slack,
which is inherently ephemeral, then you might as well
type it into a Yammel file and commit that in the repo.
And then you can have design reviews around the board
request or other tools that the offer, that sort of thing.
So, yeah, that's, that's just completely a hypothetical and something I'm
thinking the second night and check that, but I'm sure it's happening.
Matthew Reinbold: I completely agree.
And, and let me throw in something that's not in the report, but
something that's got me totally geeked out and I'm watching for on
my radar, we are going to see the greatest Renaissance of API design
documentation that we've ever seen in the next couple of years.
Now, granted, you know, as far as Renaissance goes, maybe Renaissance.
Documentation are not that great.
So, you know, let's put the party hats back in the closet, but
what we're seeing with the great resignation right now is all of
that knowledge that people acquired in their heads is leaving.
It's headed out the door and I've read reports like up to
80% of how to do things with API APIs is in people's heads.
Like at we work.
If you needed to know how API has worked.
You know, you knew Phil was the guy that could get you straightened and
Phil Sturgeon: I didn't have a clue.
That was the problem.
I was trying to find out how to do it.
Matthew Reinbold: Okay.
So I wasn't, it was somebody, it was somebody
on the other end of a, of a Nerf battle away
Phil Sturgeon: Someone who quit already is the person that you.
Matthew Reinbold: But right now in organizations like you have
this phenomenon where a tremendous number of people are leaving
organizations and they might've been the sole person who knew where
the end points were or knew how that particular tricky function worked.
And as organizations are trying to deal with this and recover
and still be productive, there's going to be a greater emphasis
on having that crap written down, having things documented.
Organizations don't have aren't left on their back foot like they are right now.
So whether that's heavy handed processes, whether that's just a
greater appreciation for documentation among the staff, that's
left, whatever that manifests as there's going to be an increasing
amount of emphasis on documentation, because people have seen
that too much was stuck in people's heads and it's not sustained.
Phil Sturgeon: Yeah, that's a really good point.
I mean, and not just kind of documentation, but
the whole open API as a source of truth earlier on.
And I figured it has to be, has to become more noticeably important when Yeah.
They've, they've lost the whole team.
How the API works and you know what it's like, code's always a bloody mess.
Cause you just hacked up within about what
over the place and patch things and fix things.
And what about and yeah, when they find themselves rewrite
in the API, cause no one can really take it over and no one
remembers how it works and there's no documentation for it.
And it's just too hard to figure out when they just make a brand new one.
And they have a whole brand new team doing it.
Cause they've already lost all that stuff.
Matthew Reinbold: Yeah.
Phil Sturgeon: That's a situation that a lot of managers and business
people are going to say, how can we go about avoiding doing this?
And I just hope there's someone in the room that says, well,
APA designed first would really help avoid this problem because
otherwise they'll just repeat all the same mistakes again.
Matthew Reinbold: Right.
Absolutely.
Whether it's design first or tools that help analyze existing traffic
and write the document afterwards, like whatever you got to do, get
that written down and start taking some notes against it because.
It's it, I believe right now with the great resignation.
It's an Achilles heel.
That's probably hampering a lot of organizational ecosystems right now.
Matt Trask: Yeah, I would definitely agree.
I mean, it shows in the report under open API three dot oh, 44% of
people are aware of it, but they don't use it 28% say they use it.
12% said they use it, the love it.
So even just combining use it and use it in love.
It still does not match aware of we're not using it.
Which means that there is definitely a.
A river to jump over.
So to speak, to getting more people on, to open API, which
is probably currently like the standard for API documentation
right now which comes back to your point, which allows them
to start writing things down and start documenting things.
And Phil gets it by bus tomorrow.
We work is still going to be okay.
It very well could happen.
Which is exactly why I use that example.
And it, it, yeah, it it'll give the organization a little bit more or
a little less reliance on what's in people's heads a little bit more
stability in case great races, nation three Datto happens in three years.
You know, you don't know what's gonna happen.
Phil Sturgeon: Is that when everyone resigns from web three point now,
Matt Trask: please.
Don't don't threaten me with a good time.
Like I've already, I've already muted those web
three and NFD on my Twitter and it cleaned it up so
Phil Sturgeon: Why do you hate progress, man?
Matt Trask: A lot of reasons.
I'm a combustion at heart?
No.
Matthew Reinbold: Hey, if you don't,
Phil Sturgeon: particular messages of this progress that are the problem.
Matthew Reinbold: if you, don't stand for something, you'll fall for anything.
Good for you, Matt.
Matt Trask: yes, I've always wanted my life
to be attributed to a, a Hamilton quote.
So I am glad I did.
I can check that one off to get back onto the actual topic and not just
bashing NFTs for an hour and a half, which sounds like a lot of fun.
What you the most about this report?
Like what was something that you read that just you weren't expecting?
Matthew Reinbold: I, I think there was two things that when
you combine them together it made me tilt my head and go, huh?
The, the first is that more than anything else?
Including speed to production.
People want quality API APIs.
They want stability.
They want some other things reliability.
But the primary thing that people want out of their, their API APIs is quality.
And yet when it came to whether or not people had time to test.
Everybody acknowledged that testing was good.
Tested was valid, but nobody had enough time for testing and it's like, huh?
These two things kind of seem like.
The, the two sides of a coin, right.
You know, people aren't getting the quality that they want, but everybody
acknowledges that they don't have enough time to do testing, even
though they recognize the testing is an extremely valuable type thing.
So I think when it comes to socializing this report and
talking to decision-makers and doing the kind of coaching
that I so often do, I, this is one of those things too,
to bring up, like how in your program are you supporting.
Testing and ensuring that enough is being done there so that your
developers feel like you're, you're reaching the kind of quality
goals that, that you're, you're promising to the rest of the world.
Phil Sturgeon: Hm, do you, is the survey broken down by role?
So can you, can you look to see if.
Managers and engineers have a rule, very interested in, in high quality.
And engineers are going, but we don't have enough time, but
the manager's like, oh, they definitely have enough time.
Matthew Reinbold: Right.
So we do have a breakdown by role and job title, but I
don't have the numbers in front of me that, that combined,
and show me how to break down the quality question.
Phil Sturgeon: Yeah, that'd be an interesting one.
Cause yeah, so many roles, so many organizations, I just take it as like a
universal truth is that companies are just, you know, business and product
are demanding feature, feature, feature, feature, feature, and engineers are
just like screaming, just keyboards on fire, trying to try to hit them goals.
And everything's just wonky as hell.
And it seems to be everywhere I go.
There's not enough to have.
There's not enough time for QA.
They might've got rid of the QA team because it's slowed
down product and slowed down delivery of features.
Yeah, everyone wants high-quality API has, but no one wants to put
the time in to testing because testing is inherently hard and slow.
Matthew Reinbold: Right.
And kind of along those same lines, another stat that jumped out at me was that
76% of the people building API APIs have less than five years experience doing.
I mean, you know, as far as restful APIs now,
we're, we're more than a decade into that journey.
So that stat leaps out at me, like what is it about API development, where
we're getting people with zero to five years experience like what's happening.
There are the successful API builders, aging out and becoming management.
it, are they moving on to web three O and NFTs?
Like, like what is, where are our experienced API builders
and why are these critical pieces of business infrastructure?
In the hands of relatively younger people.
That's not to say that they can't be doing a good job, that, that it's
impossible to build a great web experience at your first time at bat.
But it's also something where I think
everybody on this call would probably agree.
Experience counts, experience matters.
Ha being around the block once or twice, you pick up a
feel for what's beneficial, what's maybe a little wonky
and you can imbue that into a better design at launch.
So, you know, where are the.
10 year, the 12 year, the 15 year veterans.
And why are they not the primary source of API infrastructure development?
Phil Sturgeon: Yeah.
Some that I've seen so much, again, just, I love complaining about we work.
Pretty much everyone that was a junior developer, Right.
Like the vast majority, what, what you need developers and their
role responsible for creating you know, there's like a hundred API
APIs and, you know more than a hundred junior developers with just a
sprinkling of seniors who were more on the cowboy coder end of things.
Not, not to be rude, you know, like startup, you need
to be super agile, super fast, not, not a perfectionist.
And so, so many of the problems where this is, this person's first
rails app, like they know how to accept incoming Jason parameters
and they know how to spit something back from the database.
And.
That's that, and they know how to make a web request.
So he talks to . He talks to F talks to G in the
thread, and then no, one's got a timer anyway.
So everything falls over, like, things like that.
The sort of thing you realize, if you've been doing APIs for five years,
or for 10 years, you've been doing it for 10 years, you wouldn't do that.
You just wouldn't do that.
You'd put something in a sidekick job and then implement
a web socket or a web hook, or literally anything else.
But.
That's the sort of thing you do when you consider like
HTP failures or server downtime, to be an edge case that
is like some weird scenario that probably won't happen.
And when you've been doing it for a longer time, you're like you,
you change your mindset to this web requests probably won't work.
And on the off chance that it.
This is what should happen.
And you just get really defensive and paranoid and have like
25 different guard statements and, you know, 25 different types
of ex exception catching and, and every single circuit breaker
and trigger warning that you can possibly put on this thing.
And there is, yeah, there is a change in mind.
Around around that kind of it doesn't, I'm not being a gatekeeper or at least
they're saying you've got to be doing EPS for 10 years until you're good.
But when you start out, you you're such, you're more of an optimist.
You haven't seen it go wrong in as many ways.
You haven't had cascading failures and you haven't
had all these terrifying things that happen.
So that, that is definitely a concern for me is that I think, yeah.
Happy, happy path development.
When you go from having one AP.
To having 20 or a hundred, the, the the chance of
straying off the happy path gets exponentially worse.
Right.
And, and that's just something, I think a lot
of these younger developers on experience with.
Matthew Reinbold: Right.
Even, even when it comes to design, having used API APIs, having to
incorporate the API APIs, you better understand what makes a good
description and what is just a reiteration of the, the name itself.
Yeah.
Yeah.
If I have a field called date of birth and the description is just the
birth, that, the date that the person was born on, like, well, what was the.
do I need to refresh it?
Or is it cashed?
You know, like, can I store it or is it part of some kind of regulatory PII?
And I shouldn't, you know, I can use it, but I shouldn't store, like,
there's so many issues that once you've been down that road, and
then you're asked to produce an API, you bring that experience with
you and you put it into the description that adds so much that yeah.
I, I, I, I don't know.
How we continue to get that, that experience
circulating and get that in front of people.
But I think it's really important.
Matt Trask: Well, I must wonder too, like how many of those, like
experienced API builders are getting swallowed up into Stripe?
Twilio, Google.
And kind of almost locked away working on their API APIs and not able to
share their experiences down the road to junior developers in their own
companies or interim networks, things like that too, because it feels
like you do your five, seven years as developer, you get pulled into the
management game and then all of your knowledge is still there, but you're
having to balance both managing a development team, hitting your goals.
Pushing out products because you've got to make money for the business.
And all of your knowledge that you've worked so hard to gain is kind
of sidelined in the name of profits or KPIs or whatever it might be.
Matthew Reinbold: Possibly there's, there's
certainly exceptions that spring to mind.
One of which is Tim Burks and the team over at Google
and with the number of resources that they put out there.
For their APIs.
It's, it's kind of a mouthful, but if you do a Google search for that,
they've produced a tremendous amount of documentation about how they
support API APIs at scale, how they do their design reviews, how they
think about consistency and cohesion across their entire footprint.
So that certainly what you described could be the case in some places.
You know, I, I, I do think that it's not necessarily the default that's
people go off to these big organizations and then just disappear because
the folks at Google around Tim and his crew they're doing some great work.
Phil Sturgeon: So I've been sat in the room with you having these sort of
conversations your last job, Right, Like a center of excellence type stuff.
You, you get a bunch of smart people and me together and start talking
about what, what would help with these various different problems?
Like how do we do APA design reviews?
How do we do governance?
What standards should we be interested in?
So I think sometimes yeah.
Experienced developers can get sucked up into these companies and kind
of finish and end up having that scale was used for something else.
But I, I think companies that have those governance processes,
like they're sharing their experience back by creating style
guides, by creating programs that they explain how these, how
these like API designed life cycles or API life cycle should work.
And that's a way that they can essentially.
Distribute their experience.
So instead of like, I know what to look for when I'm
reviewing a poor request, they can create a style guide.
That means that everyone will do that.
I think the danger there is that when style goes focus on what, instead
of why then, then you kind of lose some of that experience because
it just seems like arbitrary decisions delivered from upon high.
Right.
You just get.
Do it this way, but, but Y I've read loads of style guides recently.
And, and some of them, I should probably show the examples.
It's just like, do this.
Like, why you don't tell me what to do?
You don't my dad, like, it just, I couldn't figure
out what they possibly could have meant by it.
Cause usually I can look at something.
Why might they mean that?
Oh, that reminds me of a thing that happened along these lines.
They probably got burned by that before, and they want to avoid
it, but if you don't see why it just sounds arbitrary and you're
not actually teaching anyone on anything, but if you do it right.
that that can be really helpful.
Matthew Reinbold: Right.
And it's also essential that if you're designing these systems like a governance
or like a center of excellence that you have the feedback process that you
have, the, the communication cycles so that when people do have that kind of.
That they have a recourse.
It's not a dead end.
It's not either you do this or you're punished for it, but
oh, if this doesn't make sense, here's who you talk to.
Here's how you can escalate your concern here is how you elevate your edge case.
And we can have a discussion about it and you can help co-evolve
this thing, because you own this as much as somebody else,
the, the phenomenon that you described, where it's a dead end.
It's thrust upon you.
You don't have ownership of that.
And as a developer, that does not feel good, that does not
invest you in seeing the long-term growth of, of that system.
You want to burn that system.
You want to be the rebels flying through the death star trench.
You want to take that thing down?
So what's essential is to realize.
You provide the avenues for people to, to voice their
concerns, voice their questions, and make them feel heard
in such a way that their process, the process is theirs.
It's not something done to them.
It's it's their process.
Phil Sturgeon: I'm just laughing about the death star rebel situation.
Now I'm completely distracted.
I need to go rewatch some star wars.
I don't know.
Matt Trask: I mean, your, your thought on the ownership thing is
also interesting cause And we like watching the junior Twitter,
the junior developer Twitter circles, which is not the end all
be all of it all, but there is a large emphasis on if you want to
make more money, you need to jump ship every two years on average.
And that kind of removes the does or not the desire, but like
the, the ownership of any sort of product from a junior developer,
because in two years, they're going to be onto another thing.
They're going to be onto another system.
Codebase, maybe another language and it, it does kind of bring
back, like, how do you entice people to have ownership, even if
they only are going to plan to say somewhere for a short period?
Because we all know that like having, like you said, having that
ownership is going to kind of make you more invested, more caring, more
thoughtful, more empathetic towards whatever it is that you're building.
Matthew Reinbold: Right.
I mean, we're veering into management territory, which I'm happy to talk about.
I, I know.
Matt Trask: very allergic to management.
So.
Matthew Reinbold: But I, I was just reading Harvard business review.
Hey, I'm fun at parties too.
So I was reading Harvard business review talking about
COVID and the great resignation and the, the management
challenges that, that come with that and what we need more.
In all companies is a feeling of belonging, a feeling like we have a
career progression feeling like our, our, our work has impact and all
too often management, just as about making sure people don't do dumpster.
Right.
You know, I'm, I'm here to police you
because the organization doesn't trust you.
And it leads to all kinds of weird effects.
Like, Hey, if you actually want to grow your career, you need to leave.
You need to hop companies every two years and let's be clear that may work, but
it's still very disruptive, not just for the company, but for the individual.
'cause they're having to rebuild all of those social
structures, their relationships, their patterns,
the routines it, it's not, it doesn't come for free.
And so from a management standpoint, if you can show people
how to have that fulfilling career, how to fulfill those needs.
They don't have to jump ship every two years.
There's no reason that that has to be the default blueprint.
And from a company standpoint, you actually benefit from
that accrued experience rather than having a developer.
That's done the same thing.
Five times you get five years of experience.
That's really powerful, really tremendous.
And that, that ultimately not only leads to
better APIs, but leads to a better employee.
So there is a disconnect we need to work with our management layers.
It shouldn't just be the technician that
has some headcount is by default manager.
There needs to be an appreciation for how those are unique skill sets.
Those are unique muscles that need to be exercised, but.
If we can create that fulfilling sense of duty then, and
that the career path for these individuals, we can get
them off of this kind of binge and purge career treadmill.
Matt Trask: So that's a really, yeah, that's a
really good way to put the whole two year turn.
And I mean, it comes back full circle to what you just said
earlier, which is, you know, 75% of API has been developed
now or done by people with less than five years experience.
And that's probably because of the same, people are jumping, jumping, jumping.
Whereas if you can keep them around, make
them happy, make them feel like they belong.
We might actually start seeing that number.
Dropped significantly to more experienced API developers building
more thoughtful API design with, with years of knowledge built up.
So I think it'll be really interesting to see kind of what
happens with this great resignation how that all shapes up.
And then it'll be interesting to see to kind of the 2022 say the API report.
How does that.
How, how will things change from a year in a year going forward?
And what can we expect possibly looking at these two years,
the next five years after that, the next 10 years growing on
different trends, you know, we might see NFTs ruling the world.
We might see graph QL.
Rolling.
Phil Sturgeon: No comment.
Matt Trask: Matthew is kind of shrugging
Phil Sturgeon: we're all sad.
Now, rural sat now, NFTs powered by graft UL, problem solved.
Can you, can you still right click that?
No, you can't.
It's like a post.
So.
Matt Trask: Well, there goes
Matthew Reinbold: Each unique query is published as an innovator.
And you can put the ownership of that query in a blockchain
so that you don't have the centralized point of failure.
Phil Sturgeon: I was going to thank you for being for,
for making this podcast sound intelligent for once.
And,
Matthew Reinbold: And then I ruined it.
Sorry.
Phil Sturgeon: and then you.
Matt Trask: no, no, no, you didn't ruin it.
You just brought it back down to its normal level of ridiculousness.
Phil Sturgeon: Fantastic.
No.
Do you have any predictions for what we're going
to see in the, in next year's state of this report?
Because then we can play that clip back and laugh at how wrong you were.
Matthew Reinbold: Oh, lovely.
All right, well, let me have a few minutes to sandbag my answer.
No, I think there's a tremendous amount of, of areas where we
can take this correlation that I talked about before behaviors.
You know how the question immediately becomes well, okay.
If these four behaviors are so good and are present
in high-performing API companies, how do we get there?
And this year we had a little bit around leadership and what leaders do.
To get an API first company.
I think there is a lot of exploration we can do there to
really dial in and say, okay, we know these things are good.
How do you get there?
How do you promote these things?
How do you, how do you get it so that you are able to
deploy in a minimal amount of time or recover faster?
What are leaders in those organizations doing?
That's one of the things I'd love to dig into obviously.
A lot of post pandemic aftermath.
There's been a tremendous amount of published about how this digital
transformation and, you know, we're so much more flexible and
adaptable because we, we are now doing all our conversations over zoom.
And I look at that and I, I scratch my head because.
Digital transformation, at least in the non buzzword compliant
way is a whole lot more difficult than just moving everything
to a slack conversation or a, or a zoom conversation.
Like it means fundamentally dismantling your policies and procedures
and reinventing them in a way that digital technology lends itself to.
So figuring out what that post pandemic landscape looks
like and how we're still feeling the knock on effect.
Is going to be something that's also going to be very interesting to explore.
Matt Trask: Yeah, that's definitely true.
I mean, I think one thing I would like to see is, is that
number of people who know open API, but don't use it start
to gradually shift down and people who are using open.
Start to shift up, which, you know, from a silver right back
to having documentation and some sort of notes about their API.
So when the, the knowledge people do eventually leave because everyone
leaves the company at some point, the knowledge isn't necessarily leaving.
And instead we're, we're kind of leaving a
better legacy to the people following us.
Yeah, definitely.
Matthew Reinbold: Here here.
Matt Trask: Cool.
Matthew, thank you so much for taking some
time out of your, your, your day to talk to us.
We really appreciate it.
Look forward to having you back in roughly a year's time to talk 20, 22.
Say the API report
Matthew Reinbold: I love it.
Let's do it.
Pencil it in right now.
Matt Trask: Yep.
It's it's on my calendar.
I don't know what I'll be doing in a year from
today, but I know for a fact we'll be talking again.
If you want to get.
Matthew on Twitter.
He is at libel Vox, L I B E L underscore V O X M.
And we'll throw the link to your blog and Twitter
in the show notes as well as everything else.
Awesome.
Cool.
Thank you so much.
We appreciate it.
Phil Sturgeon: Yeah.