 Shall I start? Ooh. There's a microphone, and I can hear myself. Hi, everyone. It's very good to see everyone. It's also my first time in Austin, so that's exciting. I know it's been a long day for most of you, so I'll try to make it a little bit light-hearted while at the same time try to talk about very important things. So today, this afternoon, we're going to talk about developer experience and how developer experience can help us conquer the hearts of developers. My name is Ellen Alate. I'm a partner part four, partner. Former partnerships lead at GitHub Education. If you know of GitHub Student Developer Pack, it's a program for students. I salute partnerships for that. I'm also a full-stack open-source software engineer, especially recently I've been doing a lot of cloud-native stuff and Kubernetes, in the past I've worked with APIs and API tooling and building integrations for various things, so writing a lot of YAML but also writing a lot of JavaScript. Over the last couple of years, I've mostly been working in developer relations, so helping companies create powerful, diverse strategies, improve their developer experience, whether that be onboarding or documentation or anything else, and also launch open-source projects if always kind of stuck close to that open-source world. And over the last couple of months, I've been building holographic, also on a sticker page, which is a virtual rewards and incentives platform for developers. So we're going to go through what DevX actually is. I'm going to use DevX, short for developer experience. We'll talk about why it matters, go through some practical examples, how we can use DevX to get developers to fall in love with our products. Some KPIs, there were some interesting discussions in the past talk that I heard, how do we actually measure success of improving or not really improving developer experience, and then go through some of the challenges associated with this stuff. So let's take a trip down memory lane. I think those slides shouldn't have been in that order, but in any case, what's DevX? So it's something that's been more and more a conversation topic in the last few years or so. This is Google Transgraph from the last 10 years. So how exactly did we get here? Well, in 2006 or even 10 years ago, when we wanted to build something, build a responsive, well not just responsive, but interactive webpage, we would just look at the few tools that really were available. Maybe it's vanilla JavaScript, maybe it's jQuery, we pick that, does the job, we use that. These days, when we're making those decisions, the choice looks a little bit more like this. And all of these tools, or most of these tools really that you see on there, solve a very similar problem, right? Like JavaScript helps us build, or front-end JavaScript frameworks help us build interactive web pages in websites. So in order to stand out, it turns out that functionality, just a product or a project solving a problem is no longer enough, because there's a lot of choice. Winston Churchill famously said, democracy is the worst form of government except for all the others that have been tried. Literally any Dev tool says this tool is the best one, and yes, we've tried all the others. They all do a similar thing just in a slightly different way. And then, we don't even need to mention then Kubernetes happens, and we have a bunch of other tools built on top of Kubernetes or for Kubernetes, and that happens with virtually all developer tools. And so what begins to matter, or rather what it's no longer all about is it's not just about product market fit, not about tool solving a problem, but more of a product user fit. And in our case, it's more of a product developer fit. Developers have an increasing say in their teams and what we'll be working on, but also what tools they're going to adopt. So that's where developer experience comes in, and I like to think of it as that specifically the product user fit. The better your product user fit is, the better your developer experience is for your user. So developer experience describes how developers feel while using or working on your product. And our goal is to build products and not only solve those workflow problems at hand, but they also fit developers' lifestyle or style of work, really, and pace of work. Why does it matter? If we look at these boxes left to right, that's sort of the ideal flow, or the ideal chain. If we manage to improve our developer experience and our developer satisfaction, we feel good about using those tools because the tools get them. They're probably built by programmers for programmers. It just feels good. It's nice. You kind of get in the flow. Then that leads to organic growth. So developers evangelize good products to their teams and their peers to discuss them on the internet at conferences. Maybe they just recommend some tool in passing because they read a cool blog post about it, which then leads to higher adoption based on those positive reviews. So even more people choose the product, and that leads to quality software because the more people and projects and companies depend on software, the more feedback that company or the project gets, more contributions, that attracts talent because the project seems a bit more recognized. It's also kind of cool to work on things that you like. And ultimately that just creates this love chain from developers and by developers leading to thriving communities and an ideal world that looks something like this, where this is HDPI specifically I've used to work with them, where folks just talk about your product because it's so cool because it just gets them. So what does it look like in practice? What can we do or which areas of products or projects should we look at to implement some of it? Well the first one is SEO, and ironically in the last Stack Overflow developer survey, I think the last published one is the 2021 one, it revealed that 89.69% of developers turned to Google search first when faced with a problem, whether that be picking a specific tool to solve a problem or a specific query about a tool. That is more than Stack Overflow. I don't know whether Stack Overflow included how many of those Google queries where how do I use Next from Stack Overflow or something. And having your products be SEO optimized really does two things. One, it does help solve concrete problems, which is great because that's what we're looking for. But secondly, it also signals that there are other people using these products or using those tools. And that signal is important because it's also fellow developers essentially talking about those tools. So they must be legit. I mean, to just illustrate as an example, by SEO matters, she have hands how many people have ever looked at them documentation, or does it look something more like this? Right, so how to quit. That's a very SEO optimized tool. Secondly, given that this is an open source setting especially, we need to talk about GitHub and how the GitHub repo looks. So what we're looking for really, or what developers are looking for, is a tool that projects and that signals essentially confidence. And it also inspires confidence in developers. So when it comes to housekeeping, GitHub repo is your landing page and first impressions really matter. So making the project look that it is regularly maintained, it is regularly updated, issues are attended to, et cetera, helps create that impression and attract users and make them feel good about using your product. And at the same time, when speaking about contributors, it's useful to help your users help you. So this is something that I found that a lot of new projects face, where they get maybe their first contributors, and they're not exactly sure what they're doing. And people who are reviewing those, who requested those issues, also don't quite know what they're doing, who should be doing this, et cetera, et cetera. So utilizing GitHub to its very maximum comes in quite handy. Using templates as much as possible, whether that be issue templates or PR templates, that just creates less room for error and frustration and also acts as a guide what developers can work on and what contributors can do. Because not every contribution has to be like a full-blown feature request, right? So here's Backstage, which is a project that's backed by Spotify, which I like to use as an example. They've really got their GitHub repo figured out. So this is what their issue templates look like. So you want to do something or you want to work on something. I mean, you can go through the contributing guides, but this is also super helpful. So this kind of guides your flow. This is what the reading looks like. It's nice because it almost, the nice thing about the Backstage reading is that it describes what the product is and what workflow problems it solves and its features and has all the links to the documentation just right down below. Some tools like to include maybe their entire documentation, their entire contributing history or guides within the reading. But what we really want to do is we want to show that the tool is easy to use and to contribute to. So the reason I wanted to show this one is on the releases, basically the right-hand side, you can notice that they've filled out the sectors that need to be filled out, essentially, which is good. Because then people are like, OK, this is maintained. People are using this. I'm going to give it a try. One of the biggest things, in general, in developer experience, is the features. Ideally, we want to spend more time building cool features and helping people to use the product than have people essentially read the documentation over and over again. So first bit, standards are king. So if you're using an existing technology, don't reinvent the wheel. We have, for example, open API specification that can be used as guidance when you're building an API for your product or your tool, which is helpful because then folks who are using your API and probably other APIs already know what it's like and can integrate that easily. If you're building a new technology and there are no standards yet, create the standards. Help developers help themselves. Something that's fully customizable, especially if it's a new product, it's not necessarily a selling point. It just signals that there's going to be some work because I will need to figure out how exactly do I do if everything is fully customizable and there are not really any defaults, et cetera, et cetera. If a door sign says pull, will you keep pushing it? It's not you. It's the door that's badly designed. So it's the same with features, really. If people keep asking the same questions again, sometimes it's worth thinking, OK, but we've answered those questions. We've even written an entire section of documentation about this, but people are still asking those questions. Surely we should take a step back and think about it a little bit more. And lastly, which is very, not necessarily very... No, never mind, yes. So when it comes to errors, don't admit your errors, explain them also. Developers spend up to 10 times more time debugging than they do actually building. So if you can reduce the burden of that process, you can really, really help their life. So an example of that last bit would be all two really familiar lines to all of us, which is whenever you try to push something to a new repo, GitHub, or I don't know if it's a Git or a GitHub feature, I should really know. I want to say it's a good feature. It says, OK, well, this is the command that you probably meant to run because you're pushing it for the first time and it's your local branch, it doesn't exist there. So there's an error, but it immediately kind of tells you, is this what you meant? Is this something that you intended to do? And this is how you fix it. On-boarding, nothing feels the vibe quicker than a schedule a call for a quick demo. This is very enterprise specific, but when we're thinking about developers and we're thinking about engineers, they're self-starters, they enjoy tinkering and doing things on their own and trying things by themselves and getting that little dopamine rush when you get something working and see something on the screen. The reason why Hello World is such a powerful thing, really, when it comes to programming languages, this is Alert Hello World, which does this, really, so it makes the annoying pop-ups on your browser, which some websites abuse it. But it's perfect not because it's just a one-liner, it's perfect because you can see the result on your screen right there and then in production. It's not like some fake terminal that you're using or you're watching a YouTube video, it's there and then, it's you. So an example of that, actually, is Keef Cross. I've worked with Keef Cross, so full disclosure there, but the, oh, it was there. Not all tools, obviously, can have a one-liner, one-liner, Hello World. But in case of a more complicated tool, if you look at the installation instructions here, it's essentially copying one, two, three, yes, three lines, and then the fourth one, when you navigate to that link, gives you an entire dashboard. So it's a very quick way to get a developer not only to test your product, but also feel good about themselves that, oh, okay, I managed to actually get something on the screen enough and running, and do it very quickly. So if you're onboarding, or rather, if your installation, or Hello World, takes a long list of prerequisites, and then super long installation instructions, it's worth spending some time there and check whether that's really the Hello World. And then lastly, I wanna talk about documentation a little bit, so something that's focused, that developer experience folks, and DevRels, I think, focus a lot, when, yeah, this is just something that people focus a lot in developers read. So there are two things really that you can mind here. One is the balance between the theoretical and practical content. So the origin and inspiration behind Rye Flour could be interesting when you're looking up a recipe, could be very interesting, but often we just wanna see the method for the recipe. We just wanna copy the code and we wanna run it. If we want someone to tell us exactly what to do, how to do it, and maybe periodically check in and see, okay, this is what the dough should look like at this stage. So practical content, or code snippets, and hands-on exercises, showing things by example, or screenshots if your product's more visual, is satisfying to work with. And then use case versus feature-based documentation, especially when documentation, I think, is written by maintainers or creators of the project, it's very tempting to just start thinking about it in the same way that the architecture, what the architecture of the project is, which isn't necessarily how people use it. So having a combination of both, or maybe at the beginning, even more use case-based documentation is a good chat since people enjoy working and learning from example. It's also a good way to, especially if it's maintainers, writing the documentation to learn more about their users without necessarily talking to their users at that point. So getting started guides, tutorials, and use case documents help developers understand how the tool fits in within their existing workflows. An example that I like to use is Twilio. So Twilio have been, I don't know if anyone's from Shilio here, but they have been excellent at documentation for a very long time, content also, but documentation is put on. And precisely because of that, can you see, oh yes, you can see my cursor, excellent. Because of that combination of this is the bit that's really important to you if you're gonna dig really deep into page open. Okay, making an HTTP request, let's say, sure. But at the same time, they have a lot of getting started guides and also just very concrete solutions to very concrete problems. One thing to keep in mind is that this is a bit difficult to maintain if your API changes, for instance, you do have to go back and rewrite a lot of those smaller, getting started guides or bigger ones also. But that's what standards are for, right? So Twilio or Vineers and APIs, it's unlikely that their API would change significantly. But that's content that's appreciated. Oh, cool. So we've seen some of the examples, what we can do, what sort of mindset we have to be in to think about what makes developers happy. How can we actually measure that? It's hard to measure it. But these are some of the suggestions that you can use. And normally to measure developer experience, they're a combination of community engagement metrics, then also more like marketing metrics, some of the bad data metrics, so numbers and clicks on things, but also very product and almost company-wide ones. So time to hello world. I've added a star there because it can also be time to pull requests or time to contribution, depending on what type of developer you're working on. That's important, right? Developers want to be able to get their first result as soon as possible or get some sort of feedback, whether they're going in the right direction or the wrong direction immediately. So to do some user testing and basically calculate how long it takes them to get from one point to another can be useful measurement. Another one is Net Promoter Score. This is more from products or from product, really. So Net Promoter Score, there really should be a trademark on there. Oh, God, this talk is going on the line. I'm sorry, NPS people, but basically once someone asks you how likely are you to recommend this product to your friends, that's the Net Promoter Score. A lot of companies ask it in a slightly different way because it's trademarked, but that's also something that can be used. The challenge with that is, I mean, to get a developer to complete a survey or any person really is a lot of trouble and so the data can be unbalanced or skewed or it will be the biggest haters or the largest supporters who complete those surveys. There would be community engagement. So there was some conversations about orbit. That's one of the tools that can be used. So, folks, what are they coming to you for? How many of them are talking about you online and prompted posting questions, participating in forums, et cetera, et cetera. And your own recognition. Internal surveys, so we're quite lucky to be working in a field where we're building tools and projects for people who literally are like us. So we have that benefit that we don't necessarily have to go and do a field study. We can just ask our folks internally and do some so-called Starbucks testing, which is just observing them using tools and noticing their frustrations. Churn rate, so drop off, essentially, which also comes more probably from product, but that's something to measure if a developer's going to enjoy using the tool, they're probably going to stick with it, maybe propose even features, do some more community engagement. And then SEO benchmarking. So with here, yeah, essentially, seeing how particular keywords relate to your product and measuring the improvement of that and the problems. So, what are the challenges of developer experience if it doesn't seem hard enough yet? Well, there really are three top problems. One is that it takes time. A lot of it is research, a lot of it is experiments. If you need to implement each of those, it takes time. It is not uncommon that developer experience teams take a good year to set up before the first results are seen, essentially. Secondly, it's unclear return on investment. So, because measuring success is a little bit of an issue, or rather, we don't necessarily know what exactly to measure, it's hard to convince your managers or convince your investors that this is something that we need a team for but this is something that we need to put resources in. But then, if we do, especially now, there's a big community developer experience, developer relations push, there's a skill shortage. So, either upskilling your existing folks to work on that side of things or hiring developer experience experts. Yeah, that's it. Thank you. So, community engagement metrics, have you ever used orbit? Okay. So, it's really a combination of things. It's essentially how many and how and what type of people are participating in the same spaces that you are. So, when you have your own products community or your own, for example, open source projects community, it's a bit clearer there because you can measure how many people are starring your project, how many people are creating or liking or otherwise interacting with issues or opening pull requests. If you do happen to have, let's say a Slack workspace, maybe it's how many folks joined that, how many stay around, et cetera, et cetera. Then also, there's an element of evangelism. So, how people talk about you to others. So, to measure that, you can use, I've used something called mention.com in the past where it just tracks who and how and then what people are saying about you. So, the ideal, let's say a situation there is that if you are the owner of the Vim project, it's not you who's writing the answers for how to equip them. It's sort of people who are helping each other that's sort of like the North Star. They don't have to ever interact with you. You don't have to have like a space but the point is that there's this implicit group of people. A small group of really active community members versus a larger group that are maybe a little bit less engaged. In either work or do you try to... The things, this is just from experience really and things I've observed and yeah, the super supporters or the super fans. There's a book called, there's a book, oh god, who is it by? Maybe they're even, she's definitely here, oh no, maybe not in this room. The Business Value of Developer Relations, the author, it's at the time of my time. Yeah, there's a notion of super fans and those are essentially going to be the people who talk about you and from what the GitHub state of the Octaverse service say and from what Stack Overflow service say, it seems that developers seem to adopt tools really because others are recommending. So if someone seems or is really loud enough to evangelize your product, then that's probably the person that you should focus on. With quantity, it's a bit difficult. When you really think about it, there aren't that many individual product communities realistically as a person, how many communities can you be part of? But as a product, what you can do also and where quantity matters is contribute to a lot of the existing ones. So when it comes to cloud native or API developers or JavaScript or React or anything there, yeah, I think there was a bit of a wishy-washy answer, but generally super supporters are the way to go. The Business Value of Developer Relations, I want to say that I saw the author in the attendee list. Yes. I think it's almost like a different category. It's almost like a discussion topic. So I think events like this are more important for other DevRel folks, other developer experience folks and maintainers, et cetera. Then they probably are for developers themselves. I think that echoes and that resonates back into the communities, into the user bases. But it's more that. So the importance, I think it's super important because it is essentially skill sharing. It is experience sharing and discussion and then talking about it. Probably not so much doing cross-reference with a bit of a field study. I think that's what I would suggest. Well, when it comes to internal, how internal experience is reflective of customers or users using the product? If I answer that, is that, sorry. No, sorry, would that be a good start? Yeah, yeah. So, to assigning weights to that, I think that's something very much for each company or each project really to figure out. One thing to look at would be, are those developers who are working on that project also a consumer of that project? Like, if you think about something like, I'm gonna use GitHub, maybe that's not a great example, right? But let's, backstage specifically, I think it's also a tool that they use internally. So there are different teams, essentially, who work and develop that tool versus who consume it. So you probably would want to go to the folks who are consuming it rather than using it, if that makes sense. I think it becomes more difficult if, let's say, just trying to think of a... Are you gonna be a friend of others? No, no, no, no, no, no. But that's a really, really great question. Yeah, it's a lot easier. If you were an API testing company, an API, or you're a company that builds APIs and the developers happen to be, let's say, full-sac or front-end cleaning engineers, they're gonna be consumers of that product. So surely, that's a good benchmark there. It gets difficult when the, yeah, when, I don't know, it's a dashboard for something that's super low-level. Like, that's just gonna be a different one. Yeah, sorry. Yes, so it's sort of what, also I don't want to turn this into a pitch, but yeah, I think that can work, and it does work extremely well with guiding developers to do certain actions that they otherwise wouldn't. So if you think about, well, a good example would actually be OpenShift. I can think of one that, when you use it, it has sort of guides on screen, which bits you could click on, and then at some point, there is an interaction, or almost like a rewarding thing that says, you know, you've done this, or this is cool to check out some other spots. It comes extremely handy also in things like learn modules. I know some companies have just launched some. So essentially almost having developers are incentivizing to complete and look at maybe the documentation, or look at certain things before they go ahead and ask the question. I think it's extremely, it also works well, and from what we've seen really from things like Stack Overflow and GitHub, you feel more confident asking a question when there's like upvotes involved, right? Like that's the potential there also. I think it's both. Once for yourself, once for yourself, right? Like if we look at developer laptops, and if we look at the stickers on those laptops, they're there for two reasons. One is because you collect them, and it's like a nice thing, right? It's a stamp of, I've done this thing, and maybe I've learned this thing, or won this hackathon, or like participated somewhere. But another one is that it is a conversation starter. It's GitHub commits the green boxes. They stay there, which is nice. We don't hide them, even if they come from private repos. No, no one just hides. I think we're out of time, so I'm gonna just wrap up here.