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.