Mike Bifulco: Hello, and welcome
back to APIs you won't hate.
. My name is Mike Biko one of
your APIs you won't hate.
Co-hosts, co-founders,
whatever you wanna call me.
Today I'm sitting down to chat with my
good friend Danny Sheridan from Fern.
Danny's been on the show
before about six months ago.
We talked in March of 2023, shortly
after I believe Danny, you had just
finished going through Y Combinator's
Winter Batch for this year.
And it's great to have you back.
I'm really excited to, to hear
what's happened since then.
And what's going on with you?
How are you doing today?
Danny Sheridan: I am ecstatic today.
I think that as we talked last,
like you said, six months ago.
My team was just coming out
of the Y Combinator program.
We were able to use that acceleration
that they provide to go raise
the seed round of fundraising.
And at this point, we've been growing
the business by increasing the number of
customers that we work with, which we can
talk about today, as well as expanding
the functionality that Fern provides for
companies that have public rest APIs.
Mike Bifulco: Love that.
Yeah, I'm, I'm super
interested to get into it.
As you know you know, we're, we're big API
fans around here, so nerding out on this
stuff is definitely in the wheelhouse.
Before we do that, let's take a step
back and why don't you tell me the
audience listeners about Fern from
a 1 0 1 0 1 level, what is Fern?
What is it for, and who
would be interested in it?
Danny Sheridan: Yeah, I think the
best way to start there is to talk
about the inspiration from Fern, which
is that I was at AWS as a product
manager before Co-founding Fern, and my
co-founder, whose name is Deep, was at
Palantir Technologies as an engineer.
And one of the things that both of us got
to experience was that Palantir and AWS.
Both design APIs, starting with
the API specification or the
API contract, they don't start
by writing backend server code.
They don't start by
writing API documentation.
Instead, they start in A-A-J-S-O-N
or a YAML file describing the
endpoints, the data models.
And the errors that can be
thrown by those endpoints.
And so that was a big inspiration.
I wanna give, we stand on the shoulders
of giants here at Fern and specifically
we do that with Amazon's Smithy, which
is an open source project they created.
And Palantir's Conjure and Mike,
we'll include those in the show notes
for folks that wanna check 'em out.
Both, both of them are,
are in-house built tools.
AWS and Palantir that really showed
us the power of going API first,
they allow a front end and backend
engineer, maybe even a product manager
to collaborate on designing the API.
And then once the API contract is
established, you run it through
code generation technology and
those code generators produce a
couple of different artifacts.
They can produce server boilerplate code.
that looks like maybe you're using the
Java springing framework or the TypeScript
Express, or even Python's fast, API.
And you wanna take my API contract and
make sure that I create all of those
routes and I'm implementing them.
The second thing that those tools
created were client libraries.
So these are the SDKs.
It's nice to have a typed client
that you get auto complete in
your ID of whichever you're using.
Typically, we see VS
code as the most popular.
But when I like hit, when I'm using the
SDK, it'll show me all of the resources
that are available and the operations
that I can perform on those resources.
And so that might be like payment create.
And that's a really nice
developer experience because
they don't have to leave.
Their IDE while they're coding to go
check what the documentation says.
It's part of the SDK and they,
they've kind of got docs on hover
where they can see details about
each, each of those resources or
operations, uh, how they behave.
And the third thing, Mike, is in addition
to some server code and SDKs, is that
these tools, these conjure and SMITHY
tools from the companies that I mentioned,
produced a version of API documentation.
In AWS's case, it was
literally the A-W-S-A-P-I docs.
I don't think it'll be a surprise to
folks and Mike, tell me if I'm wrong, that
AWS does not hand write all of their API
documentation and their API reference.
Mike Bifulco: Yeah.
I think if you've browsed it once or
twice, it's probably apparent that
either someone from a different universe
made some of them, or they're, they're
not necessarily human generated.
Yeah.
Danny Sheridan: It was really inspiring
to me, though, to see an example.
a human is not responsible for
updating the docs anytime that the
API changes because at Amazon we had
that concept of good intentions, which
is that good intentions.
Mike, when someone says, anytime
we change the API, we will
remember to update the docs.
Good
intentions fail because people are busy
Mike Bifulco: That's
Danny Sheridan: and instead Exactly.
And instead, what we should
be doing is having tooling.
That supports us in
accomplishing our goals.
And so Fern is a way where companies
with public rest APIs use Fern to
offer SDKs in popular programming
languages and API documentation
that documents those rest APIs.
Mike Bifulco: I think our listeners
will identify with this quite a bit.
I think we're in an interesting, like.
Point in history, this sort of inflection
point where maybe even between now
and the last time you and I chatted
I think something has happened sort
of in like the, the general public
mindset that people suddenly trust
machines to do more intelligent things.
And by that I mean like the, the
zeitgeist of AI tools, AI wrappers for
everything has made people a lot more
lenient to let the the, the . Software,
write things for them, create things
for them, do creative work, do work.
That was prior quite manual tasks.
And I think Fern is happening at a really
interesting time in that inflection
where suddenly it's like, oh, actually
maybe I can run my, my open API spec
through something and it can generate
client libraries and also maybe generate
meaningful documentation where I think
if you asked me that two years ago,
I would've been like, not a chance.
I'm gonna hire an army of technical
writers and they're gonna do
a great job for me on this.
I'm curious to hear your sort of feelings
on that and, and also your feelings
on like the, the world of working
with people who are generating code as
opposed to writing code manually too.
Danny Sheridan: let's talk about
the biggest objections that I hear
when I talk to customers or
prospects specifically about Fern.
One of the objections that is common is I
don't trust a machine to generate my SDK.
My developer experience is
important to my business.
It increases our revenue if we can
acquire new customers, and I don't
wanna trust that to something that.
eVery time I run the code generator
could have a different output.
Right.
And what I tell people is, Fern
does not use LLMs to generate code.
Mike Bifulco: Hmm.
Danny Sheridan: We have bitten, we
have built a rule-based system and
if we're getting more specific,
we built a compiler that takes
in an open API spec and generates
TypeScript or Python or Java files.
Mike Bifulco: Yeah.
Danny Sheridan: And so one of
the important things to folks
right now is determinism.
I run the fern generator more than one
time, will I get the same SDK output?
If, if the SDK would change every time
because of determinism, that, that
would be a, a major blocker to adoption.
And so right now, the most popular
way is to generate SDKs are all,
there is no L-L-M-S-D-K generation
tooling that has become popular.
Not to say it can't happen one day.
I think folks want determinism
and then they also wanna see why,
like why did the code generator
output a specific line of code?
And they really like being able to
poke into the open source source code.
And so Fern is open source because
our customers are developers and they
like to see how the magic happens.
Mike Bifulco: Yeah, that's
an important point too.
And I'll make sure we have notes on
a link to fern's GitHub in our show
notes so our listeners can go and kind
of browse that and, you know, also
contribute if if they're so inclined.
Yeah, I think, I think that's.
A valuable point to make that like
deterministic LLMs are not a thing
in, in the current state of the art.
They may one day be, I don't know
if that's even possible based on,
you know, what an LLM technically
is, but you want your generated
libraries to be predictable and the
same and by that nature also testable.
And I feel like that's something that
probably comes out of people using Fern is
you can generate a library and if you can
generate it the same every time, you can
test it and be certain that what you're
getting is something that at least passes
the tests that, that you've provided.
Danny Sheridan: aNd Mike, I'm
thinking about one of our customers.
The company is called Cohere.
They're an AI platform for enterprises
that is growing in popularity.
They are LLM experts and they have
chosen fern and do not wanna use LLMs
to produce their SDKs because their
main source of revenue is their API
Mike Bifulco: Yeah,
Danny Sheridan: and a problem in
their SDK would literally impact
their ability to generate income.
And so they, they, they were
almost willing to put an engineer
against it when they saw that they
could, instead of having to build.
SDKs by hand.
They could buy an SDK generation tool.
They
opted to buy and not build.
And I think you're right.
You mentioned things are changing
around the API developer experience
market, should we call it that
the developer experience market um, things
around SDKs, API documentation.
We are seeing a shift where in the
past companies would've said, and we've
been working on FERN for 18 months now.
18 months ago, my folks would've said.
We, the only option to provide great
SDKs is to put an engineer against it.
Mike Bifulco: Yeah, definitely.
Definitely.
Danny Sheridan: do this by hand.
This is a, a ticket in
our engineering queue.
And I think that there's been a shift
in the last 18 months where more
engineering leaders, this typically is
happening at the CTO or an engineering
manager, platform engineer who says
there are now tools like Fern where I
can pass in an open API specification.
I can get out high quality
idiomatic SDKs that I'm comfortable
putting in front of my customers.
Mike Bifulco: Sure.
Yeah.
I think also worth pointing out that
even the discussion you and I had
six months ago has changed pretty
dramatically in as much as back then
at least, I don't think we talked
too much about documentation either.
But I feel like that's maybe part
of like the, the holistic picture
of providing great developer
experience to people consuming your
client libraries, whether they're
internal or external to your company.
GEtting both a functioning client
library and then the documentation
to build it is the story.
That's, that's the story.
You need to have both of those
things for your thing to be valuable.
And, and I think there's
probably like, I don't know.
I would imagine you've probably seen
patterns in your customers that they're
probably all looking for like a platonic
ideal that they want to have, you
know, great developer experience and
great documentation to go with it.
What, what does that like lifecycle look
like for maybe finding, acquiring and, and
delivering solutions to your customers?
Danny Sheridan: Mike, you said kind of
who is the gold standard, who is the ideal
right now for developer experience,
and I think that over the last at least
three years, the answer has not changed.
The company with the best developer
experience in the world is Stripe.
Mike Bifulco: yeah, sure.
sure.
Danny Sheridan: think
that folks would find that agreeable,
but Mike disagree on the why.
Mike, you have to
reason through it together.
Mike Bifulco: Let's do it.
And before we get into that, this
is probably where I should mention.
I'm a former Stripe employee.
No bad blood between me and Stripe, or me
and Danny as far as I know, at least but
you know, a reasonable call out here too.
Yeah.
Let's reason through it.
Walk me through it.
Danny Sheridan: Let's talk about
this as if we're making a, a
recipe and the outcome is the
Stripe developer experience.
I think the question, Mike,
is what are the inputs.
Mike Bifulco: Cool.
Yeah.
Danny Sheridan: And I usually like to
speak in threes, but in this case, I've
got five things on my mind that make the
Stripe developer experience exceptional.
Mike Bifulco: Yeah, hit me.
Danny Sheridan: The first is consistent
design, whichever endpoints you're using
within Stripe's, vast API, you can expect
similar behavior and patterns, like you'll
learn it once and you learned it across
the whole API and any endpoint you use.
Mike Bifulco: Yeah.
Danny Sheridan: To do, especially
as a company grows over.
I mean, Mike, they're well
over a decade old, right?
Mike Bifulco: Sure.
Yeah, absolutely.
Yeah, pat patterns are huge.
And you know, much like you'd imagine
in some places there are teams of
developers maintaining client libraries.
And at AWS there are teams of
people starting with that API spec.
The discussion on consistency
is massive at Stripe.
Making sure that things make sense
from one to the other so that end users
can learn one pattern and apply it
everywhere is super, super valuable.
Danny Sheridan: The
second is documentation.
Developers expect that they, it's easy
to find what they're looking for and
that the information is up to date.
It's very frustrating when you go and
check out what the JSON looks like
for an API response, and it's wrong
because some developer changed
it and forgot to update the docs.
And so Stripe has done
a phenomenal job of.
Automating their documentation and they
have a whole team responsible for it.
Mike Bifulco: Yeah.
Yeah, definitely.
If you are reasonably good at
Googling, you can find a, a talk I
did on Stripe's internal documentation
tools on YouTube somewhere.
Danny Sheridan: The third thing are
SDKs in popular languages, whether
you are a Java, a Python, or a
Ruby developer, you get a client
library that's got auto complete.
Immediately, and you get that
when you're starting your project.
SDKs tend to make integrations
happen in 50% less time, and Stripe
understands that by my last count, they
supported seven different languages or
frameworks that they provide SDKs for.
Mike Bifulco: Yeah,
that sounds about right.
Yeah.
And then to, to that point too,
idiomatic SDKs are important, right?
Like, it feels like python, it
feels like ruby, when you're
writing in that language.
And that's, that's a hard thing
to to accomplish just as well.
Danny Sheridan: All right.
The fourth thing of five errors.
When you run into an error in the
stripe, API, the message that's output
to the developer, it's actually helpful.
It typically links you to a
place in their documentation.
So it's like documentation aware.
It'll give you AURL where you can go to
read more and it might even recommend
a fix as part of the error message.
And that's just, um, Mike, it might
be craft, that's the word on my mind.
Mike Bifulco: Yeah, sure.
sure.
I think so.
And, and that was a revelation too, right?
Like this was not a common thing.
In a world before stripes
developer SDKs existed, like
oftentimes as a API consumer.
Your job was to set debuggers run
console logs and pull your hair out until
you figured out what, what comma was
missing or what type you had incorrect,
or you know, what you had done wrong.
And at best you maybe got a 500 back.
Something like that.
Yeah.
Danny Sheridan: And the fifth thing, Mike,
that's on my mind is around versioning.
When you start, when you open your Stripe
account, your pin to a version of the API,
and from that day on you are, they expect
that you'll be using that API version,
and you have to choose to take an upgrade.
And so Stripe does a phenomenal job
of having backwards compatibility.
They've actually built tooling that they
call gating that we can talk more about
in another episode if you'd like to in.
Mike Bifulco: Sure.
Danny Sheridan: They've, to date,
they've never broken their API.
And I think that's a really expensive
decision because it, you learn a lot
after 10 plus years of doing business.
And I'm sure there are moments that
they would've loved to break the
API, but to date they have not.
Mike Bifulco: Yeah, yeah.
The, those, so let me let me see
if I can kind of sum that up then.
So, versioning error messaging,
client, libraries, docs and
the fifth one is escaping me.
A design right.
Consistency are are definitely
adding up for that the magic.
That's, that's the experience I
want my engineering team to have.
That's also the experience I want
from every client library I consume
from a third party service as well.
Danny Sheridan: Yeah, but Mike, how
many employees does Stripe have?
Mike Bifulco: Engineers.
We have four right now.
Danny Sheridan: Sorry.
At Stripe.
Mike Bifulco: Oh, it's Stripe.
Oh, sorry.
Yeah, yeah, yeah.
Stripe.
Gosh, rounding out a few thousand easily,
I think probably close to five or 6,000.
Danny Sheridan: Yeah.
So
let's compare craft work to stripe's
engineering ability, maybe I'll
call it four to a thousand,
something like that ratio.
It's really,
it's not feasible for companies
to hire engineers to go build this
developer experience infrastructure.
For their company.
And so that is why the market
is turning to buy a solution
that's available for you.
And Fern is filling that
place in the market.
And so the, the idea of Fern is
that we will bring a stripe like
developer experience to your API.
We will do that over.
That's, that's the vision
that we are working toward.
And today we will deliver two things
for our customers SDKs in multiple
languages that are idiomatic.
We take care of publishing them to NPM
and Maven Central and So we take care of
getting 'em to the package managers and
publishing the source code to GitHub.
And the second product that
we offer is API documentation.
Everyone wants the Stripe
like Docs website that fits
your, it matches your brand.
You've got the infinite scrolling page.
You can see the SDKs documented
in the API reference.
That's a really nice feature, Mike.
And Stripe does in a way
where it's auto-populated.
So human does not have to go and
update the code snippets in all seven
SDK languages for every endpoint.
Whenever the API changes,
they have automation for that.
And that's something that Fern has
now rolled out for our customers is
you can get what we call code snippets
for every endpoint showing how to
use your SDK in any of the languages
that you generated for an SDK for.
Mike Bifulco: Yeah.
That's, that's incredible.
That's, that's quite an offering
and, and a bold statement to make.
And I think what I wanna know
from you is like, what, what are
your consumers need to provide?
How do they, how do they get that?
What's
Danny Sheridan: They provide,
they provide an open API spec.
Mike Bifulco: Hmm.
I.
Danny Sheridan: We generate SDKs
and we generate the API docs.
Additionally, if they want to, they can
provide markdown files, which will be the
pages in their documentation if they'd
like to do things like how to get started.
How to authenticate with our API.
Maybe they have item potency.
Those are some of the examples that
we tend to see how pagination works.
So they can add custom pages in
addition to their API reference.
And in my mind, Mike SDKs and API
docs are like peanut butter and jelly.
They just go better when they're together.
You can have 'em separately, but
it's really nice when your SDKs, yeah,
when the SDKs are documented next to the
API reference, it feels most natural as a
developer that wants to go figure out, how
do I integrate with this company's API.
Mike Bifulco: Sure.
Yeah.
So are you able to share any
stories about customers that
you've had who are using Fern?
Danny Sheridan: Absolutely.
How about we talk about, I mentioned
cohere already, so I'll pick another one.
hOw about merge Dev to
give a little?
Are you familiar with that,
Mike?
Mike Bifulco: Past guests
of APIs you and hate.
We have, we recorded an episode with them
maybe a year and a half ago at this point.
Danny Sheridan: Oh, was that my hunch was
probably either Shei or Gale, the CTO.
Mike Bifulco: It was Gil.
Yeah.
We chatted with Gil on,
on APIs, you and hate.
Yeah.
Danny Sheridan: Fantastic.
Mike Bifulco: In case someone
hasn't listened though,
what's the 1, 1 0 1 on merge?
What do they do?
I.
Danny Sheridan: Yeah, merge
is a fast growing company that
developed a unified API that
simplifies integration development.
So there are a lot of popular
SaaS products out there that you
might want to integrate with.
And I'll just give an example.
If I wanna add ACRM integration to my app,
I might want to connect with Salesforce
data, or HubSpot data, or Pipedrive data.
And so for me to go build integrations
with each of those three is pretty
burdensome on my engineering team.
And instead I can go use Merge.
And so Merge is the, is a unified API
platform and is the difference between
building one integration with Just Merge
or building 10 with multiple different
SaaS tools that have changing APIs.
Mike Bifulco: Yeah, from, from what
I remember, talking to GI Merge, they
have a astonishing number of third
parties that they unify into one
place to call, at, at the time when we
chatted, it was like dozens upon dozens,
and I'm sure it's grown since then.
It's, it's definitely a big product.
Danny Sheridan: WE can talk about the,
the problem that merge came to us with,
a merge customer uses the merge SDK
and not a Salesforce or a HubSpot, SDK,
Mike Bifulco: Right.
Danny Sheridan: instead of
having to deal with those
Mike Bifulco: place.
Danny Sheridan: Exactly.
You call 'em all from one place.
Well, that means that merge needs,
I'm gonna call it a kick ass SDK.
They need to have an extremely developer
friendly, well document consistent
across all languages experience.
But they are API experts.
They're not necessarily SDK experts,
and so they teamed up with the firm
team and they move really quickly.
Merge is a fast moving company from
first initial call with us to learn about
what we do to actually going live with.
Was a four week time period, so
really impressive at the speed
that they've been able to move.
Mike Bifulco: Yeah,
my God.
Danny Sheridan: at this point they've
now released a node, Python, Java, go,
SDK, using Fern, and we're together
collaborating on C Sharp and Ruby as
the next languages that'll come out.
It's pretty nice when you have a customer
who pushes you to increase selection.
Mike Bifulco: Yeah, definitely.
Right.
So, so with that then, it sounds
like you've probably expanded the
languages that Fern has delivered
on since March as well, right?
Danny Sheridan: We have
since we last talked, we've
added Python and go and we
will continue adding languages.
It feels like after the top eight
to 10 programming languages,
there's a pretty big drop off.
Mike Bifulco: That's probably fair.
Yeah.
Danny Sheridan: but I could see
us using a good chunk of 2024 to
get there to that top eight or 10.
Mike Bifulco: Cool.
. Okay, so, so Merge is a a fern user
and they've, they've then delivered
their SDKs in, in four weeks.
Is is honestly a staggering
turnaround for something like that.
Like if you're listening to the show,
you should hop over to merge.dev and like
browse, scroll to the bottom of the page.
The footer of their page shows
how many APIs they integrate with.
And it is . Like conservatively a
hundred different, different APIs
they pull into merge, which must
mean that Fern is generating like
mountains of API client library
and documentation for them as well.
Danny Sheridan: Yeah, we generate
hundreds of endpoints for them every
time that they generate code with us.
And one of the things that I want to
call out is at, I was at AWS before
this, as I mentioned, at AWS Andy
Jassy used to talk to the team that
the most successful implementations
of AWS happened when it was top down.
It's just too hard for cloud
infrastructure to go bottom up.
You need a C-level goal, such as
the CTO or CIO setting a goal that
gets everyone on the same North
Star of like getting to the cloud.
And in this case, we see the
same trend happening with SDKs.
It's really hard to go bottoms up.
It's really easy when a leader like
Gil from Merge says, Hey, everyone.
We are using Fern, we're going all
in on offering every SDK language.
They, they provide and puts an engineer.
Actually in our case, there was
an engineer and an engineering
manager that we got to work with
to go live with each of their SDKs.
And I think that's just the right
approach as a leader to identify like
a single threaded leader who's gonna
be responsible for this SDK project
going from first meeting to completion.
Mike Bifulco: Yeah, that's the
right rights kind of investment and
clearly shows you know, a pattern for
success too, and that it worked and,
and that merges now user of Fern.
That's, that's really exciting.
So you, you now have a client
library product and a Docs product.
I.
For people listening to the show.
We also mentioned before that
you to, to get started with
Fern, you need an open API spec.
What does it look like to get started?
How long does that take?
Danny Sheridan: Yeah it, you
install an NPM package, which is
the Fern CLI command line interface.
then you run a command called Fern
Generate and that takes your open
API spec and starts generating a
list of generators that you specify.
So it takes about five
minutes to get started.
Pretty often what our customers
figure out is that their open API
spec is of pretty poor quality.
I
mean that this is like a trend that
you've talked about on this show a lot
and that you've written about of
their, having an open API spec is
not the same as having a high quality
open API spec for your organization.
Mike Bifulco: For sure.
Yeah, it's aspirational.
Definitely intentional, you know, a
lot of, a lot of companies want to
do it, and in practice it's tricky.
It's a bit like starting with test
driven development, like it's, it
sounds like a great idea, but it's
hard to get people to commit to it.
Danny Sheridan: I'll give two
examples of where I think open
API specs that I've seen fall
short just to, to make it tangible
for folks.
The first is that they mention a
bunch of different properties of
an object and they don't add a
description of what that property is.
And I don't know your API as well as, you
know, your API, and so I need some help.
I need a human readable description.
Age means like is age in
days and months and years.
It's really helpful.
You know, an integer for age isn't
very clear to me as a developer
what I should be put using there.
And so one of the things that we see as a
room for improvement is adding description
fields across the entire API spec.
The second area of improvement
are adding examples.
really helpful as a developer to
see an example JS om response,
Mike Bifulco: Yeah.
Danny Sheridan: like very high value.
But in order for.
Fe to know what a response looks like.
We need companies in their open, API specs
to include an example for each endpoint
and the great, the great customers
that we work with that really want the
exceptional developer experience make
that part of their, like their, they
can't ship update API without improving,
without updating their open API spec.
And then improving things like
description fields and examples.
Mike Bifulco: Yeah, I'd imagine
that's a bit of a cathartic experience
too, because it's effectively
like forcing people to invest in
their own reduction of tech debt.
You know, we, we all have this notion
that we want to do a great job of
these things, but frankly, like human
readable descriptions that make sense
and examples and things like that fall
by the wayside pretty quickly when
you're under the gun to get things done.
But that'll turn around
if the tooling takes.
Those things end.
Multiplies the value of it for you.
Right.
And, and I think that's what Fern at
least, is purporting to do here, and I
think that's a really exciting offering.
Danny Sheridan: Mike, do you see a world
where LLMs could be helpful here, where
it's like, help me add some descriptions
and help me add some examples.
Mike Bifulco: Sure.
Yeah, yeah, yeah.
That, that's definitely a place
where I think people would be excited
to you know, to to, to add that
sort of ai magic on top of things.
And maybe an, an interesting
application of that too.
I could see maybe even something where
you're, you're chatting with your
code base, like, Hey, how would I.
Do whatever it is, like take an
ACH payment from someone in Japan.
Right?
Like, how do, how do I do that?
What does that look like?
And, and if your documentation is in order
and your open API spec is well written,
I think that's something that, that is
not too far off in the future for us.
Danny Sheridan: You just touched on
something that I think is just probably
a billion dollar idea, so let's explore
it for a minute together.
Mike Bifulco: yeah.
Far away.
Danny Sheridan: Today API
documentation is like an encyclopedia.
Mike Bifulco: Yeah.
Danny Sheridan: It's got a bunch of
informations and, and a bunch of pages,
and it's your responsibility to go
either look at the table of contents
or look at the glossary, kinda like
the search bar, and you have to go find
what you're looking for, get to the
right section, read it, and digest it.
Mike Bifulco: Yeah.
Danny Sheridan: I speculate that instead
of an encyclopedia experience where you
have to like go find the right page.
You're gonna be able to ask a
question to the encyclopedia.
I mean, this is what SIR and Alexa
wanted to be back then, right?
I can just ask a question
and it goes and finds the
information and presents it to me.
And I could see a future where
you get to someone's API docs
and there's a text input.
And that text input allows you to ask
a question like, I'm using Jango to
call the Stripe API as an example.
Well, let's pick the merge dev
API I'm using to call your API.
I wanna migrate, I wanna use the HubSpot
and Salesforce integration to go create
new leads and it starts writing code for
you, basically a sample app of how you
would, and you get to share that, right?
It's gonna use the Python,
SDK 'cause it's, it knows
you're in a Python framework
and it's going to live, generate you
code that you can start using that
you would never find in their docs.
It's actually combining some of
the word description guides with
the API reference with the SDKs
that now like an LLM Power Docs
understands all of those things to me.
The day that we can go and, and like you
said, have a conversation about what are
you trying to accomplish here at Docs?
Congrats.
You've landed.
What are you trying to do here?
That is not an experience
that I've ever seen.
Have you?
Mike Bifulco: No.
And I think that the, those tend to
be, for me at least, the most exciting
applications of this LLM technology is
where, where it's a second brain that
actually is a second brain, right?
Like in the past few years people
have talked a lot about note
taking and self-organization
and things like notion and.
Rome research and obsidian and,
and being really good about
documenting what you're seeing.
But when the L LMS start putting
that together for you and take the
need to document yourself out of the
picture and can become an educator
for you, I think that's really
interesting and really empowering.
And, and I can see lots of different
people getting into development
as a result of that too, and
I'm really excited by that.
Danny Sheridan: I, I'll
make a speculation here.
'cause it's fun to guess
about the future, isn't it?
Mike Bifulco: No, always.
Yeah.
Danny Sheridan: I think that the number
one consumer of API documentation
in the future, we'll call it three
years from now, is going to be LLMs.
Mike Bifulco: Hmm.
That's really interesting.
Wow.
Well, I guess we're gonna have to put
it on the calendar to have you back on
the podcast in three years, but I'd,
I'd love to have you back sooner if, if
that's something you're interested in.
Danny Sheridan: I,
Mike Bifulco: Danny, let, let's do this.
So tell me about if people are interested
in jumping in and getting started with
Fern, where's the best place to go?
Danny Sheridan: the best place to go is
our website, which is build with fern.com.
Mike Bifulco: We will of course have
that in the show notes along with all the
other things we've mentioned here today.
One other thing I, I like to ask
guests on the show is is Fern growing?
Are you hiring at the moment?
Danny Sheridan: Fern is growing.
We are looking for a
founding backend engineer.
This person would work with
our team in New York City.
It's an onsite role, and they would
be responsible for helping us expand
selection of our SDK generators.
So we're looking for someone who's
excited to be a polyglot that might jump
within a week between Java, Python, and
Ruby, and is excited about languages
and has a high attention to detail.
Mike Bifulco: Yeah.
Very cool that that sounds
like a great opportunity.
Danny Sheridan: And, And,
lastly, Mike, I'll,
I'll share that
the salary range that we're paying for
that role we publish, which is 130 to
$160,000 a year, in addition to a half
percent to 1% equity in a growing startup.
Mike Bifulco: Brilliant.
How's that for Open?
I'm, I'm, I deeply appreciate that.
I think especially in a world where
lots of people are squirming to find
the right place for them getting
to that discussion around like,
what does compensation look like?
Where do you want me to be
and what am I gonna be doing?
It's really hard to get to and,
and I think a lot of companies.
Can and should aspire to
what you just did there.
We'll drop a, a link in the show notes
as well to the job opening here too.
And Danny, where, where's
the best place to get at you?
If people want to shout at you
about SDKs or documentation, where,
where can you be found online?
Danny Sheridan: The best place to
talk to me is actually going to
the build with fern.com website
and scheduling a call.
Would love to ch if folks listen to
this and they're like, Hey, I'm ready.
I'm ready to make my API developer
experience more like stripes.
That's, if that's the
intention, that's the place.
Best place to find me is just book a call.
Let's hop on.
Mike Bifulco: Yeah.
That is an opportunity not to be
passed up friends, I think . Danny a,
apart from being a, a very exciting
person to chat with, I think you're
also super knowledgeable and it's
been great to have you hang out.
I'm looking forward to six months
from now seeing how you've shaped
the, the planet of API developer
experience in that marketplace too.
Thanks for joining so much.
I appreciate having you here.
And looking forward to talking again,
Danny Sheridan: Let's build
APIs that people will love.
Mike Bifulco: add away into it.
All right, Denny, take care.
Danny Sheridan: Cheers.