API Evangelist Conversation with Adam DuVander, Technical Content Strategist at EveryDeveloper

Hello there, Kin Lane, API Evangelist here again for one of my API Evangelist conversations where I talk to folks who are doing interesting things with APIs. Let’s not waste any time, let’s bring them on here and find out who they are. Hello there, who are you?

Adam DuVander. I long ago worked with you for a brief moment at ProgrammableWeb when I was the editor there of the API directory and news source, and now I run a company called EveryDeveloper, which works with companies that want to reach a technical audience, have a technical product, need someone technical to use it.

I was updating my knowledge base list, and I had to, haven’t updated it in three or four years, and I had to clean some sites off of there, and ProgrammableWeb was one of them that I cleaned up.

Yeah, broke my heart. Yeah, the background there, of course, that acquired a few different times but ended up with MuleSoft at Salesforce and had a good life there for a while, and just couldn’t quite make it through that overall company strategy is what it seems like.

So yeah, do you think that was it? Do you think it’s company strategy and how it was seen, or do you think there’s some wider reason why ProgrammableWeb couldn’t stay viable?

So, I mean, there is definitely the aspect of, maybe we’ve moved beyond the directory sort of stage, right? Like we no longer go to Yahoo and explore the directory of websites, why would we explore this huge directory of APIs? So that could be a piece of it, but Yahoo didn’t go away, and we still explore websites. So I think there’s still that need to understand what the APIs are, it’s still there, and it was a rich database of APIs and API history. So yeah, you know, from the outside and as a completely biased person in there, and someone who used it as like a second brain to be like, oh, what was that API that did, you know, shopping cart stuff for grocers in the UK, and I would search and I would find the thing that I wrote and what date it was, right? Like, so for me it was a useful resource still. I understand that not everyone was able to use it that way, but you know, there’s definitely good stuff there. And yeah, being able to trace, you know, things like the rise of JSON, I mean, it’s almost hard to imagine now that there was another data format that was the most popular data format, right?

So, well, in the hockey stick API, number of APIs growth chart, I mean, we all plotted our course in this journey using that. I’m so used to, every conference I would see it, and just a couple months ago I was at a conference in New York and snapped a shot of that chart again and sent it to John Musser, the founder of ProgrammableWeb. I said, it’s still alive, it’s still out there.

Oh my god.

So I mean, the APIs and I think that hit, rich history is super important, but the storytelling on ProgrammableWeb is what I enjoyed the most, at least in the prime, in the heyday of it. Towards the end there, and I know that’s one of the reasons it kind of became lead gen I think for a lot of people, about the directory and lead gen for a lot of those in the space. But let’s move to the content piece. So I kind of feel like we’re hitting the end of, it’s like web, you mentioned web, you know, there’s a time where we stopped talking about the web as this like new and amazing, and it just became ubiquitous, and APIs I think are kind of doing that. But those of us who are producing APIs and can’t, you know, get listed on ProgrammableWeb and tell our story on ProgrammableWeb, what should we be investing in? How do we tell that story? How do we get it out there?

Yeah, and I should say, I agree with you. An, you know, 10-plus-year-ago version of me agreed with you. I think John found me from something that I wrote that said mashups are dead and the web is alive, because we used to talk about combining APIs as mashups, but I mean now it’s just, it’s just like the way that we use software. And yeah, I’m sure that there’s a post on ProgrammableWeb that said that about APIs too, that APIs, we need to stop talking about them because really it’s what you do with them that’s interesting. And that’s where the stories come through, and that’s, I mean, that’s the work that EveryDeveloper does with clients, and the things that, you know, if you see me shouting from the rooftops about things, it’s definitely going to be about, like, why does this matter, right? Like, no one wants to add another row to a database, like, that’s not actually a job to be done, except maybe by a database administrator, right? So yeah, it’s what’s the point, I mean, really, right? Like, if you, how I ended up where I am is starting from that journalistic standpoint, and that was the question I had to answer as a journalist, right? What’s the point? Why is someone who’s reading ProgrammableWeb going to care about this? But at some point I realized the companies don’t necessarily know what the point is, we need to help them, we need to help them figure out what that point is. And that, you know, it turns out that that’s called marketing within an org chart, but really, I mean, I think that’s what everyone across the org should care about, about what they’re building, and definitely in building APIs you want to be able to know why are you actually doing this. It’s not to add that row to a database.

So who’s this got to speak to? Is it, I mean, because the stories we always told were for developers, get developers excited, and that’s what you and I have kind of made out of. Is it still that? I mean, are we still just trying to tell the point of it to a developer, or is it to a wider audience?

