Developer Experience Done Right: Proven DX Strategies to Onboard and Retain More Developers - Joshua

Please a round of applause for Joshua Wangu as he comes on stage. Thank you very much.

Hi everyone, good evening or yeah um I'll start with an introduction. My name is Joshua. um a developer relation engineer currently working with high partners uh where we provide de as a service to um literally I'm not supposed to say that but we provide de service to a lot of web tree companies big protocol that you guys know and um yeah that's pretty much about it so this topic is actually meant for developers but for some reasons I missed um they moved my flight so I came in late and that's why we're having it now but yeah I'm going to be talking about how to um get and retain developers. I think it' be really helpful if you put up the slides so they follow through. But yeah, so first thing I have very little time so I'm going to rush through it.

So first thing we're going to talk about what is developer experience and why should you improve it and then lastly how do you do that. All right. So, first uh developer experience is how people feel or the result they're able to get out using your product as developers, right? Uh like I mentioned earlier, this topic is for developers. But yeah, and there reason why there are a few reasons why.

Yeah. All right. Next slide. Next slide. We've passed this.

Next, next. Yeah. This is where I'm at now. All right. So, this is what a typical developer journey looks like for most people.

you have ditches from your discovery phase to the scale phase, right? You have a lot of obstacle they have to go through. But your goal as um a de engineer, even a product builder yourself is to streamline this process and make it as straightforward as possible. Thank you so much. Appreciate.

All right. So, but why why should you even do that? Why do you need to bother to improve developer experience? Right. Um couple of reasons.

Some you can define yourself. But for me, there are three main reasons. First is to attract new developers, right? Then second is to retain and certify existing developers. And thirdly is to meet your KPI so you keep your job.

This is a joke for deer guys. So but now how do we do that? Okay, how do we do that? First thing is that you need to understand your product, right? You need to understand the in and out of your product from the business standpoint to the developer perspective to even like a normal community user.

Let's say your product also have like a userfacing side where nobody needs to write any code. They just come to use the service, right? You also need to understand that part of it like every single aspect of it like deep down like you own the product. Most of the times is usually very important if you're the one that own the product. Then after understanding the product first you need to do there are two things you can do right if you don't have an already existing developer experience let's say it's a brand new project you need to create a persona.

You can't really target everybody. It's very tempting to do but most of the times you figure out that you're just wasting time and resources. So create a persona if you're creating um your developer experience for the first time. Then the next thing you need to do is to audit. If you already have like an existing developer experience, audit the current developer experience that is existing.

See where there are loopholes, things that are meant to be fixed. Then next um this is the current template we use at high partners to audit clients um developer experience or create new ones when want to create. So I can share this with any of you if you need it later. Sorry I'm being very fast. Now moving on next to the solution.

So how do you actually we've talked about why but how do you actually now do this? You've audited or you've created a persona. How do you now improve your developer experience? First thing is to drop your ego. Most of the times developers have this ego.

They try to show that they are really smart. They building one abstractive one very amazing technology and they want to dunk it on other people. They want to dump it on other people. And the truth is that people don't care. Most of you don't know the technology that OPE is built on and you don't absolutely care about it.

Like you're using WhatsApp. we most likely know is a react um they use react on whatever but you actually don't care what they used to build those application and that is what how it should feel in hands of developers any product you're building so first you need to drop your ego build for human beings use everyday terms use everyday user experience then next thing you need to do that just I guess I just look from here straight so next thing you need to do is to abstract anything abstractable I know it's bit of tyology there but yeah you need to really really abstract there's no need for you to um give your developers or users 10 different step on how to just achieve one thing. So you need to abstract everything. Let it be that they just need to take one action and then you help them make API calls behind the scene. Right?

Then the other steps you can follow. You can add code sandbox which is simply a simple to where they just get to test out your product and see how it works in real time before deciding to build on you know of course there is SDK and there are build kits. So they can easily set up and start building whatever product they want to build in minutes. And a very helpful one is to open source example project so they understand what kind of use cases can be built on top of your protocol or your application. Then um here this is a very important one too.

You have to make your article concise right and make your videos very fun and educative. Now attention span is very very little these days. So if you're making videos you need to make them very very interactive very very fun and educative. Then make don't write article like you're submitting thesis for approval in your university. write very very short but um helpful articles.

Right? So the other method the other things you can do by adding feedback button to each of your page on on your documentation site. This has really really improved developer experience for a lot of our clients at um hype. So when you add this you notice that people tend to give you feedback on things you wouldn't even notice things you didn't your eyes couldn't catch. So it's very important to add like feedback button or feedback functionalities on your documentation site.

Then next is to have a dedicated channel for technical discussions. Right? A lot of times you go into communities. Let's say you're trying to build on a particular product. You go into their community and you're trying to ask a question but your question is getting overshadowed by people asking about um TGE and all that.

So you need to have like a dedicated channel where people who are actually building on your product like technical guys can ask question and yes you need to host AMAs or workshop just host have a time for developers where they can bring their question and ask you so they feel connected. Then I think for now last is to recognize uh reward active builders. This goes a long way. It's like you replicating yourself in two different persons because when you recognize active builder what happen is that every single step that you've taken they go on to do it on their own. That's why you see a lot of people make videos about project that they are not affiliated with just because they enjoy working with that project.

They um tend to make videos write article about it and post because they feel rewarded. Those reward can be things as little as just shouting them out on Twitter. You don't necessarily to give them like financial incentive. Then of course another way to improve this for big project is to have create ambassador program right this is where you now have people representing you in different places where you wouldn't normally reach and um yeah what gets measured gets um done. So you need to actually measure each of these strategies uh even the ones that I haven't mentioned here.

Whatever strategy you're using you need to measure them to see what actually works and what does not work. If not, if not, you end up wasting time and effort. So, I think that's it for now. I would like to take any question. Does anyone have any question?

I guess no. Yeah, that's it. Thanks for listening. My name is Judy and I see you guys next time. Thank you.