WEBVTT NOTE This file was generated by Descript 00:00:00.239 --> 00:00:02.549 Mike Bifulco: Hello, and welcome back to APIs you won't hate. 00:00:03.114 --> 00:00:06.214 . My name is Mike Biko one of your APIs you won't hate. 00:00:06.214 --> 00:00:08.254 Co-hosts, co-founders, whatever you wanna call me. 00:00:08.544 --> 00:00:12.684 Today I'm sitting down to chat with my good friend Danny Sheridan from Fern. 00:00:12.894 --> 00:00:15.054 Danny's been on the show before about six months ago. 00:00:15.154 --> 00:00:19.694 We talked in March of 2023, shortly after I believe Danny, you had just 00:00:19.894 --> 00:00:23.314 finished going through Y Combinator's Winter Batch for this year. 00:00:23.684 --> 00:00:24.584 And it's great to have you back. 00:00:24.604 --> 00:00:26.584 I'm really excited to, to hear what's happened since then. 00:00:26.584 --> 00:00:27.464 And what's going on with you? 00:00:27.464 --> 00:00:28.144 How are you doing today? 00:00:29.009 --> 00:00:30.169 Danny Sheridan: I am ecstatic today. 00:00:30.569 --> 00:00:33.809 I think that as we talked last, like you said, six months ago. 00:00:34.619 --> 00:00:37.279 My team was just coming out of the Y Combinator program. 00:00:38.179 --> 00:00:41.679 We were able to use that acceleration that they provide to go raise 00:00:41.699 --> 00:00:43.119 the seed round of fundraising. 00:00:43.819 --> 00:00:48.479 And at this point, we've been growing the business by increasing the number of 00:00:48.679 --> 00:00:52.879 customers that we work with, which we can talk about today, as well as expanding 00:00:52.899 --> 00:00:57.999 the functionality that Fern provides for companies that have public rest APIs. 00:00:59.304 --> 00:00:59.714 Mike Bifulco: Love that. 00:00:59.714 --> 00:01:01.834 Yeah, I'm, I'm super interested to get into it. 00:01:02.174 --> 00:01:05.954 As you know you know, we're, we're big API fans around here, so nerding out on this 00:01:05.954 --> 00:01:07.234 stuff is definitely in the wheelhouse. 00:01:07.814 --> 00:01:11.444 Before we do that, let's take a step back and why don't you tell me the 00:01:11.644 --> 00:01:15.574 audience listeners about Fern from a 1 0 1 0 1 level, what is Fern? 00:01:15.574 --> 00:01:17.454 What is it for, and who would be interested in it? 00:01:17.934 --> 00:01:20.224 Danny Sheridan: Yeah, I think the best way to start there is to talk 00:01:20.224 --> 00:01:25.024 about the inspiration from Fern, which is that I was at AWS as a product 00:01:25.024 --> 00:01:31.854 manager before Co-founding Fern, and my co-founder, whose name is Deep, was at 00:01:31.934 --> 00:01:34.654 Palantir Technologies as an engineer. 00:01:35.154 --> 00:01:41.014 And one of the things that both of us got to experience was that Palantir and AWS. 00:01:42.049 --> 00:01:47.979 Both design APIs, starting with the API specification or the 00:01:48.019 --> 00:01:52.259 API contract, they don't start by writing backend server code. 00:01:52.689 --> 00:01:54.979 They don't start by writing API documentation. 00:01:55.009 --> 00:01:59.739 Instead, they start in A-A-J-S-O-N or a YAML file describing the 00:02:00.179 --> 00:02:02.179 endpoints, the data models. 00:02:03.689 --> 00:02:06.549 And the errors that can be thrown by those endpoints. 00:02:06.729 --> 00:02:08.189 And so that was a big inspiration. 00:02:08.649 --> 00:02:13.739 I wanna give, we stand on the shoulders of giants here at Fern and specifically 00:02:13.839 --> 00:02:18.219 we do that with Amazon's Smithy, which is an open source project they created. 00:02:18.799 --> 00:02:22.859 And Palantir's Conjure and Mike, we'll include those in the show notes 00:02:22.859 --> 00:02:24.179 for folks that wanna check 'em out. 00:02:24.489 --> 00:02:28.099 Both, both of them are, are in-house built tools. 00:02:29.504 --> 00:02:33.864 AWS and Palantir that really showed us the power of going API first, 00:02:34.494 --> 00:02:38.104 they allow a front end and backend engineer, maybe even a product manager 00:02:38.684 --> 00:02:40.904 to collaborate on designing the API. 00:02:41.644 --> 00:02:45.824 And then once the API contract is established, you run it through 00:02:45.934 --> 00:02:50.824 code generation technology and those code generators produce a 00:02:50.824 --> 00:02:51.984 couple of different artifacts. 00:02:52.824 --> 00:02:55.914 They can produce server boilerplate code. 00:02:57.214 --> 00:03:01.534 that looks like maybe you're using the Java springing framework or the TypeScript 00:03:01.684 --> 00:03:04.894 Express, or even Python's fast, API. 00:03:05.034 --> 00:03:08.974 And you wanna take my API contract and make sure that I create all of those 00:03:08.974 --> 00:03:11.854 routes and I'm implementing them. 00:03:13.029 --> 00:03:16.209 The second thing that those tools created were client libraries. 00:03:16.309 --> 00:03:17.489 So these are the SDKs. 00:03:17.999 --> 00:03:21.969 It's nice to have a typed client that you get auto complete in 00:03:21.969 --> 00:03:23.649 your ID of whichever you're using. 00:03:23.649 --> 00:03:25.889 Typically, we see VS code as the most popular. 00:03:26.549 --> 00:03:31.129 But when I like hit, when I'm using the SDK, it'll show me all of the resources 00:03:31.129 --> 00:03:35.329 that are available and the operations that I can perform on those resources. 00:03:35.349 --> 00:03:38.089 And so that might be like payment create. 00:03:38.499 --> 00:03:40.499 And that's a really nice developer experience because 00:03:40.729 --> 00:03:41.739 they don't have to leave. 00:03:42.504 --> 00:03:46.654 Their IDE while they're coding to go check what the documentation says. 00:03:47.324 --> 00:03:51.414 It's part of the SDK and they, they've kind of got docs on hover 00:03:51.944 --> 00:03:55.734 where they can see details about each, each of those resources or 00:03:55.734 --> 00:03:58.054 operations, uh, how they behave. 00:03:59.054 --> 00:04:04.914 And the third thing, Mike, is in addition to some server code and SDKs, is that 00:04:04.914 --> 00:04:09.234 these tools, these conjure and SMITHY tools from the companies that I mentioned, 00:04:09.914 --> 00:04:11.794 produced a version of API documentation. 00:04:12.784 --> 00:04:16.444 In AWS's case, it was literally the A-W-S-A-P-I docs. 00:04:17.514 --> 00:04:21.034 I don't think it'll be a surprise to folks and Mike, tell me if I'm wrong, that 00:04:21.154 --> 00:04:25.514 AWS does not hand write all of their API documentation and their API reference. 00:04:25.989 --> 00:04:26.279 Mike Bifulco: Yeah. 00:04:26.639 --> 00:04:29.239 I think if you've browsed it once or twice, it's probably apparent that 00:04:29.239 --> 00:04:32.279 either someone from a different universe made some of them, or they're, they're 00:04:32.279 --> 00:04:33.479 not necessarily human generated. 00:04:33.479 --> 00:04:33.719 Yeah. 00:04:34.524 --> 00:04:38.504 Danny Sheridan: It was really inspiring to me, though, to see an example. 00:04:40.259 --> 00:04:43.459 a human is not responsible for updating the docs anytime that the 00:04:43.499 --> 00:04:50.409 API changes because at Amazon we had that concept of good intentions, which 00:04:50.409 --> 00:04:52.129 is that good intentions. 00:04:52.129 --> 00:04:55.009 Mike, when someone says, anytime we change the API, we will 00:04:55.329 --> 00:04:56.329 remember to update the docs. 00:04:56.959 --> 00:04:57.249 Good 00:04:57.879 --> 00:05:00.279 intentions fail because people are busy 00:05:00.519 --> 00:05:00.939 Mike Bifulco: That's 00:05:00.939 --> 00:05:02.719 Danny Sheridan: and instead Exactly. 00:05:02.819 --> 00:05:05.159 And instead, what we should be doing is having tooling. 00:05:05.879 --> 00:05:07.569 That supports us in accomplishing our goals. 00:05:07.669 --> 00:05:14.749 And so Fern is a way where companies with public rest APIs use Fern to 00:05:14.749 --> 00:05:21.149 offer SDKs in popular programming languages and API documentation 00:05:21.299 --> 00:05:23.429 that documents those rest APIs. 00:05:24.214 --> 00:05:26.544 Mike Bifulco: I think our listeners will identify with this quite a bit. 00:05:27.004 --> 00:05:28.204 I think we're in an interesting, like. 00:05:28.969 --> 00:05:32.559 Point in history, this sort of inflection point where maybe even between now 00:05:32.559 --> 00:05:35.539 and the last time you and I chatted I think something has happened sort 00:05:35.539 --> 00:05:39.579 of in like the, the general public mindset that people suddenly trust 00:05:40.019 --> 00:05:42.099 machines to do more intelligent things. 00:05:42.319 --> 00:05:47.039 And by that I mean like the, the zeitgeist of AI tools, AI wrappers for 00:05:47.199 --> 00:05:52.384 everything has made people a lot more lenient to let the the, the . Software, 00:05:52.394 --> 00:05:55.184 write things for them, create things for them, do creative work, do work. 00:05:55.184 --> 00:05:57.554 That was prior quite manual tasks. 00:05:57.654 --> 00:06:00.784 And I think Fern is happening at a really interesting time in that inflection 00:06:00.794 --> 00:06:05.654 where suddenly it's like, oh, actually maybe I can run my, my open API spec 00:06:05.654 --> 00:06:09.254 through something and it can generate client libraries and also maybe generate 00:06:09.254 --> 00:06:12.574 meaningful documentation where I think if you asked me that two years ago, 00:06:12.694 --> 00:06:13.934 I would've been like, not a chance. 00:06:14.379 --> 00:06:16.599 I'm gonna hire an army of technical writers and they're gonna do 00:06:16.599 --> 00:06:17.909 a great job for me on this. 00:06:19.199 --> 00:06:22.539 I'm curious to hear your sort of feelings on that and, and also your feelings 00:06:22.539 --> 00:06:25.659 on like the, the world of working with people who are generating code as 00:06:25.659 --> 00:06:27.019 opposed to writing code manually too. 00:06:28.742 --> 00:06:31.332 Danny Sheridan: let's talk about the biggest objections that I hear 00:06:31.722 --> 00:06:35.772 when I talk to customers or prospects specifically about Fern. 00:06:36.472 --> 00:06:41.692 One of the objections that is common is I don't trust a machine to generate my SDK. 00:06:43.242 --> 00:06:45.702 My developer experience is important to my business. 00:06:46.442 --> 00:06:51.942 It increases our revenue if we can acquire new customers, and I don't 00:06:51.942 --> 00:06:53.262 wanna trust that to something that. 00:06:54.127 --> 00:06:57.557 eVery time I run the code generator could have a different output. 00:06:57.807 --> 00:06:58.157 Right. 00:06:58.817 --> 00:07:03.717 And what I tell people is, Fern does not use LLMs to generate code. 00:07:04.637 --> 00:07:04.717 Mike Bifulco: Hmm. 00:07:05.197 --> 00:07:09.277 Danny Sheridan: We have bitten, we have built a rule-based system and 00:07:09.277 --> 00:07:11.757 if we're getting more specific, we built a compiler that takes 00:07:11.777 --> 00:07:17.957 in an open API spec and generates TypeScript or Python or Java files. 00:07:18.477 --> 00:07:18.767 Mike Bifulco: Yeah. 00:07:19.177 --> 00:07:21.157 Danny Sheridan: And so one of the important things to folks 00:07:21.157 --> 00:07:22.557 right now is determinism. 00:07:23.912 --> 00:07:29.512 I run the fern generator more than one time, will I get the same SDK output? 00:07:30.212 --> 00:07:35.332 If, if the SDK would change every time because of determinism, that, that 00:07:35.332 --> 00:07:37.772 would be a, a major blocker to adoption. 00:07:38.032 --> 00:07:41.602 And so right now, the most popular way is to generate SDKs are all, 00:07:42.812 --> 00:07:47.402 there is no L-L-M-S-D-K generation tooling that has become popular. 00:07:48.222 --> 00:07:49.722 Not to say it can't happen one day. 00:07:50.817 --> 00:07:54.577 I think folks want determinism and then they also wanna see why, 00:07:55.287 --> 00:07:59.817 like why did the code generator output a specific line of code? 00:07:59.877 --> 00:08:03.137 And they really like being able to poke into the open source source code. 00:08:03.477 --> 00:08:06.457 And so Fern is open source because our customers are developers and they 00:08:06.457 --> 00:08:08.457 like to see how the magic happens. 00:08:09.837 --> 00:08:11.367 Mike Bifulco: Yeah, that's an important point too. 00:08:11.367 --> 00:08:14.977 And I'll make sure we have notes on a link to fern's GitHub in our show 00:08:14.977 --> 00:08:18.227 notes so our listeners can go and kind of browse that and, you know, also 00:08:18.227 --> 00:08:19.957 contribute if if they're so inclined. 00:08:20.407 --> 00:08:21.737 Yeah, I think, I think that's. 00:08:22.987 --> 00:08:26.177 A valuable point to make that like deterministic LLMs are not a thing 00:08:26.317 --> 00:08:27.817 in, in the current state of the art. 00:08:28.047 --> 00:08:30.777 They may one day be, I don't know if that's even possible based on, 00:08:30.777 --> 00:08:34.377 you know, what an LLM technically is, but you want your generated 00:08:34.377 --> 00:08:38.377 libraries to be predictable and the same and by that nature also testable. 00:08:38.757 --> 00:08:41.777 And I feel like that's something that probably comes out of people using Fern is 00:08:41.777 --> 00:08:44.817 you can generate a library and if you can generate it the same every time, you can 00:08:44.817 --> 00:08:48.257 test it and be certain that what you're getting is something that at least passes 00:08:48.357 --> 00:08:49.817 the tests that, that you've provided. 00:08:50.877 --> 00:08:52.977 Danny Sheridan: aNd Mike, I'm thinking about one of our customers. 00:08:53.237 --> 00:08:54.937 The company is called Cohere. 00:08:55.567 --> 00:08:59.497 They're an AI platform for enterprises that is growing in popularity. 00:09:00.627 --> 00:09:05.957 They are LLM experts and they have chosen fern and do not wanna use LLMs 00:09:05.957 --> 00:09:10.237 to produce their SDKs because their main source of revenue is their API 00:09:10.657 --> 00:09:10.947 Mike Bifulco: Yeah, 00:09:11.197 --> 00:09:15.217 Danny Sheridan: and a problem in their SDK would literally impact 00:09:15.217 --> 00:09:16.697 their ability to generate income. 00:09:17.637 --> 00:09:21.457 And so they, they, they were almost willing to put an engineer 00:09:21.457 --> 00:09:24.257 against it when they saw that they could, instead of having to build. 00:09:25.472 --> 00:09:26.562 SDKs by hand. 00:09:27.072 --> 00:09:29.722 They could buy an SDK generation tool. 00:09:29.832 --> 00:09:30.122 They 00:09:30.132 --> 00:09:31.442 opted to buy and not build. 00:09:31.702 --> 00:09:32.482 And I think you're right. 00:09:32.542 --> 00:09:36.962 You mentioned things are changing around the API developer experience 00:09:36.962 --> 00:09:38.762 market, should we call it that 00:09:39.302 --> 00:09:41.422 the developer experience market um, things 00:09:41.422 --> 00:09:43.982 around SDKs, API documentation. 00:09:44.242 --> 00:09:48.342 We are seeing a shift where in the past companies would've said, and we've 00:09:48.342 --> 00:09:50.102 been working on FERN for 18 months now. 00:09:51.022 --> 00:09:52.942 18 months ago, my folks would've said. 00:09:54.427 --> 00:09:58.247 We, the only option to provide great SDKs is to put an engineer against it. 00:09:58.657 --> 00:09:59.707 Mike Bifulco: Yeah, definitely. 00:09:59.837 --> 00:10:00.507 Definitely. 00:10:00.587 --> 00:10:01.187 Danny Sheridan: do this by hand. 00:10:01.187 --> 00:10:03.987 This is a, a ticket in our engineering queue. 00:10:04.487 --> 00:10:08.387 And I think that there's been a shift in the last 18 months where more 00:10:08.707 --> 00:10:12.747 engineering leaders, this typically is happening at the CTO or an engineering 00:10:12.817 --> 00:10:18.667 manager, platform engineer who says there are now tools like Fern where I 00:10:18.667 --> 00:10:21.227 can pass in an open API specification. 00:10:22.267 --> 00:10:27.147 I can get out high quality idiomatic SDKs that I'm comfortable 00:10:27.147 --> 00:10:28.427 putting in front of my customers. 00:10:29.082 --> 00:10:29.372 Mike Bifulco: Sure. 00:10:29.562 --> 00:10:29.852 Yeah. 00:10:29.972 --> 00:10:32.792 I think also worth pointing out that even the discussion you and I had 00:10:32.892 --> 00:10:36.782 six months ago has changed pretty dramatically in as much as back then 00:10:36.782 --> 00:10:39.382 at least, I don't think we talked too much about documentation either. 00:10:39.802 --> 00:10:42.942 But I feel like that's maybe part of like the, the holistic picture 00:10:43.002 --> 00:10:46.442 of providing great developer experience to people consuming your 00:10:46.442 --> 00:10:49.362 client libraries, whether they're internal or external to your company. 00:10:49.902 --> 00:10:52.587 GEtting both a functioning client library and then the documentation 00:10:52.587 --> 00:10:54.267 to build it is the story. 00:10:54.267 --> 00:10:55.147 That's, that's the story. 00:10:55.167 --> 00:10:57.587 You need to have both of those things for your thing to be valuable. 00:10:57.917 --> 00:11:00.097 And, and I think there's probably like, I don't know. 00:11:00.097 --> 00:11:03.077 I would imagine you've probably seen patterns in your customers that they're 00:11:03.157 --> 00:11:06.077 probably all looking for like a platonic ideal that they want to have, you 00:11:06.077 --> 00:11:09.337 know, great developer experience and great documentation to go with it. 00:11:09.367 --> 00:11:14.377 What, what does that like lifecycle look like for maybe finding, acquiring and, and 00:11:14.377 --> 00:11:15.947 delivering solutions to your customers? 00:11:17.117 --> 00:11:20.647 Danny Sheridan: Mike, you said kind of who is the gold standard, who is the ideal 00:11:21.177 --> 00:11:25.607 right now for developer experience, and I think that over the last at least 00:11:25.607 --> 00:11:27.327 three years, the answer has not changed. 00:11:28.327 --> 00:11:32.347 The company with the best developer experience in the world is Stripe. 00:11:33.502 --> 00:11:34.272 Mike Bifulco: yeah, sure. 00:11:34.662 --> 00:11:34.952 sure. 00:11:35.037 --> 00:11:35.157 Danny Sheridan: think 00:11:35.157 --> 00:11:39.797 that folks would find that agreeable, but Mike disagree on the why. 00:11:40.607 --> 00:11:41.337 Mike, you have to 00:11:41.337 --> 00:11:42.177 reason through it together. 00:11:43.257 --> 00:11:43.807 Mike Bifulco: Let's do it. 00:11:43.827 --> 00:11:46.167 And before we get into that, this is probably where I should mention. 00:11:46.307 --> 00:11:47.447 I'm a former Stripe employee. 00:11:47.867 --> 00:11:51.687 No bad blood between me and Stripe, or me and Danny as far as I know, at least but 00:11:51.687 --> 00:11:53.577 you know, a reasonable call out here too. 00:11:53.577 --> 00:11:53.857 Yeah. 00:11:53.857 --> 00:11:54.617 Let's reason through it. 00:11:54.647 --> 00:11:55.337 Walk me through it. 00:11:56.942 --> 00:12:00.972 Danny Sheridan: Let's talk about this as if we're making a, a 00:12:00.972 --> 00:12:04.492 recipe and the outcome is the Stripe developer experience. 00:12:04.652 --> 00:12:06.492 I think the question, Mike, is what are the inputs. 00:12:06.907 --> 00:12:07.197 Mike Bifulco: Cool. 00:12:07.307 --> 00:12:07.597 Yeah. 00:12:08.412 --> 00:12:11.232 Danny Sheridan: And I usually like to speak in threes, but in this case, I've 00:12:11.232 --> 00:12:15.952 got five things on my mind that make the Stripe developer experience exceptional. 00:12:16.607 --> 00:12:17.292 Mike Bifulco: Yeah, hit me. 00:12:18.162 --> 00:12:23.052 Danny Sheridan: The first is consistent design, whichever endpoints you're using 00:12:23.072 --> 00:12:30.702 within Stripe's, vast API, you can expect similar behavior and patterns, like you'll 00:12:30.702 --> 00:12:34.822 learn it once and you learned it across the whole API and any endpoint you use. 00:12:35.732 --> 00:12:36.022 Mike Bifulco: Yeah. 00:12:36.592 --> 00:12:38.932 Danny Sheridan: To do, especially as a company grows over. 00:12:39.972 --> 00:12:41.812 I mean, Mike, they're well over a decade old, right? 00:12:42.392 --> 00:12:42.682 Mike Bifulco: Sure. 00:12:42.682 --> 00:12:43.722 Yeah, absolutely. 00:12:43.952 --> 00:12:45.362 Yeah, pat patterns are huge. 00:12:45.502 --> 00:12:48.802 And you know, much like you'd imagine in some places there are teams of 00:12:48.802 --> 00:12:50.522 developers maintaining client libraries. 00:12:50.862 --> 00:12:54.582 And at AWS there are teams of people starting with that API spec. 00:12:54.962 --> 00:12:57.742 The discussion on consistency is massive at Stripe. 00:12:57.742 --> 00:13:00.982 Making sure that things make sense from one to the other so that end users 00:13:01.082 --> 00:13:04.542 can learn one pattern and apply it everywhere is super, super valuable. 00:13:06.612 --> 00:13:08.352 Danny Sheridan: The second is documentation. 00:13:09.502 --> 00:13:14.842 Developers expect that they, it's easy to find what they're looking for and 00:13:14.842 --> 00:13:16.682 that the information is up to date. 00:13:17.262 --> 00:13:21.392 It's very frustrating when you go and check out what the JSON looks like 00:13:21.572 --> 00:13:23.312 for an API response, and it's wrong 00:13:23.662 --> 00:13:27.272 because some developer changed it and forgot to update the docs. 00:13:27.732 --> 00:13:29.952 And so Stripe has done a phenomenal job of. 00:13:30.672 --> 00:13:35.142 Automating their documentation and they have a whole team responsible for it. 00:13:35.607 --> 00:13:35.897 Mike Bifulco: Yeah. 00:13:36.127 --> 00:13:36.937 Yeah, definitely. 00:13:37.037 --> 00:13:40.457 If you are reasonably good at Googling, you can find a, a talk I 00:13:40.457 --> 00:13:43.257 did on Stripe's internal documentation tools on YouTube somewhere. 00:13:45.102 --> 00:13:49.942 Danny Sheridan: The third thing are SDKs in popular languages, whether 00:13:50.002 --> 00:13:55.422 you are a Java, a Python, or a Ruby developer, you get a client 00:13:55.422 --> 00:13:57.782 library that's got auto complete. 00:14:00.137 --> 00:14:03.532 Immediately, and you get that when you're starting your project. 00:14:05.092 --> 00:14:10.062 SDKs tend to make integrations happen in 50% less time, and Stripe 00:14:10.062 --> 00:14:14.262 understands that by my last count, they supported seven different languages or 00:14:14.262 --> 00:14:15.982 frameworks that they provide SDKs for. 00:14:17.172 --> 00:14:18.182 Mike Bifulco: Yeah, that sounds about right. 00:14:18.212 --> 00:14:18.502 Yeah. 00:14:19.432 --> 00:14:22.812 And then to, to that point too, idiomatic SDKs are important, right? 00:14:22.812 --> 00:14:26.232 Like, it feels like python, it feels like ruby, when you're 00:14:26.232 --> 00:14:27.032 writing in that language. 00:14:27.032 --> 00:14:29.562 And that's, that's a hard thing to to accomplish just as well. 00:14:31.522 --> 00:14:31.782 Danny Sheridan: All right. 00:14:31.802 --> 00:14:35.422 The fourth thing of five errors. 00:14:36.182 --> 00:14:41.272 When you run into an error in the stripe, API, the message that's output 00:14:41.272 --> 00:14:43.592 to the developer, it's actually helpful. 00:14:44.902 --> 00:14:48.282 It typically links you to a place in their documentation. 00:14:48.502 --> 00:14:50.162 So it's like documentation aware. 00:14:50.172 --> 00:14:54.722 It'll give you AURL where you can go to read more and it might even recommend 00:14:54.842 --> 00:14:57.002 a fix as part of the error message. 00:14:57.862 --> 00:15:04.192 And that's just, um, Mike, it might be craft, that's the word on my mind. 00:15:04.317 --> 00:15:05.207 Mike Bifulco: Yeah, sure. 00:15:05.717 --> 00:15:06.007 sure. 00:15:06.207 --> 00:15:06.567 I think so. 00:15:06.667 --> 00:15:08.407 And, and that was a revelation too, right? 00:15:08.407 --> 00:15:09.687 Like this was not a common thing. 00:15:10.727 --> 00:15:14.197 In a world before stripes developer SDKs existed, like 00:15:14.407 --> 00:15:16.977 oftentimes as a API consumer. 00:15:17.247 --> 00:15:22.177 Your job was to set debuggers run console logs and pull your hair out until 00:15:22.177 --> 00:15:25.137 you figured out what, what comma was missing or what type you had incorrect, 00:15:25.157 --> 00:15:27.097 or you know, what you had done wrong. 00:15:27.307 --> 00:15:29.567 And at best you maybe got a 500 back. 00:15:29.567 --> 00:15:30.207 Something like that. 00:15:30.237 --> 00:15:30.527 Yeah. 00:15:32.402 --> 00:15:35.342 Danny Sheridan: And the fifth thing, Mike, that's on my mind is around versioning. 00:15:36.692 --> 00:15:40.942 When you start, when you open your Stripe account, your pin to a version of the API, 00:15:41.682 --> 00:15:47.362 and from that day on you are, they expect that you'll be using that API version, 00:15:47.422 --> 00:15:49.042 and you have to choose to take an upgrade. 00:15:49.582 --> 00:15:53.242 And so Stripe does a phenomenal job of having backwards compatibility. 00:15:53.672 --> 00:15:57.482 They've actually built tooling that they call gating that we can talk more about 00:15:57.662 --> 00:15:59.722 in another episode if you'd like to in. 00:16:00.482 --> 00:16:00.772 Mike Bifulco: Sure. 00:16:01.887 --> 00:16:04.377 Danny Sheridan: They've, to date, they've never broken their API. 00:16:04.557 --> 00:16:09.177 And I think that's a really expensive decision because it, you learn a lot 00:16:09.177 --> 00:16:10.817 after 10 plus years of doing business. 00:16:11.237 --> 00:16:13.697 And I'm sure there are moments that they would've loved to break the 00:16:13.777 --> 00:16:16.017 API, but to date they have not. 00:16:16.767 --> 00:16:17.617 Mike Bifulco: Yeah, yeah. 00:16:18.277 --> 00:16:21.727 The, those, so let me let me see if I can kind of sum that up then. 00:16:21.747 --> 00:16:26.457 So, versioning error messaging, client, libraries, docs and 00:16:26.757 --> 00:16:27.937 the fifth one is escaping me. 00:16:28.017 --> 00:16:28.657 A design right. 00:16:28.657 --> 00:16:32.567 Consistency are are definitely adding up for that the magic. 00:16:32.647 --> 00:16:35.047 That's, that's the experience I want my engineering team to have. 00:16:35.047 --> 00:16:37.807 That's also the experience I want from every client library I consume 00:16:37.807 --> 00:16:39.207 from a third party service as well. 00:16:40.127 --> 00:16:42.177 Danny Sheridan: Yeah, but Mike, how many employees does Stripe have? 00:16:43.497 --> 00:16:43.777 Mike Bifulco: Engineers. 00:16:43.777 --> 00:16:44.577 We have four right now. 00:16:45.167 --> 00:16:45.407 Danny Sheridan: Sorry. 00:16:45.407 --> 00:16:45.967 At Stripe. 00:16:46.307 --> 00:16:46.967 Mike Bifulco: Oh, it's Stripe. 00:16:46.967 --> 00:16:47.367 Oh, sorry. 00:16:47.367 --> 00:16:47.887 Yeah, yeah, yeah. 00:16:47.887 --> 00:16:48.287 Stripe. 00:16:48.517 --> 00:16:52.247 Gosh, rounding out a few thousand easily, I think probably close to five or 6,000. 00:16:52.477 --> 00:16:52.767 Danny Sheridan: Yeah. 00:16:52.787 --> 00:16:53.007 So 00:16:53.007 --> 00:16:54.887 let's compare craft work to stripe's 00:16:55.367 --> 00:16:58.127 engineering ability, maybe I'll call it four to a thousand, 00:16:58.127 --> 00:16:59.487 something like that ratio. 00:17:00.067 --> 00:17:00.597 It's really, 00:17:01.387 --> 00:17:06.697 it's not feasible for companies to hire engineers to go build this 00:17:06.807 --> 00:17:09.377 developer experience infrastructure. 00:17:10.227 --> 00:17:10.847 For their company. 00:17:11.307 --> 00:17:15.247 And so that is why the market is turning to buy a solution 00:17:16.067 --> 00:17:17.927 that's available for you. 00:17:18.427 --> 00:17:20.487 And Fern is filling that place in the market. 00:17:20.707 --> 00:17:24.887 And so the, the idea of Fern is that we will bring a stripe like 00:17:24.887 --> 00:17:26.727 developer experience to your API. 00:17:27.507 --> 00:17:28.567 We will do that over. 00:17:28.567 --> 00:17:30.647 That's, that's the vision that we are working toward. 00:17:30.827 --> 00:17:34.807 And today we will deliver two things for our customers SDKs in multiple 00:17:35.047 --> 00:17:36.087 languages that are idiomatic. 00:17:37.117 --> 00:17:41.937 We take care of publishing them to NPM and Maven Central and So we take care of 00:17:41.937 --> 00:17:45.057 getting 'em to the package managers and publishing the source code to GitHub. 00:17:45.637 --> 00:17:48.337 And the second product that we offer is API documentation. 00:17:49.217 --> 00:17:51.777 Everyone wants the Stripe like Docs website that fits 00:17:51.777 --> 00:17:52.897 your, it matches your brand. 00:17:52.897 --> 00:17:54.697 You've got the infinite scrolling page. 00:17:55.877 --> 00:17:59.297 You can see the SDKs documented in the API reference. 00:17:59.357 --> 00:18:00.937 That's a really nice feature, Mike. 00:18:01.557 --> 00:18:04.097 And Stripe does in a way where it's auto-populated. 00:18:04.782 --> 00:18:08.882 So human does not have to go and update the code snippets in all seven 00:18:09.202 --> 00:18:10.842 SDK languages for every endpoint. 00:18:11.082 --> 00:18:11.922 Whenever the API changes, 00:18:12.272 --> 00:18:13.602 they have automation for that. 00:18:13.942 --> 00:18:17.042 And that's something that Fern has now rolled out for our customers is 00:18:17.042 --> 00:18:22.152 you can get what we call code snippets for every endpoint showing how to 00:18:22.152 --> 00:18:26.112 use your SDK in any of the languages that you generated for an SDK for. 00:18:26.787 --> 00:18:27.077 Mike Bifulco: Yeah. 00:18:27.297 --> 00:18:28.877 That's, that's incredible. 00:18:28.877 --> 00:18:31.677 That's, that's quite an offering and, and a bold statement to make. 00:18:32.057 --> 00:18:34.277 And I think what I wanna know from you is like, what, what are 00:18:34.277 --> 00:18:35.717 your consumers need to provide? 00:18:35.777 --> 00:18:36.997 How do they, how do they get that? 00:18:37.787 --> 00:18:38.207 What's 00:18:38.217 --> 00:18:40.867 Danny Sheridan: They provide, they provide an open API spec. 00:18:41.387 --> 00:18:41.467 Mike Bifulco: Hmm. 00:18:41.827 --> 00:18:41.947 I. 00:18:42.597 --> 00:18:46.097 Danny Sheridan: We generate SDKs and we generate the API docs. 00:18:46.857 --> 00:18:50.777 Additionally, if they want to, they can provide markdown files, which will be the 00:18:50.777 --> 00:18:53.777 pages in their documentation if they'd like to do things like how to get started. 00:18:54.647 --> 00:18:56.267 How to authenticate with our API. 00:18:56.717 --> 00:18:58.107 Maybe they have item potency. 00:18:58.107 --> 00:19:00.827 Those are some of the examples that we tend to see how pagination works. 00:19:01.487 --> 00:19:05.267 So they can add custom pages in addition to their API reference. 00:19:06.087 --> 00:19:14.007 And in my mind, Mike SDKs and API docs are like peanut butter and jelly. 00:19:15.732 --> 00:19:17.622 They just go better when they're together. 00:19:17.802 --> 00:19:20.062 You can have 'em separately, but 00:19:20.452 --> 00:19:25.502 it's really nice when your SDKs, yeah, when the SDKs are documented next to the 00:19:25.542 --> 00:19:30.422 API reference, it feels most natural as a developer that wants to go figure out, how 00:19:30.422 --> 00:19:32.022 do I integrate with this company's API. 00:19:32.832 --> 00:19:33.122 Mike Bifulco: Sure. 00:19:33.192 --> 00:19:33.482 Yeah. 00:19:33.822 --> 00:19:35.982 So are you able to share any stories about customers that 00:19:35.982 --> 00:19:37.342 you've had who are using Fern? 00:19:39.092 --> 00:19:39.372 Danny Sheridan: Absolutely. 00:19:39.782 --> 00:19:43.402 How about we talk about, I mentioned cohere already, so I'll pick another one. 00:19:43.942 --> 00:19:46.562 hOw about merge Dev to 00:19:46.562 --> 00:19:47.122 give a little? 00:19:47.742 --> 00:19:48.602 Are you familiar with that, 00:19:48.602 --> 00:19:48.842 Mike? 00:19:49.207 --> 00:19:50.877 Mike Bifulco: Past guests of APIs you and hate. 00:19:50.877 --> 00:19:54.277 We have, we recorded an episode with them maybe a year and a half ago at this point. 00:19:54.872 --> 00:19:58.712 Danny Sheridan: Oh, was that my hunch was probably either Shei or Gale, the CTO. 00:19:59.047 --> 00:19:59.587 Mike Bifulco: It was Gil. 00:19:59.587 --> 00:19:59.827 Yeah. 00:19:59.827 --> 00:20:01.747 We chatted with Gil on, on APIs, you and hate. 00:20:01.777 --> 00:20:02.067 Yeah. 00:20:02.602 --> 00:20:03.212 Danny Sheridan: Fantastic. 00:20:03.567 --> 00:20:04.747 Mike Bifulco: In case someone hasn't listened though, 00:20:04.747 --> 00:20:06.107 what's the 1, 1 0 1 on merge? 00:20:06.107 --> 00:20:06.467 What do they do? 00:20:06.947 --> 00:20:07.067 I. 00:20:07.477 --> 00:20:09.807 Danny Sheridan: Yeah, merge is a fast growing company that 00:20:09.807 --> 00:20:14.287 developed a unified API that simplifies integration development. 00:20:14.787 --> 00:20:18.487 So there are a lot of popular SaaS products out there that you 00:20:18.487 --> 00:20:19.447 might want to integrate with. 00:20:20.107 --> 00:20:21.087 And I'll just give an example. 00:20:21.107 --> 00:20:27.327 If I wanna add ACRM integration to my app, I might want to connect with Salesforce 00:20:27.357 --> 00:20:30.167 data, or HubSpot data, or Pipedrive data. 00:20:31.132 --> 00:20:34.712 And so for me to go build integrations with each of those three is pretty 00:20:34.712 --> 00:20:36.272 burdensome on my engineering team. 00:20:36.692 --> 00:20:38.392 And instead I can go use Merge. 00:20:38.492 --> 00:20:43.272 And so Merge is the, is a unified API platform and is the difference between 00:20:43.552 --> 00:20:48.112 building one integration with Just Merge or building 10 with multiple different 00:20:48.182 --> 00:20:50.192 SaaS tools that have changing APIs. 00:20:50.952 --> 00:20:53.682 Mike Bifulco: Yeah, from, from what I remember, talking to GI Merge, they 00:20:53.682 --> 00:20:58.322 have a astonishing number of third parties that they unify into one 00:20:58.322 --> 00:21:01.992 place to call, at, at the time when we chatted, it was like dozens upon dozens, 00:21:01.992 --> 00:21:03.152 and I'm sure it's grown since then. 00:21:03.522 --> 00:21:04.732 It's, it's definitely a big product. 00:21:05.256 --> 00:21:08.396 Danny Sheridan: WE can talk about the, the problem that merge came to us with, 00:21:10.886 --> 00:21:16.166 a merge customer uses the merge SDK and not a Salesforce or a HubSpot, SDK, 00:21:17.031 --> 00:21:17.381 Mike Bifulco: Right. 00:21:17.506 --> 00:21:19.156 Danny Sheridan: instead of having to deal with those 00:21:19.236 --> 00:21:19.476 Mike Bifulco: place. 00:21:20.096 --> 00:21:20.586 Danny Sheridan: Exactly. 00:21:20.681 --> 00:21:21.821 You call 'em all from one place. 00:21:22.291 --> 00:21:25.901 Well, that means that merge needs, I'm gonna call it a kick ass SDK. 00:21:26.731 --> 00:21:31.181 They need to have an extremely developer friendly, well document consistent 00:21:31.281 --> 00:21:33.061 across all languages experience. 00:21:33.641 --> 00:21:35.381 But they are API experts. 00:21:35.381 --> 00:21:39.741 They're not necessarily SDK experts, and so they teamed up with the firm 00:21:39.741 --> 00:21:41.461 team and they move really quickly. 00:21:41.791 --> 00:21:45.701 Merge is a fast moving company from first initial call with us to learn about 00:21:45.701 --> 00:21:47.581 what we do to actually going live with. 00:21:49.476 --> 00:21:52.736 Was a four week time period, so really impressive at the speed 00:21:52.736 --> 00:21:53.736 that they've been able to move. 00:21:54.406 --> 00:21:54.696 Mike Bifulco: Yeah, 00:21:54.836 --> 00:21:55.256 my God. 00:21:56.266 --> 00:22:00.886 Danny Sheridan: at this point they've now released a node, Python, Java, go, 00:22:01.526 --> 00:22:06.406 SDK, using Fern, and we're together collaborating on C Sharp and Ruby as 00:22:06.406 --> 00:22:07.686 the next languages that'll come out. 00:22:08.276 --> 00:22:11.766 It's pretty nice when you have a customer who pushes you to increase selection. 00:22:12.696 --> 00:22:13.416 Mike Bifulco: Yeah, definitely. 00:22:13.416 --> 00:22:13.696 Right. 00:22:13.796 --> 00:22:17.046 So, so with that then, it sounds like you've probably expanded the 00:22:17.166 --> 00:22:19.726 languages that Fern has delivered on since March as well, right? 00:22:20.586 --> 00:22:20.886 Danny Sheridan: We have 00:22:20.936 --> 00:22:24.496 since we last talked, we've added Python and go and we 00:22:24.496 --> 00:22:25.856 will continue adding languages. 00:22:25.916 --> 00:22:29.416 It feels like after the top eight to 10 programming languages, 00:22:29.416 --> 00:22:30.656 there's a pretty big drop off. 00:22:31.606 --> 00:22:32.166 Mike Bifulco: That's probably fair. 00:22:32.236 --> 00:22:32.526 Yeah. 00:22:32.981 --> 00:22:35.561 Danny Sheridan: but I could see us using a good chunk of 2024 to 00:22:35.561 --> 00:22:36.761 get there to that top eight or 10. 00:22:37.496 --> 00:22:37.786 Mike Bifulco: Cool. 00:22:39.491 --> 00:22:43.651 . Okay, so, so Merge is a a fern user and they've, they've then delivered 00:22:43.651 --> 00:22:45.291 their SDKs in, in four weeks. 00:22:45.351 --> 00:22:48.221 Is is honestly a staggering turnaround for something like that. 00:22:48.291 --> 00:22:52.411 Like if you're listening to the show, you should hop over to merge.dev and like 00:22:52.411 --> 00:22:54.091 browse, scroll to the bottom of the page. 00:22:54.111 --> 00:22:57.011 The footer of their page shows how many APIs they integrate with. 00:22:57.471 --> 00:23:01.586 And it is . Like conservatively a hundred different, different APIs 00:23:01.586 --> 00:23:04.456 they pull into merge, which must mean that Fern is generating like 00:23:04.776 --> 00:23:07.876 mountains of API client library and documentation for them as well. 00:23:08.491 --> 00:23:10.781 Danny Sheridan: Yeah, we generate hundreds of endpoints for them every 00:23:10.781 --> 00:23:12.141 time that they generate code with us. 00:23:12.921 --> 00:23:17.301 And one of the things that I want to call out is at, I was at AWS before 00:23:17.301 --> 00:23:23.071 this, as I mentioned, at AWS Andy Jassy used to talk to the team that 00:23:23.171 --> 00:23:28.471 the most successful implementations of AWS happened when it was top down. 00:23:29.271 --> 00:23:32.321 It's just too hard for cloud infrastructure to go bottom up. 00:23:33.061 --> 00:23:39.961 You need a C-level goal, such as the CTO or CIO setting a goal that 00:23:39.961 --> 00:23:45.081 gets everyone on the same North Star of like getting to the cloud. 00:23:45.741 --> 00:23:48.721 And in this case, we see the same trend happening with SDKs. 00:23:48.911 --> 00:23:50.481 It's really hard to go bottoms up. 00:23:50.951 --> 00:23:54.921 It's really easy when a leader like Gil from Merge says, Hey, everyone. 00:23:55.621 --> 00:23:59.521 We are using Fern, we're going all in on offering every SDK language. 00:23:59.521 --> 00:24:03.241 They, they provide and puts an engineer. 00:24:03.681 --> 00:24:05.561 Actually in our case, there was an engineer and an engineering 00:24:05.561 --> 00:24:09.801 manager that we got to work with to go live with each of their SDKs. 00:24:09.861 --> 00:24:13.921 And I think that's just the right approach as a leader to identify like 00:24:13.961 --> 00:24:17.521 a single threaded leader who's gonna be responsible for this SDK project 00:24:17.731 --> 00:24:19.801 going from first meeting to completion. 00:24:20.646 --> 00:24:22.956 Mike Bifulco: Yeah, that's the right rights kind of investment and 00:24:22.956 --> 00:24:26.276 clearly shows you know, a pattern for success too, and that it worked and, 00:24:26.296 --> 00:24:28.126 and that merges now user of Fern. 00:24:28.736 --> 00:24:29.776 That's, that's really exciting. 00:24:29.916 --> 00:24:33.376 So you, you now have a client library product and a Docs product. 00:24:34.126 --> 00:24:34.246 I. 00:24:34.656 --> 00:24:36.436 For people listening to the show. 00:24:36.646 --> 00:24:39.386 We also mentioned before that you to, to get started with 00:24:39.386 --> 00:24:40.866 Fern, you need an open API spec. 00:24:41.286 --> 00:24:42.576 What does it look like to get started? 00:24:42.596 --> 00:24:43.376 How long does that take? 00:24:44.611 --> 00:24:47.621 Danny Sheridan: Yeah it, you install an NPM package, which is 00:24:47.621 --> 00:24:49.901 the Fern CLI command line interface. 00:24:51.021 --> 00:24:54.661 then you run a command called Fern Generate and that takes your open 00:24:54.781 --> 00:24:58.221 API spec and starts generating a list of generators that you specify. 00:24:59.121 --> 00:25:02.691 So it takes about five minutes to get started. 00:25:03.501 --> 00:25:07.781 Pretty often what our customers figure out is that their open API 00:25:07.811 --> 00:25:09.661 spec is of pretty poor quality. 00:25:11.246 --> 00:25:11.366 I 00:25:11.366 --> 00:25:14.846 mean that this is like a trend that you've talked about on this show a lot 00:25:15.226 --> 00:25:19.446 and that you've written about of their, having an open API spec is 00:25:19.446 --> 00:25:23.246 not the same as having a high quality open API spec for your organization. 00:25:23.906 --> 00:25:24.206 Mike Bifulco: For sure. 00:25:24.396 --> 00:25:26.006 Yeah, it's aspirational. 00:25:26.136 --> 00:25:28.926 Definitely intentional, you know, a lot of, a lot of companies want to 00:25:28.926 --> 00:25:30.126 do it, and in practice it's tricky. 00:25:30.356 --> 00:25:33.046 It's a bit like starting with test driven development, like it's, it 00:25:33.046 --> 00:25:35.286 sounds like a great idea, but it's hard to get people to commit to it. 00:25:36.046 --> 00:25:37.656 Danny Sheridan: I'll give two examples of where I think open 00:25:37.776 --> 00:25:40.856 API specs that I've seen fall short just to, to make it tangible 00:25:40.956 --> 00:25:41.376 for folks. 00:25:42.076 --> 00:25:46.256 The first is that they mention a bunch of different properties of 00:25:46.256 --> 00:25:51.816 an object and they don't add a description of what that property is. 00:25:52.626 --> 00:25:56.446 And I don't know your API as well as, you know, your API, and so I need some help. 00:25:56.606 --> 00:25:58.086 I need a human readable description. 00:25:59.581 --> 00:26:02.081 Age means like is age in days and months and years. 00:26:02.151 --> 00:26:02.761 It's really helpful. 00:26:02.901 --> 00:26:05.881 You know, an integer for age isn't very clear to me as a developer 00:26:05.881 --> 00:26:07.201 what I should be put using there. 00:26:07.621 --> 00:26:11.121 And so one of the things that we see as a room for improvement is adding description 00:26:11.121 --> 00:26:13.161 fields across the entire API spec. 00:26:14.101 --> 00:26:16.761 The second area of improvement are adding examples. 00:26:18.181 --> 00:26:21.701 really helpful as a developer to see an example JS om response, 00:26:23.286 --> 00:26:23.576 Mike Bifulco: Yeah. 00:26:24.771 --> 00:26:26.261 Danny Sheridan: like very high value. 00:26:26.521 --> 00:26:27.301 But in order for. 00:26:28.331 --> 00:26:30.711 Fe to know what a response looks like. 00:26:31.611 --> 00:26:37.311 We need companies in their open, API specs to include an example for each endpoint 00:26:38.221 --> 00:26:41.841 and the great, the great customers that we work with that really want the 00:26:41.841 --> 00:26:45.281 exceptional developer experience make that part of their, like their, they 00:26:45.281 --> 00:26:52.131 can't ship update API without improving, without updating their open API spec. 00:26:52.151 --> 00:26:55.571 And then improving things like description fields and examples. 00:26:56.226 --> 00:26:58.276 Mike Bifulco: Yeah, I'd imagine that's a bit of a cathartic experience 00:26:58.276 --> 00:27:01.276 too, because it's effectively like forcing people to invest in 00:27:01.276 --> 00:27:02.916 their own reduction of tech debt. 00:27:03.376 --> 00:27:06.236 You know, we, we all have this notion that we want to do a great job of 00:27:06.236 --> 00:27:09.686 these things, but frankly, like human readable descriptions that make sense 00:27:09.986 --> 00:27:12.806 and examples and things like that fall by the wayside pretty quickly when 00:27:12.806 --> 00:27:14.086 you're under the gun to get things done. 00:27:14.826 --> 00:27:17.006 But that'll turn around if the tooling takes. 00:27:17.006 --> 00:27:17.806 Those things end. 00:27:18.451 --> 00:27:19.771 Multiplies the value of it for you. 00:27:19.771 --> 00:27:20.091 Right. 00:27:20.151 --> 00:27:23.281 And, and I think that's what Fern at least, is purporting to do here, and I 00:27:23.281 --> 00:27:24.441 think that's a really exciting offering. 00:27:25.046 --> 00:27:27.976 Danny Sheridan: Mike, do you see a world where LLMs could be helpful here, where 00:27:27.976 --> 00:27:30.856 it's like, help me add some descriptions and help me add some examples. 00:27:31.506 --> 00:27:31.796 Mike Bifulco: Sure. 00:27:31.906 --> 00:27:33.556 Yeah, yeah, yeah. 00:27:33.556 --> 00:27:36.236 That, that's definitely a place where I think people would be excited 00:27:36.296 --> 00:27:40.036 to you know, to to, to add that sort of ai magic on top of things. 00:27:40.036 --> 00:27:42.506 And maybe an, an interesting application of that too. 00:27:42.946 --> 00:27:45.186 I could see maybe even something where you're, you're chatting with your 00:27:45.186 --> 00:27:46.706 code base, like, Hey, how would I. 00:27:47.651 --> 00:27:50.751 Do whatever it is, like take an ACH payment from someone in Japan. 00:27:50.921 --> 00:27:51.271 Right? 00:27:51.271 --> 00:27:52.391 Like, how do, how do I do that? 00:27:52.391 --> 00:27:53.231 What does that look like? 00:27:53.331 --> 00:27:57.341 And, and if your documentation is in order and your open API spec is well written, 00:27:57.391 --> 00:28:00.191 I think that's something that, that is not too far off in the future for us. 00:28:00.951 --> 00:28:04.291 Danny Sheridan: You just touched on something that I think is just probably 00:28:04.291 --> 00:28:06.411 a billion dollar idea, so let's explore 00:28:06.411 --> 00:28:07.211 it for a minute together. 00:28:07.401 --> 00:28:07.691 Mike Bifulco: yeah. 00:28:07.871 --> 00:28:08.411 Far away. 00:28:09.941 --> 00:28:13.491 Danny Sheridan: Today API documentation is like an encyclopedia. 00:28:13.771 --> 00:28:14.061 Mike Bifulco: Yeah. 00:28:14.731 --> 00:28:17.421 Danny Sheridan: It's got a bunch of informations and, and a bunch of pages, 00:28:18.121 --> 00:28:21.501 and it's your responsibility to go either look at the table of contents 00:28:21.501 --> 00:28:25.821 or look at the glossary, kinda like the search bar, and you have to go find 00:28:25.971 --> 00:28:29.501 what you're looking for, get to the right section, read it, and digest it. 00:28:30.861 --> 00:28:31.151 Mike Bifulco: Yeah. 00:28:31.541 --> 00:28:36.771 Danny Sheridan: I speculate that instead of an encyclopedia experience where you 00:28:36.771 --> 00:28:38.211 have to like go find the right page. 00:28:38.871 --> 00:28:41.076 You're gonna be able to ask a question to the encyclopedia. 00:28:41.476 --> 00:28:44.236 I mean, this is what SIR and Alexa wanted to be back then, right? 00:28:44.756 --> 00:28:47.076 I can just ask a question and it goes and finds the 00:28:47.076 --> 00:28:48.316 information and presents it to me. 00:28:49.016 --> 00:28:52.276 And I could see a future where you get to someone's API docs 00:28:52.456 --> 00:28:53.596 and there's a text input. 00:28:54.236 --> 00:28:58.976 And that text input allows you to ask a question like, I'm using Jango to 00:28:58.976 --> 00:29:01.296 call the Stripe API as an example. 00:29:01.366 --> 00:29:05.736 Well, let's pick the merge dev API I'm using to call your API. 00:29:06.781 --> 00:29:13.711 I wanna migrate, I wanna use the HubSpot and Salesforce integration to go create 00:29:13.731 --> 00:29:20.101 new leads and it starts writing code for you, basically a sample app of how you 00:29:20.101 --> 00:29:22.821 would, and you get to share that, right? 00:29:22.821 --> 00:29:25.021 It's gonna use the Python, SDK 'cause it's, it knows 00:29:25.021 --> 00:29:26.181 you're in a Python framework 00:29:26.881 --> 00:29:30.301 and it's going to live, generate you code that you can start using that 00:29:30.301 --> 00:29:31.581 you would never find in their docs. 00:29:32.411 --> 00:29:36.061 It's actually combining some of the word description guides with 00:29:36.061 --> 00:29:41.261 the API reference with the SDKs that now like an LLM Power Docs 00:29:41.331 --> 00:29:43.821 understands all of those things to me. 00:29:43.821 --> 00:29:47.581 The day that we can go and, and like you said, have a conversation about what are 00:29:47.581 --> 00:29:49.821 you trying to accomplish here at Docs? 00:29:49.901 --> 00:29:50.461 Congrats. 00:29:50.461 --> 00:29:50.901 You've landed. 00:29:50.971 --> 00:29:52.301 What are you trying to do here? 00:29:52.911 --> 00:29:54.751 That is not an experience that I've ever seen. 00:29:55.181 --> 00:29:55.591 Have you? 00:29:56.746 --> 00:29:56.966 Mike Bifulco: No. 00:29:57.026 --> 00:29:59.986 And I think that the, those tend to be, for me at least, the most exciting 00:29:59.986 --> 00:30:05.026 applications of this LLM technology is where, where it's a second brain that 00:30:05.306 --> 00:30:06.506 actually is a second brain, right? 00:30:06.506 --> 00:30:08.986 Like in the past few years people have talked a lot about note 00:30:08.986 --> 00:30:11.906 taking and self-organization and things like notion and. 00:30:13.241 --> 00:30:16.131 Rome research and obsidian and, and being really good about 00:30:16.371 --> 00:30:17.171 documenting what you're seeing. 00:30:17.431 --> 00:30:20.771 But when the L LMS start putting that together for you and take the 00:30:21.161 --> 00:30:25.211 need to document yourself out of the picture and can become an educator 00:30:25.211 --> 00:30:27.411 for you, I think that's really interesting and really empowering. 00:30:27.831 --> 00:30:30.691 And, and I can see lots of different people getting into development 00:30:30.691 --> 00:30:32.731 as a result of that too, and I'm really excited by that. 00:30:33.696 --> 00:30:35.896 Danny Sheridan: I, I'll make a speculation here. 00:30:36.136 --> 00:30:37.976 'cause it's fun to guess about the future, isn't it? 00:30:38.341 --> 00:30:38.881 Mike Bifulco: No, always. 00:30:38.911 --> 00:30:39.201 Yeah. 00:30:40.246 --> 00:30:43.766 Danny Sheridan: I think that the number one consumer of API documentation 00:30:43.766 --> 00:30:48.326 in the future, we'll call it three years from now, is going to be LLMs. 00:30:49.961 --> 00:30:50.081 Mike Bifulco: Hmm. 00:30:50.461 --> 00:30:51.561 That's really interesting. 00:30:52.141 --> 00:30:52.361 Wow. 00:30:52.361 --> 00:30:54.721 Well, I guess we're gonna have to put it on the calendar to have you back on 00:30:54.721 --> 00:30:57.811 the podcast in three years, but I'd, I'd love to have you back sooner if, if 00:30:57.811 --> 00:30:58.971 that's something you're interested in. 00:30:59.711 --> 00:30:59.831 Danny Sheridan: I, 00:31:00.171 --> 00:31:01.241 Mike Bifulco: Danny, let, let's do this. 00:31:01.301 --> 00:31:04.551 So tell me about if people are interested in jumping in and getting started with 00:31:04.551 --> 00:31:05.711 Fern, where's the best place to go? 00:31:06.561 --> 00:31:10.661 Danny Sheridan: the best place to go is our website, which is build with fern.com. 00:31:11.701 --> 00:31:14.281 Mike Bifulco: We will of course have that in the show notes along with all the 00:31:14.281 --> 00:31:16.081 other things we've mentioned here today. 00:31:16.461 --> 00:31:19.481 One other thing I, I like to ask guests on the show is is Fern growing? 00:31:19.501 --> 00:31:20.401 Are you hiring at the moment? 00:31:21.406 --> 00:31:22.176 Danny Sheridan: Fern is growing. 00:31:22.356 --> 00:31:25.216 We are looking for a founding backend engineer. 00:31:25.966 --> 00:31:28.376 This person would work with our team in New York City. 00:31:29.336 --> 00:31:34.066 It's an onsite role, and they would be responsible for helping us expand 00:31:34.546 --> 00:31:36.146 selection of our SDK generators. 00:31:37.046 --> 00:31:40.386 So we're looking for someone who's excited to be a polyglot that might jump 00:31:40.386 --> 00:31:44.546 within a week between Java, Python, and Ruby, and is excited about languages 00:31:45.326 --> 00:31:47.706 and has a high attention to detail. 00:31:48.846 --> 00:31:49.136 Mike Bifulco: Yeah. 00:31:49.286 --> 00:31:51.716 Very cool that that sounds like a great opportunity. 00:31:52.216 --> 00:31:52.636 Danny Sheridan: And, And, 00:31:52.636 --> 00:31:53.556 lastly, Mike, I'll, 00:31:53.556 --> 00:31:54.156 I'll share that 00:31:54.416 --> 00:31:58.636 the salary range that we're paying for that role we publish, which is 130 to 00:31:58.636 --> 00:32:05.356 $160,000 a year, in addition to a half percent to 1% equity in a growing startup. 00:32:06.051 --> 00:32:06.291 Mike Bifulco: Brilliant. 00:32:06.291 --> 00:32:07.091 How's that for Open? 00:32:07.631 --> 00:32:09.651 I'm, I'm, I deeply appreciate that. 00:32:09.731 --> 00:32:12.651 I think especially in a world where lots of people are squirming to find 00:32:12.651 --> 00:32:15.271 the right place for them getting to that discussion around like, 00:32:15.271 --> 00:32:16.351 what does compensation look like? 00:32:16.351 --> 00:32:18.151 Where do you want me to be and what am I gonna be doing? 00:32:18.491 --> 00:32:21.111 It's really hard to get to and, and I think a lot of companies. 00:32:21.651 --> 00:32:23.511 Can and should aspire to what you just did there. 00:32:24.011 --> 00:32:27.451 We'll drop a, a link in the show notes as well to the job opening here too. 00:32:27.711 --> 00:32:30.021 And Danny, where, where's the best place to get at you? 00:32:30.021 --> 00:32:33.141 If people want to shout at you about SDKs or documentation, where, 00:32:33.141 --> 00:32:34.241 where can you be found online? 00:32:35.091 --> 00:32:37.831 Danny Sheridan: The best place to talk to me is actually going to 00:32:37.831 --> 00:32:39.911 the build with fern.com website 00:32:40.331 --> 00:32:41.711 and scheduling a call. 00:32:41.931 --> 00:32:45.001 Would love to ch if folks listen to this and they're like, Hey, I'm ready. 00:32:45.181 --> 00:32:50.141 I'm ready to make my API developer experience more like stripes. 00:32:50.281 --> 00:32:52.221 That's, if that's the intention, that's the place. 00:32:52.291 --> 00:32:54.061 Best place to find me is just book a call. 00:32:54.151 --> 00:32:54.861 Let's hop on. 00:32:55.986 --> 00:32:56.276 Mike Bifulco: Yeah. 00:32:56.496 --> 00:32:59.801 That is an opportunity not to be passed up friends, I think . Danny a, 00:32:59.801 --> 00:33:02.551 apart from being a, a very exciting person to chat with, I think you're 00:33:02.551 --> 00:33:05.271 also super knowledgeable and it's been great to have you hang out. 00:33:05.371 --> 00:33:07.911 I'm looking forward to six months from now seeing how you've shaped 00:33:08.011 --> 00:33:11.111 the, the planet of API developer experience in that marketplace too. 00:33:11.481 --> 00:33:12.321 Thanks for joining so much. 00:33:12.361 --> 00:33:13.241 I appreciate having you here. 00:33:13.331 --> 00:33:14.551 And looking forward to talking again, 00:33:15.301 --> 00:33:18.731 Danny Sheridan: Let's build APIs that people will love. 00:33:19.211 --> 00:33:20.311 Mike Bifulco: add away into it. 00:33:20.651 --> 00:33:21.591 All right, Denny, take care. 00:33:21.911 --> 00:33:22.331 Danny Sheridan: Cheers.