Haxor founder, Ian Jennings, was featured on episode 3 of OK Human, a podcast about developer empathy created by Headspring. Listen below!
In this episode, we talk to Ian Jennings, founder of the Developer Experience (DX) platform Haxor and a pioneer in this nascent space. What is DX? Another buzz term to fuss over? More like a no-brainer. Ian shares his thoughts on why DX makes sense—not just for makers of developer products, but for internal teams as well. We’ll talk about what it is, how we measure it, and how it relates to things like User Experience, Customer Experience—even DevOps. As Ian points out, “Every developer experience is responsible for thousands of user experiences.” 🤯 Whether you’re a developer, product maker or IT leader, this may be well worth a listen!
Speaker 1 (00:00):
Hi, nice to be with you again and welcome to episode three of okay human, the podcast about the people’s sides of technology. I’m your host Patrick McVittie mill and today we have a guest with us who spent his career advocating for and enhancing experiences for the developer community. We’re really excited to welcome Ian Jennings to the podcast. Thanks for taking the time to be with us, Ian.
Speaker 2 (00:19):
Hey, thanks for having me.
Speaker 1 (00:22):
Ian is the founder of the developer experience company Hacksaw where they work on optimizing the developers experience when utilizing API APIs by performing user research with developers. Before that he worked in DX that’s short for developer experience at PubNub, which makes products for developers to build real time web, mobile and IOT apps, and also built and sold the hackathon platform hacker league to Mashery and Intel and has an impressive background as a front end developer. We’re thrilled that he’s here today to talk with us about DX and why it’s becoming a rising interest for companies. So, even when I hear developer experience, I think about, well how good of a time am I having as a developer when I’m coding? Is it more than that or what, what does developer experience mean to you?
Speaker 2 (01:07):
Essentially? Yeah, it’s about how easy it is to get started and work with developer products. And as we’ve seen so many developer products enter the market, it’s becoming more and more important for these companies to differentiate themselves from other companies by improving their developer experience.
Speaker 1 (01:25):
So when you say when just companies in general, you just mean all, all sorts of technology, anything where developers are a piece of the puzzle,
Speaker 2 (01:33):
making that experience better or, yeah, so since, um, Amazon released this memo called the famous Bezos memo in 2002, um, more and more technology companies had been pushed to make API APIs. And so now we about, you know, 10 or 20 years later, we have all these companies which are essentially producing developer products. And, um, as we see, they’re essentially not really paying any attention to developer experience. They’re just mostly pushing out that the functional portion,
Speaker 1 (02:03):
they just putting out an API and saying, there you go, we’ve done it, you’re welcome. Bayzos are welcome developer community. You’ve got it from here, but it’s,
Speaker 2 (02:11):
it can stink. So yeah, most of them do. And that’s what we found over over the years of working at PubNub, um, hacker league and the time that hackathons is that a lot of this documentation becomes outdated very quickly and it’s full of bugs.
Speaker 1 (02:25):
Gotcha. So tell me a little bit more about Hacksaw or what’s the, the, the mission there.
Speaker 2 (02:30):
The idea behind hack, sir, is to improve these resources. So any one of these API’s can be a developer’s first time learning some concept or even getting started with a new language. And a lot of the API documentation and resources are not very accessible. The mission is to make developer resources more accessible or to educate and empower developers to use these new technology products. So instead of just assuming that these are advanced programmers who are using these products where I want to make them more accessible to everybody.
Speaker 1 (03:01):
So if I’m a company that has an API and I’m trying to figure out how are people going to use this, this, that’s something that hacks or could help me with.
Speaker 2 (03:08):
Yeah, exactly. So Axler we hired developers to work with API APIs while recording their screen and code changes and they offer um, insight into where developers encounter friction, uh, where they have problems, where they find bugs, things that are confusing, where language is inconsistent so that the maintainers of these products can essentially fix those bugs and make it smoother for the next developer.
Speaker 1 (03:32):
That’s really cool. That’s, that’s something that, I mean most of the time, if you’re lucky, the API you’re working with is open source and you might be able to file an issue or something like that. But a lot of times there’s not much responsiveness with, with the group that’s owning that API. So to have that as a focus upfront, I imagine really helps with, with all of that
Speaker 2 (03:52):
really we’re starting a conversation between the people who are producing API products and the developers who are consuming them right now. I think there’s a really big disconnect and a lot of the developers, you know, developers just want to code, they just want to, uh, get their stuff out. And so if, if it API product has problems, often they’ll just move on to the next one. They won’t ever submit a support ticket. They don’t ever complain to anybody. They don’t email anyone. They just want to keep coding. So they’ll still other brute force it or they’ll move on. And these companies are really lacking that feedback.
Speaker 1 (04:24):
That’s interesting to think that they’re, you know, the, the APIs are being produced by developers. They probably are caring about how people are using it, but they might not know.
Speaker 2 (04:33):
Yeah. So, uh, we have a saying, which is you can only be new once. It’s effectively impossible for a developer to empathize with someone who’s not familiar with what they’re writing. And that creates a huge problem because often the developers are tasked with actually writing the documentation and they’re familiar with every single little nook and cranny. So it’s really difficult for them to get inside the head of somebody who’s new. And often you’ll see that in docs, uh, very short code samples with a little explanation because the developer knows everything about it.
Speaker 1 (05:03):
Right. That’s, I mean that’s a problem that I’ve seen with, with mentoring. When someone senior is working with someone more junior, just imagining what’s it like to be a novice, how do you not know this, this thing. And being empathetic in how you present ideas and how you approach teaching someone something with a foundation of nothing instead of all of your years of experience or your expertise in how an API works.
Speaker 2 (05:29):
Yeah. And it even goes beyond internal. Uh, it even goes beyond the company as well because if you’re sending the docs out to your own developers within your company, they are still familiar with the language. They’re still familiar with the different portals and where to find the keys and things like that. Um, whereas it might be extremely confusing to somebody who’s new. So what we’re really doing is showing them this fresh perspective.
Speaker 1 (05:55):
So what, what does that look like when like what is a good easy to use, nice developer experience on an API
Speaker 2 (06:03):
and ended up shaping up as well. Stripe and Twillio are the GoTo references for what people are shooting for and most companies are trying to play catch up with them. Recently they’ve IPO and really proven that developer experience is something, uh, valuable and it’s a really differentiator in the market. Those companies have a huge eye for design. They’re performing these tests, they’re getting that feedback and they’re out there on the ground watching over developer’s shoulders and making sure that they are having a good time like you wrote them with, right. While they’re implementing with these API’s,
Speaker 1 (06:40):
when you’re conducting that kind of research, what are the things, what are, what are the hurdles that you look for? How do you tell that an experiences is good or
Speaker 2 (06:49):
in that moment we can easily see as we’re observing developers where they are encountering what we call friction. And that’s essentially hesitation or questions, things that are confusing or things that take away too long. So if you see a developer struggling to find something in the developer portal or maybe they keep getting error responses when they’re working with an API, it’s pretty easy to find out when a developer gets frustrated. And um, if you’ve done any programming yourself, you know that you’re actually probably spending about 80% of your time debugging things, encountering problems, right. There’s only maybe like one or 5% of the time where you’re actually producing code that works. Right, right. Yeah. Lots of time. Yeah. Scrolling around, making grumpy faces saying, I’ve already been on this page. Things like that. Yeah. And we also, you know, we’re looking at audio transcriptions and listening to the developers as they go, wow, that didn’t work. I wonder how to do this. Why isn’t this working? And so we can actually jump around and see exactly where developers are having trouble.
Speaker 1 (07:45):
And then you can present that back to the product owner and say, Hey, maybe you should change this. Maybe you need more documentation. Okay.
Speaker 2 (07:51):
Yeah. So we, we summarize those friction points and prioritize them based on the likeliness that a developer would encounter them. Or, or effectively leave the whole website entirely and um, present those in an actionable report and, and have them improve their developer documentation based on those findings. That’s really awesome. I think that’s, I mean that that
Speaker 1 (08:11):
missing piece of information, of sharing information, those artifacts is really valuable when you’re developing things. So,
Speaker 2 (08:19):
Speaker 1 (08:20):
You mentioned hackathons and how this sort of, the need with APIs and all that has, how have hackathons were a part of that.
Speaker 2 (08:29):
Speaker 1 (08:29):
How does that model of programming and learning, how has that influenced your take on the developer experience?
Speaker 2 (08:37):
Sure. So hackathons really are a larger event full of people learning. And as those people are learning, they’re working with new tools. And a part of the incentive for those sponsors are those API companies to be president of those. Our events are to learn about how developers are using their product. And so they’re there watching developers and answering the questions and then they’re secretly writing down where developers are getting stuck so they can improve their resources in the future. What we’re doing at Axar is essentially boiling that down into a, a repeatable process that will produce that same feedback.
Speaker 1 (09:12):
So instead of having to get dozens of people together and saying, go, you’re, you’re acting as a laboratory with a targeted effect. Yeah, exactly. So we mentioned in the intro that you also started this company, hacker league, that that was related to organizing hackathons. How does that relate to what you’re doing now and to develop an experience?
Speaker 2 (09:33):
So when we started hacker league, the idea was to document what had happened at hackathons. So, uh, we were students going to hackathons and we’d essentially spend the whole weekend coding and building products. And then, um, at the end, the convention at the time was to submit your hack into a survey, um, a survey document. And then that would post into like a, a Google spreadsheet or something. And nobody ever saw what was made. It’d be demos, there’d be presentations, but there was no document, if anything, I’d never happened. So we made a website to document what developers were doing at the hackathons. And at that time it really was, you know, maybe a screenshot, a demo and some texts about who worked on it and what that, what the app did this, uh, with hacks or is sort of a high resolution document of what had happened at the hackathon. Right? So it’s showing you that the steps people took and the things they built and the problems they encountered along the way as long as, as well as the finished product. So it’s essentially just taking a high resolution look at the same thing we were doing with hacker league. Um, again, taking it and putting into that nice package, a, uh, in a condensed and like very informative look at what happened during this developer experience. Right? So hackathons are just two days of developer experience,
Speaker 1 (10:52):
high intensity concentrate. Um, yeah, that’s, that’s really interesting that, that, uh, that both of these are related to that idea of communication artifacts and not losing them. That, uh, your experience at a hackathon could really be a flash in the pan and then it’s forgotten without ever, you know, retrospecting on what was this like, what did we do? Uh, and yeah, I guess before hacker league, just that getting sent into the ether and forgotten by all. So it’s interesting how between thinking about your developer experience actively and with Hacksaw or looking more at at really deliberately assessing the experience and then leaving something behind, which in itself is part of the experience.
Speaker 2 (11:40):
Yeah, I feel like I’ve been building the same business over and over again. There’s another company I started called dev port, which has developed work portfolios and again, it’s documenting what I’ve done personally in my career. So I think that as the space changes, the company changes, but really I’m solving the same problem, um, over my career
Speaker 1 (11:59):
of just of there not being enough information about things out there as they happen.
Speaker 2 (12:05):
Yeah, I think that we have get to do collaboration and tracking, but I, I don’t think there’s real documentation on how developers work. I think that, I mean that’s what’s interesting now and that’s where we have like a podcast like this and where the space is going, are people really want to understand how this work is being done. And we don’t really have a lot of insight into it because honestly, most of it’s happening, you know, alone in your room or you know, and private. We really only see the deliverables at the end of the day and we don’t understand how much time is taken to complete a task. And it’s, again, this is a huge problem even in engineering management, um, with like JIRA tasks and trying to estimate how long something will take and then you send it to your manager and they say, why did that take so long? And you have to kind of go like, you know, you’re trying to justify what you did, but if, you know, I’m not that, I’m suggesting you track yourself all the time, but if you were, it’s going to help other people empathize with how really freaking difficult it is to be a developer. I mean, it’s incredibly hard.
Speaker 1 (13:07):
Yeah. And it’s, it’s, uh, that problem space of sharing approaches. I, you’re saying it coding happens in private, even at large companies where it’s, it’s semi-public year. You’ve got all these teams, how they share ideas about how they approach problems and what’s actually happening and then reporting it back to the stakeholders of it to say, Hey, this is working. This isn’t there. You’re right. That, that, that’s difficult too to codify and share.
Speaker 2 (13:35):
It’s hard to explain. Yeah. It’s, it’s hard to, to quantify. It’s hard. It’s just hard to justify a lot of times. And you know, there’s a lot of memes and you know, media out there about how developers need like a unblocked time in four hour blocks to get anything done. You know, stop giving developers meetings. I’m on board with all this stuff, right. I’m trying to show like it’s, it’s hard out there. Um, and people think it’s, you know, that’s why these people are getting paid so much and it’s why they’re, it’s like growing space.
Speaker 1 (14:03):
A lot of folks will, we, you know, will demand some, some proof in the pudding before they’ll just accept that something was hard. And yeah, that’s, that’s interesting that you’ve got this kind of chicken and egg where you, you want to work with people and trust, but that there’s, if there’s no detailed evidence that can be a problem for some folks.
Speaker 2 (14:25):
Yeah. I mean a lot of our customers are coming to us and saying, Oh yeah, developers can get started in 15 minutes with our API and it’s just completely unrealistic and they, it takes at least an hour for what these people think. It takes 15 minutes. And so even the developer companies that have a don’t have an idea and they’re, it’s their own entire strategy.
Speaker 1 (14:45):
How is it that when you’re working on your own product, you can lose sight of what it’s like to use?
Speaker 2 (14:52):
I think, again, I think they’re familiar with a lot of the vocabulary and navigation of their own information products and their, their websites and things like that. I think that they’re trying to be optimistic and they’re often not citing optimistic cases. And again, I don’t think they’re, they’re really measuring this stuff. [inaudible] very typical measurement that these companies are using is they’re measuring time to sign up to first API call because those things can be tracked automatically through traditional marketing analytics. Right. And if I’m a developer, often I might spend half an hour reading the docs and setting up with the demo keys before I even sign up and then I might sign up and make the call right away. So they’re actually missing this the story. They’re not really looking at the entire environment
Speaker 1 (15:35):
cause you, you could be working for days with the sample and points even and have something that you’re pretty confident about it. Yeah. That’s written, that’s totally lost. Otherwise all of that time that ramp up any of your experience building to that point. Yeah.
Speaker 2 (15:49):
I could be using, um, some old keys, make a new account and sign up with a new key and completely distort that metric pretty easily. When I moved to production for example. Right. I’m going to make a new key and then just move over. So, uh, I don’t believe those metrics are accurate. Um, like continuing on that point, a lot of these companies are using full story or um, Hotjar or some of these usability analytics tools, uh, screen recording tools within their websites. And I’m hearing that, you know, these sessions that the developer just tabs over to the document, clicks around copies and pastes and it goes back into their editor. So, so the session recordings look crazy, right? They live, they don’t, they don’t really reflect the developer experience at all. They reflect the, this small, small portion developers don’t want to be on your website. Yeah.
Speaker 1 (16:39):
Right. Yeah. That, that’s got to look really interesting. I was just thinking about it. Yeah. Diving in, copying something pays to get, but yeah, you’re, you’re gone instantly and to think that’s how much time it took me that time to copy it. Assuming that’s also me absorbing and understanding and really I’m ready now is, is yeah. Stark contrast from the actual working process.
Speaker 2 (17:04):
Yeah. You brought up a good thing too, which is what is under, like we are measuring understanding, which is pretty difficult. So what does that, uh, those analytics are not really demonstrating understanding or usage. Right. And so trying to quantify this or measure it is a, is a large problem. It’s, it’s hard. Yeah.
Speaker 1 (17:23):
It’s like [inaudible] do you want to like quiz people on, on your API? You know, I guess that’s where like certification programs are sort of like the proof that you do understand something but you can’t have that for every little API. And then, I mean, yeah, you certainly can’t ask your customers as they’re getting started,
Speaker 2 (17:40):
fill out these surveys and the, and the Tessa, um, that’d be off putting. Yeah, exactly. So part part of what we’re doing, our voluntary sort of recruitment process to have developers off of that information, um,
Speaker 1 (17:53):
to produce those results. Right? Because again, developers don’t really want to be bugged unless they’re incentivize to, so how do you incentivize developers to, to do those activities and report that sort of thing.
Speaker 2 (18:03):
So we’re rewarding them for their time or paying them between like 50 and a hundred dollars an hour to participate in the tests. And the developers are usually astatic to participate because they get to learn about something new. Um, there’s not, there’s pressure to complete the test, but they’re not expected to finish or deliver a full app. They’re, uh, love to be heard. So, you know, contrary to what you think, developers don’t like to be writing technical docs, but they love to complain. And so we really don’t have a PR problem finding developers to participate. Um, they, yeah, they, they love the jobs and we get, we get repeat developers all the time.
Speaker 1 (18:43):
I mean, that makes a lot of sense. You get to learn something, play around with it and then gripe I that. Yeah, exactly. Yeah. And again, if you look at hackathons, I mean you have thousands of developers right there just to learn and get experience coding. So there was almost no incentive there except community and learning. Right? Yeah. It’s interesting that it’s so easy that that developer mindset is so eager to learn and, and tapping into that. And making it productive for everybody involved in instead of it just speaks to that person. Yeah. Yeah. So it’s like here’s the environment where you get to do what you love to do and we’re actually going to pay very close attention and listen to you about what you care about. And by the way, we’ll give you some cash at the end. So it’s refreshing. Yeah. Yeah. So developers are thrilled. Yeah. So how does DX fit in with the larger advocacy arena? Like with dev, REL or developer evangelism practices?
Speaker 2 (19:37):
It’s still to be seen officially how it fits. It’s so early. I’m working mostly with developer experience leads who have just been appointed to the role. So even in Austin, I think we might have three or four people who have title director of developer experience or DX manager. It’s so brand new that it’s still being established. How these roles fit into an organization. When I was working at PubNub, developer relations was called developer evangelism. That’s not the case anymore. Um, and I was doing developer relations, but one of my coworkers was organizing meetups five nights a week while I was building developer documentation and SDKs and we were on the same developer relations team. So that doesn’t make a lot of sense in, in inside a company. And I think we’re going to start seeing those roles be divided up. And so retroactively that’s actually developer experience building those SDKs and making those tools.
Speaker 2 (20:32):
And what this meetup I’m organizing is about as a community or developer relations. And I think that’s how we’re going to see that play out is maybe there’s a larger dev REL team and then that’s made up of developer experience and developer relations and developer community. Um, or maybe the dev REL, the developers dream team is under product, but those teams are still being formed. And we’re still working on educating these companies about where this fits in and how it’s different. You know, there aren’t any developer experience books and we’re just starting to get developer relations books. So there’s a lot of education to be, um, to be taught about how these things work together in a company
Speaker 1 (21:11):
that’s exciting and it’s good to see these areas keep growing and you know, it’s companies are actually interested in what their developers experiences and engaging the larger community. Uh, it’s nice to see that instead of just sort of letting things keep chugging in a frustrated vacuum. So
Speaker 2 (21:30):
yeah, I think that it’s, it does fit in the developer relations because like, um, I think the word frustrating brought this up for me, but you know, the way I see it fade is you have these developer relations, um, members who are essentially fielding the support from the developers and they want that to be actionable. And I feel like the people who make that actionable would be the experienced team. And they can say, well, this is what we need to do in response to these complaints we’re getting. Right. And typically I think what’s happening is a lot of that’s going to support, but I think that there’s a room to rearrange this stuff and have it sort of get that sentiment to developer experience. And support and product and kind of bring that stuff all together. So developer experience to me is sort of looking at all that process and making sure that this SDK team, what they’re doing is making sense with the docs team and with the portal team and making sure that that all makes a cohesive story because often that’s what we’re trying to fix, uh, with hacks or is that they’re, these, these companies operate in silos and they’re not communicating with one, sorry.
Speaker 2 (22:34):
The teams are operating in silos and they’re missing, um, bridges between what each team’s responsibilities are. So for example, one team might call something the username and password. Well, the next team, I call it the key and secret, even though they’re physically the same thing, um, we’re seeing disconnect between them. And so developer experience is responsible for making sure that vocabulary is consistent across all the teams and things work smoothly.
Speaker 1 (22:58):
That that shared language and vocabulary is so crucial. And it all ties back to empathy and communication and all that. And it just to think that something so simple can create such a wall and such a disconnect between, you know, being able to collaborate effectively.
Speaker 2 (23:15):
Yeah. I mean if you, you, we’ve reviewed docs where there’s six variables for the same two ideas, right? So there’s really, so even beside achy and secret where you can also have ID and password or whatever, like you can just keep going and I feel developer experience is about unifying that and understanding that, Hey, this team named this wrong and this team, is that what, you know, what are we going to call this internally, these [inaudible] and nailing it down. Yeah. Because the developer doesn’t care about the silos in teams. Right. They don’t even know. They don’t care. They want to, they want that consistent experience.
Speaker 1 (23:49):
And you might, yeah, just your, you’re on the using end of it API, you’re just saying like, huh, that’s weird that this parameter name is different even though I’m using the same value and Oh, well yeah.
Speaker 2 (24:00):
I, I tied into con, um, uh, the new field of customer experience. So if you look at customer experience, you have, um, people who are looking at every, every part of the customer journey from the first time they see an ad to when they’re returning the product at the end they use are people who are looking at this holistic view of what it’s like to be a customer of this company and making sure that the language, again, you used on this ad is the same as on the return label. So developer experience to me is that entire story. So what is it like, um, to see that first advertisement and uh, and then what, what’s it like when I have to follow a support request and making sure that that is, is fun, right? It’s fun and good and I’m going to do use this company over another company because their experience is better. Yeah.
Speaker 1 (24:46):
Yeah. And that, I mean, with the grand scale of technology these days, that developer experience is something that you might consider when you’re choosing between two things.
Speaker 2 (24:56):
Yeah. So every developer experience is responsible for thousands of user experiences. Right? So these developers, over the past 10 years I’ve been identified as decision makers and it’s important to impress them because they can switch over to another API within an hour or two hours if they don’t like what’s going on with yours. And that could mean that you know, this entire company’s suite of products is no longer using your API just because there was some friction in the beginning of their journey. So it’s incredibly important for these developers to have a good experience. And that’s what the developer experience journey and friction mapping is about.
Speaker 1 (25:33):
Yeah. That just like if I’m spiking out different texts that I might use different API APIs and I decided to go one way or the other, that could totally informed the, the whole step-by-step using other pieces, other libraries that are related to it more closely than, you know, a different option. Just because I had friction early on or I couldn’t figure out one thing I needed to do now that’s totally lost for, for that product.
Speaker 2 (25:59):
Yeah. Sometimes it’s easier to switch companies than it is to figure out the problems with the company you’re working with. When I, when I took a job at PubNub, it was because I was working with one of their API’s, um, on a, on a project and I had actually gone through five API APIs before landing on them. There’s was the one that worked out of the box. Um, the technical reasoning for that was because the other APS were using WebSockets and some other kind of newer technologies. While PubNub had a fallback, which allowed it to work in a more generic solution, they actually had a better developer experience. And when you look at that, you know, I, I invested in that company, I used it for my project and I also got a job there and worked there for five years. So that developer experience, just making that decision was hugely impactful for them. Right. That’s the, that
Speaker 1 (26:45):
the fact that it had a fallback and that made her work is interesting because a lot of times you might even not wanting to invest the time to figure that or you’re just saying, Hey, this one’s not working. This one’s not working. Oh, but this one does. And maybe later you go see why. But that the time invested to learn about the different API APIs is something that
Speaker 2 (27:04):
a lot of people wouldn’t put in. I think a lot of companies assume developers are going to be thrilled to learn about all the API inner our workings. Right. There’s also this funny misconception that developers are thrilled to be in your developer portal and really all they want to do is take the keys out and go back to coding in their local environment. So, um, yeah, I think that there’s, again, people are fascinated with their own products and their love with their own babies. So they, they think that developers are gonna love it, but really developers want to just add your service into their product and move on cause they’re, they’re purchasing from you because they don’t want to get involved to build buy. Right. That’s a build versus buy argument is they don’t want to be investing time into it. Time is what they’re saving by by purchasing,
Speaker 1 (27:48):
but yeah, by using some other tool instead of doing it themselves and that, yeah. Surely there are some tinkerers out there who want to get into the guts. But yeah, that’s, that’s a, an unfair assumption that the masses are,
Speaker 2 (27:59):
uh, [inaudible] when you were going to company and that’s all you see Fe today responsible for it. You think that everyone’s in love with it and you’re, you’re seeing engagement. So you believe that that’s what people, uh, that people are getting it a chance, but really they want to copy and paste and get it out of there. Right.
Speaker 1 (28:14):
So you mentioned that more companies are making developer relations of priority. Uh, why do you think that is?
Speaker 2 (28:20):
Well, like we mentioned earlier, I think developers are responsible for, you know, multiple products with thousands of users and over the past decade they become influencers within the company. So they’re now decision makers and they’re actually evaluating products and determining what services the companies use. So, um, new Relic published this book called the new kingmakers a few years ago, which is talking about this transition where developers are actually becoming decision makers and a lot of decisions are now, um, bottom up rather than top down. So it’s important for the companies to please the developers because they’re going to be the ones who are not only making decisions but also working with the product. Another trend is the, again, the increase of API APIs in in the space. So back in the day there were as only, so back in the day there was only one SMS API, right? You just use Trillia.
Speaker 2 (29:15):
Now there’s plenty now there’s probably 20 or 30 or 50 of these API APIs. In order to choose an API to use, you’re going to look at the developer experience, the marketing material and stuff like that. So, um, I mean the API market has exploded when we started hacker league, they were maybe 500 API APIs listed on program web and within the last year I think they’ve reported like 25,000. Yeah. And then along with that, um, a lot, again, a lot of that early API space, a lot of the documentation was accurate because there was only a little bit of documentation and there were only a few developer products. As the space has exploded, well we’ve got a ton of different developer products. A lot of different frameworks like just off the top you have like react and angular view and Webpack and like these are all concerns and you need to have guides for all of these different platforms. So as the space has matured things, I’ve got a lot more complex, there are a lot more options and frankly there’s a lot of information that’s outdated because things keep changing and moving forward. So, um, the, the companies are investing all this money into these, this technical content and it’d be a shame if it just gets outdated within a weeks because no one’s updating it or even making sure it’s relevant,
Speaker 1 (30:29):
right. That the space has been getting bigger. But I was thinking all those companies that are still here, they’re getting deeper too and all of these versions of things and just, yeah, like you said, not making sure that pieces aren’t outdated and they keep adding more and like react keeps adding extra chunks to it in the nicest way to do things. Keeps changing. But you know, the software that I wrote two years ago, I don’t have time to go totally update it. Um, but pulling in where I can and learning what those are becomes a lot more complicated.
Speaker 2 (31:00):
Exactly. So like my time at PubNub, they had 70 SDKs and each one of the dusty Ks has to be good. Right? Right. They have to be performing and they have to be documented and they have to be, have a great developer experience because that’s how you’re serving your customers. Right? So there’s this trend, this is sort of countertrend of developer documentation, generation, SDK generation and these things they take in a Jason schema and they spin out these SDKs. But the thing that everybody’s missing with these is that there’s no human interaction happening here. It’s just, it’s just printing out what’s available and it’s not getting you any usage information. There’s no empathy. It’s just saying, here’s what’s available. And, um, I’m often advising startups to, to avoid the SDK generators and start with a rest API that has a lot of that human element. Yeah. So no matter how much we generate, we’re not going to get good usage docs because it’s like somebody has to write the instructions,
Speaker 1 (31:59):
right. The, the human side of describing something and explaining how something works is just, yeah. Computers aren’t at that point where they can accurately translate into something that we can really understand. Yeah. It’s storytelling.
Speaker 2 (32:14):
When it comes down to it, you want to know what the story is. It’s not just a bunch of fragments of sentences and methods and things you want to show what the journey is going to look like and explain how these things are useful and make market cases and update those stories for the times because those things get outdated. Um, so I think that’s why people are investing in it. I think they, they’re noticing that we can’t code our way out of this. Right. We can’t, no matter how many documentation products that people purchase, the information can still be bad. It probably will be bad. It’s not going to solve the human part, right?
Speaker 1 (32:49):
Yeah. Unless, unless you’re making an effort to
Speaker 2 (32:52):
engage with the human part, it’ll never be there. It’ll always just be code. Yeah. So it’s uh, you know, going back to the, the title of the podcast, like we have, it’s not machines, programming humans to use their own information, right. We need to have humans programming the machines and the machines actually need to talk about what in a human way, right. How they can be used on the other side of it. Yeah. Yeah. Because at the end of the day, we’re people sitting here coding these things and making them, you know, manipulating the machines to do we want and, and we have to know how we can have, we can do that. Yeah, definitely. So
Speaker 1 (33:32):
with this expanding field of developer relations and developer experience, say I want to get into DX, where to, where do I go? How do I start?
Speaker 2 (33:43):
I think if you’re going to get into DX, you would start on a developer relations team and bug your manager or supervisor to create this position for you within the company. Um, some companies have started to hire for developer experience and so we’re seeing a lot of job roles open up for four people responsible, but nobody has any official experience right in the, in the, in the space. So if you want to get into DX, I would say that you would again try to apply for a few of these roles or make the role yourself within the developer relations team. Um, I would bet a lot of people are doing developer experience already and they’re not calling it
Speaker 1 (34:20):
right. Just not in an official capacity there. They’re looking at these problems and asking these questions,
Speaker 2 (34:27):
putting the, the DX stuff on it. Yeah. So I, I mean often we’re seeing these titles like API product manager, which is could be developer experience or we’re seeing developer relations. People produce tutorials and they’re producing docs. That’s probably actually developer experience, right? Um, I think we’ll see a lot more official teams pop up and a lot more roles. Um, we don’t really have a career progression right now for this stuff. Uh, and I think in general this space has a lot to learn from user experience. And user experience research. So developer experience, not only is it an emerging field, but also we’re kind of lacking that, uh, information guidance. So again, we don’t have many books about the subject. There’s articles popping up online, there’s products that are coming, coming out and people are starting to make these groupings of products. But I would say to start with, um, you know, engineering experience is great.
Speaker 2 (35:20):
Um, I, I’m noticing a lot of interest from user experience, people to get into developer experience. They’re starting to understand that it’s important, but it’s a challenging role. And the reason is, is that it’s, it’s like a cross disciplinary role and with a lot of these technical roles, especially at API companies that extremely to fill the positions when you need someone who’s a combination technical person and marketer or technical person in sales person or a technical writing is extremely hard to fulfill. So, uh, I think, again, this is going to be really, really difficult because there’s no degree for developer experience and we’re looking for people who are, um, user experience focused with technical background. And that’s difficult. It’s difficult to find those people that the,
Speaker 1 (36:05):
you’re your stereotypical engineer isn’t always the best communicator. And then to also be thinking about usability questions on top of that and being effective and all those, what would be challenging? So
Speaker 2 (36:16):
yeah, you brought up earlier that I was a front end developer which played into the experience, which is true because a lot of friend development becomes close to UX. You know, you’re getting these support tickets that say this doesn’t make any sense to the, to this person. So you’re kind of touching on that UX stuff a little bit. Sometimes you’re in charge of making UX decisions. I think that’s probably where I got my interest in it and I had, why I’ve, I’ve become an expert in it. I’m giving a talk and a couple of weeks that’s like, how do you perform a developer experience research test, right? Because these people like, you know, user experience researchers, I’ve been doing this forever. Right? But developers, I’ve never done that. And they don’t know the language. Right? Um, when I look at proposals, people call stuff all sorts of weird things because no one knows what to call it. But to call it developer research, but you can turn to, you can turn to UX and get those, that information and just apply it to these different, yeah. Yeah. And it’s
Speaker 1 (37:15):
interesting with, with UX and you had mentioned the parallels between developer experience and support. I mean, a developer is a user in the situation where they’re working with an API, they have the, the, the code is using it, but when you’re writing it, that’s, it’s very much that you’re, you’re a customer in a, in a way when you’re interacting.
Speaker 2 (37:35):
Yeah. Yeah. Develop experiences. Just user experience for developers. And I think any of those concepts can be applied. Um, I’ve actually had some discussions with some UX professionals that it’s not even a field that should be named something different. It’s actually the same. Um, but when you try to use the, the, the products and methodology, it doesn’t always apply. Exactly. Right. A UX session happens in a app or a website and no one ever leaves it. And when they’re done, they, they’re, they’ve accomplished some tasks, but development is like hours long. Every developer has a different environment. It’s not a consistent environment like snap and you’ve got this whole technical writing component. These people are creators, they’re not consumers. So there’s a lot, to me, there’s a ton of differences compared to UX, but that doesn’t mean that science can be applied. It’s just that you have to just adjust it a bit. Right. So maybe the test is four hours instead of 30 minutes or, right. And maybe you’re looking at tracking the whole desktop instead of just the, the website or app. The hard part is that the vocabulary is different and the, the interactions are different. The grantees are different that the, none of the products are there and none of the tracking is there. And it’s just a very image, immature space at the moment. Yeah. Cool. That makes it exciting too. It does. There’s a lot of stuff. We’re going to see a lot of cool stuff happening in the future.
Speaker 1 (38:56):
So we’ve been talking about API APIs as products that, uh, outside users or developers would be using this. Is this something that you’re seeing, uh, internally for companies for their own engineering teams?
Speaker 2 (39:08):
Yeah. So the words developer experience are being used often internally to describe what it’s like to be an engineer at a company and whether it’s, like you said, fun essentially. And we’re seeing, uh, you know, the rise of dev ops dev ops recently has become extremely important and, and we’re, we’re talking a lot about automating dev ops and dev ops engineers, things like that. And dev ops is really about supporting engineers so they can get their stuff out faster and they can have a, a smoother work day. So I think that we will see internal developer experience if we don’t already. I think that there’s a big opportunity to, to say like, we have a great developer experience at our company because we use these tools and things are smooth and we document everything we do. I think the opportunities larger for these API companies where they’re talking to customers and that’s where the focus mostly is. But in terms of recruitment and attracting this hard to find talent that it could be a differentiator as well.
Speaker 1 (40:03):
Yeah. That, that’s interesting that we’ve, when we’ve talked about empathy before, a lot of it’s about making the lives of others easier. When you’re thinking about that, documenting this will make it easier for the next person. Thinking about their problems will make it easier for them. And things like dev ops, automation of just smoothing out all of those things that are either time consuming or mundane to slog through is yeah, that’s, that’s developing.
Speaker 2 (40:31):
Yes, exactly. Yeah. And you’ll, you’ll see if you browse any, uh, job boards that there are often user experience roles for internal facing products. So for example, Apple has an application for people who work at Apple stores to ring up, and I guess it’s a POS system for Apple stores. And I came across this job post where you’re essentially a user experience person working on this internal experience. So the Apple employees are happy. And again, drawing that relation to developers. I think it’s the same thing. You know, some of these companies like Google have thousands of engineers, right? They’re all using the same tools. So having someone in charge of making sure that we’re saving those developers time and they’re not getting bogged down or confused is important.
Speaker 1 (41:11):
Right. Yeah. I mean even, yeah, with those really big companies, you could have massive internal APIs that aren’t even what they’re surfacing to their customers.
Speaker 2 (41:20):
Exactly. Yeah. Interesting. Yeah, it’s definitely an internal field as well. I think we’re seeing a large focus on external because that’s a little more scalable I think. But I think user experience probably started there as well. I think these are experienced mostly started externally. Yeah. Yeah, that makes sense. I have a, um, a tweet deck column that searches for developer experience and I always get thrown off a bit because sometimes people are talking about their internal developer tools at their companies or that, you know, this company when I’m working there, they have a better to be like developer experience on my last company and like, are they like, what are these people talking? I’m like, Oh no. It’s the same thing. I just have to remember that it’s not always about API APIs and SDK. Sometimes it’s about like the tools that you make internally
Speaker 1 (42:02):
and it, I mean it could even be what your, your, your experience as a developer can have to do with how work is organized. So you know, when you’re implementing something, whether, you know, you’re, you’re might be consuming an API, but how a problem is presented to you ends up impacting your experience. So sort of in the grandest terms, just thinking about how do we work better?
Speaker 2 (42:27):
Yeah, I think developers would be thrilled to have somebody who was standing in between them and shitty API’s and code even internally, right? Like don’t even toss me this thing because it’s undocumented. I don’t know how to use it. And frankly, I don’t want to be going over to your cubicle or your desk and open office plans and I’m asking you questions all the time about how this thing works. Right? I’d rather it be packaged up nicely and thrown over the fence to me where I can just use it without spending that time communicating. And if you look at API APIs or again, we’re going back to that communication aspect. That’s what this is a family. It’s about scaling communications and information. Um, it’s not really about, I mean it’s about having developers be happier and work faster, but it’s, it’s mostly a communication problem.
Speaker 2 (43:09):
It’s about making sure that developers can communicate with other developers and the machines can communicate with developers that we can all kind of seamlessly interact. Um, I like the Jeff Bezos memo about this cause he, he basically said every internal team cannot message another internal team. You all have to create API APIs for working with each other and that turned into AWS and look where they are. Right. So, um, you know, going back to these other questions about why is it valuable, because you know, these companies have been working on that for like 10 or 20 years and you can see how, what that’s turned into when there’s people really value it. So I think that a lot of these companies are playing catch up to the big, you know, the big public companies. Some of what you were saying about
Speaker 1 (43:56):
chucking it over the fence. I think about like business analysts and the project managers and how they are taking business rules and features and making that into something that can be implemented in our tech leads work to communicate that. And it’s sort of this translation chain, uh, down and where you would be translating an activity in the backside of a product with an API and the documentation. Instead, you’re turning real-world processes into something that can be done
Speaker 2 (44:26):
well, Amanda, and then, yeah.
Speaker 1 (44:27):
Yeah. It’s sort of this long chain of, of language shifting. It’s like big telephone. Yeah, that’s, that’s a great analogy because yeah, so many things get lost on the way and that now you’re filing a support ticket all the way back. Exactly. Yup. Great. Well, thanks for taking the time to be with us, Ian. It’s really exciting to hear how you’re weaving the ideas of empathy that we’ve talked about through your work in the developer experience, sled, exciting stuff. So if you, dear listener, want to learn more about Hacksaw or be a part of the platform, head on over to [inaudible] dot. S H and on the okay human side. Don’t forget to check us out on Spotify and Apple podcasts and elsewhere. You can subscribe, review, and share us with your friends and colleagues. Uh, you can also follow Headspring on Twitter at, at Headspring where you can shoot comments or suggestions our way. We’re always happy for feedback. I’m personally also on Twitter at loud and abrasive, where you can quietly and gently share your opinions and admire photos of birds that I’ve retweeted. Thanks again to our guests, Ian Jennings and our producer, Janine is, I am Patrick media mil and until next time, go peacefully.