Yeah, I mean, I think that depends on who that product is for. So a lot of times the products that I’m working with are ones that are dev tools, so that is that audience. But that’s like one of my top questions for someone, is really drilling into, and sometimes they come to me thinking that, okay, so this is an API so the audience is developers, and I kind of have to say, like, I don’t think that’s who this is. And that really showed to me at Zapier when, working on the platform, so I was there for a couple of years, and like tons of APIs and want developers to connect them, oh, I seem like the right person in there. And it came through talking to folks who actually wanted to use the platform. So they have an API at a SaaS company and they basically want to stop saying no to their users. Like, that’s actually what they want Zapier to accomplish, right? Like, oh, do you integrate with such and such, oh no, we haven’t added that yet, we’ll add that to the roadmap. Well, they saw integration, Zapier, to be the answer to that. That’s not necessarily developers that care about that, that’s products, that’s support, that’s sales, that’s biz dev, right? Like anyone who, it’s actually a big part of that org chart that cares about being able to say yes, we support that, whether that’s an integration or other functionality. That’s, you know, someone wants to be able to build on top of the product you have. At some point if it’s integrating APIs it might need a developer, but I really look at it as is it developer focused or is it a developer that enables that feature. And even that is a spectrum with a lot of spots along the way, right, where a dev might not even know until the end that this needs to happen, in which case, yeah, like the only story you have to tell to a dev there is you can trust us and here’s the docs that show you how to do it.

Yeah. So it doesn’t sound like the story or the output, the final thing, the content, is actually the whole purpose here. It’s also the process of having someone like you to ask these questions along the way and be a partner, kind of like, why are we doing this, what is the point of our product, why are we telling this story, why are we trying to reach, who are we reaching, all of these hard questions, where are they at, what are they thinking, and it’s not just the act of writing a story or writing a blog post or a series of blog posts.

Yeah, and I mean, really, if it’s at the point of a product that’s in the market and you’re doing that, you’re probably way late if you’re just thinking about how it’s going to be used, right? And that’s, certainly in the API space, I mean, we’ve worked with API design and development tools here, so if you’re in this space you know that you have to think about that at the beginning. But that’s not always obvious, and some of those things aren’t necessarily known yet, right? If there’s a mandate to create this API to do this thing, add a row to a database, kind of a functional conversation, then there’s not that contextual, why does this matter and who’s the user we’re helping, those sort of, it’s full CRUD, it’s create, read, update and delete to the database.

Yes, that’s right. So you mentioned product, sales and support, do we have to expect them to become more API aware and get in the API game, or should the engineering, should we be reaching out and going there, or is it a little of both?

Yeah, I’m not sure that it’s necessary, but certainly knowing whatever, whatever someone who’s not building software knows about the software process, the better, right? If you understand that there are, to achieve the goal that you have, there are some pieces of infrastructure that need to be built and connected, that’s the important piece, and being able to explain what you want that stuff to accomplish is really the key there. So like, I mean, to your earlier point about should we even be talking about APIs anymore, isn’t this just software, like, yeah, maybe, and you know, it’s how it’s built, but I mean, just recently I was sitting on the couch with my wife and she made something happen in some service, she’s not necessarily technical in that way, right, but it was like, oh, log in, approve this access to this thing, and she looks over to me and she says, thanks, APIs. But not everyone has sort of been immersed in this, right, and so I think in that sense, if there can be some institutional knowledge about how we make these things happen and what’s even available, that’s often a big question at larger companies, right, then that’s good.

Yeah, yeah, I feel like it’s just moving into the wall, like the electricity and the water, but it’s a little more digitally universal than that, and we’re going to need electricians and contractors and people who pay attention to this, but for the most part people aren’t going to care, are they not, if the thing does what it wants, right, or what they want it to do.

Right, and so that’s the goal, and that’s been the thing that interests me for the longest time. When I first came to Portland there were lots of like language-specific events, you could go and you could talk about Perl or PHP, and I said, like, I like those because they help me do the thing that I want to do, and that, I created a group that, and it was in the Web 2.0 sort of timeframe, so it’s like, this is when there were people who were like, oh, I’m a designer but I do care about what happens on the back end, and kind of getting groups together that care about what you’re actually building with it, and that, it still feels relevant today even though all that toolset has changed, right? Like we might talk about Ajax that makes the thing happen, but that X, as we already talked about, is probably not XML, that’s probably JavaScript that’s coming back, and you know, that’s just the way apps are built now, there’s whole frameworks that handle that communication.

There’s cycles here, I’m sensing, and so it’s all the time we have today, but you know what, you gave me an idea as I was spinning my wheels there, is to do some sort of retro check-in on a couple of different areas you’ve tagged, hit me on a couple things, Web 2.0, XML-RPC, Ajax, things like this. And the great thing about this new format is I can have you back and I can do this regularly, so I think we’ll have to stay tuned for a future episode, but I appreciate you coming by, Adam.

Oh yeah, anytime, good to see you.

Alrighty, until next time. So we’ll keep that in the background and let Adam go. And all right, that’s another one for the books, but I’m definitely going to make this a regular occurrence with Adam, because as you can tell, him and I go way back, and I think a couple retro episodes down the road are going to make some sense. All right, well, that’s it for today, thanks everyone, and have a good one.