 Welcome. So this is the last talk of today. I hope you enjoyed the morning talks. So I just want to start by telling you a story about an experience, not about developer experience. This is simply a user experience. This is back in eight years in Berlin. I was traveling with this ticket and I got caught by a cop. But I was carrying that this ticket. Do you know what is the reason? What is the radius fair? But there is nowhere it's mentioned. It's children. Yeah, I was like, my understanding was when I'm new to Berlin first time, there is no information that it's for kids. And I traveled with this ticket for a couple of times. Just two stations are short distance. Not for the long one. I traveled and I was like, okay. But I got to know when cop caught me that hey, you're traveling with a kid's ticket. And this is a kind of experience we see every day here and there. And then I'm going to talk about a developer experience and also how community can play a crucial role in impacting the developer experience. I'm going to share you the five techniques which I learned from my recent roles and projects so that you can take that. And next week you can apply in your day job. And also if you have any feedback, let me know. I'm happy to discuss. And there's another example, another nice example. During the COVID time in the train stations, they were giving you like, what is a 1.5 meter distance? It's an equivalent of like a horse. How about this? This is so cool, right? Like in order to give you 1.5 meters, it is how it is the distance you need to maintain. I really like this one. Yeah, elephant as well. And I also want you to do like a quick look into your morning until now. Can you think about your experience at this conference? Maybe just share with your neighbor. Like just for 10, 15 seconds. What was your biggest takeaway? Yeah, just talk to your neighbors. This is a community talk. So it's important that we talk to each other and help. And what are your biggest takeaway? Like what are your positives, what are negatives? Thank you. Thank you for sharing your experience. And for me, for me, it's a great organization. Great organization. And if you look at when you enter, there's a sign votes. And there's also information where to get Wi-Fi information. All this information, like where's the check-in is without noticing it's helping you. And also I had a problem today, like 30 minutes ago. The volunteer's organization team is helping me to figure out the Wi-Fi. So good. Thank you very much for the organizing team. How cool is this? I really like this. This is a great experience. You don't know if you have seen it, or not. This is a great experience. And also I had a great community event today. Thanks, Buriana, for organizing this. We had a great localization community in Bruno. And we had to talk a lot of really nice conversation. We got to exchange a lot of great ideas. That's a power of community. And a little bit about this DevCon organization, the committee itself. How cool is that? Supporting speakers. I really felt that they're really supporting. I really felt like being like I could also contribute. This is a great, great, great initiative. And I've not seen, I've spoken to many conference. I've not seen this. Maybe there might be supporting something like this. This is great. And also if you have seen the app, you can also see who is attending. And you can also see what their background is, like what my talk should be. And also I can also add presentations. And I can basically interact with the audience, interact with the community. So this is a great, great platform. And I felt like this was really great. And also you could give a feedback. Is my talk is bad or good? What can I improve? So this way I can also improve. And this is for community effort. And this is for community effort. And I'm also going to share, like I said before, my recent projects at Localize, Contentful, and Commerce Tools. I'm going to share a couple of stories and how I approached and how community helped me. And I'm from Berlin. I'm currently based in Berlin since 2015. I ran several meet-ups, including design and front-end development-related communities. There's a saying in Berlin. If you are in Berlin, you don't go to a restaurant for dinner. You go to a meet-up. We have meet-up pretty much for everything. Every tech thing you take, every front-end frameworks, design, marketing, product development, we have meet-ups for everything. So there's such a great community place. And I learned a lot by organizing and running workshops. How many of you think user experience is same as developer experience? Okay. So good that not many. So let's take a look. I applied user experience techniques into improve the developer tools to improve the developer experience. I straightaway applied what happens, like, for example, I was building a design system, a UI components to build some UI applications for Contentful. We have a framework called Format 36. It's just a UI blocks. You can think about, like, a Lego blocks to build some UI. And as a product manager, I had a lot of backlog of items to work on, like, improving the documentation, improving our components. We had a bunch of items. But these information was based on my user interviews. I talked to a lot of our customers. I also talked to a lot of our community developers. I asked, like, hey, what are the components? What are you struggling with? I got a set of feedback. But we also have a community Slack channel at Contentful where I started answering the questions. I started understanding what are the problems they are struggling with, building this UI application. I started helping them. I just started answering them. I started helping them. And slowly, I also felt like what I had the user interviews, what I got the insights was totally different from what are the interactions and insights I learned from this community interaction. I felt like if you just ask your users or your developer, they're just going to say, just like Andrew Ford, they're going to say, they're going to ask for forced horses. You're not going to get truly what you need. And this is a great quote from Amy from Sales Safari. If you want to know what a person really values, what they really suffer, what they really do, don't listen to their words. Observe their actions. I literally followed this. And if you ask me how I did, since I was answering a lot of questions on Slack channel, I started slowly building a trust among those community developers. And they were starting reaching out to me in a direct message on Slack. And for me, it was very easy like, hey, I'm working on something. I would like to do a pair programming with you. Let's build this together. I want to see what is your environment look like. How do you approach? Do you look into documentation? What is your code ID? ID Editor looks like it gave me a lot of insights, which I didn't get during the user interviews. And one of the best insight I got was TypeScript. And we were supporting the TypeScript in the UI application. And what I noticed from our community developers is never looking into documentation. For M, the documentation was types in the code editor itself. And you could able to understand what are arguments, what is the argument types. And I never seen him looking into documentation. But our backlog was full of improving the documentation, improving adding new components. But after this, we changed our strategy to make, also include, the types should be top quality so that developers can get their job done easily. And another was just an analogy. What we think as a user experience is, we just want to deliver a burger. Like, hey, as a customer, you want to deliver what I ask. But actually, a developer is, they don't want a burger, but they want a meal. And also, you need to get a proper instruction how to prepare your meal. And also, during that preparation, they also go through a lot of trouble step-by-step guide, and there's going to be a lot of troubleshooting involved. And this is why my analogy developer experience is not same as user experience. User experience is for consumers. I just have a restaurant analogy. Like, you had a restaurant, you are sitting on the table, and you order, you get, that's like a burger, what do you get it right? Whereas developer experience is for makers. Developers are makers. Developers are builders. They want to build things. They want to customize things. They don't just want to have a burger. They want to customize that. So that's why the tools you provide to developers, the way they interact is different from the techniques you apply to the user experience. And I saw the same example at Commerce Tools, building the UIKit, another design system for our customers. And I also did a pair programming sessions with our solution engineer. This is about internal community. I'm going to talk about why it's very important to build internal community first and how you can get a lot of benefits from internal community. And moving on to all this, okay, we understood. There's a user experience and developer experience. Okay, but how can I look, how can I improve the developer experience? How many of you know what is jobs to be done? A framework, jobs to be done framework? Okay, one hand. Okay, so I can give you a quick look. Example, people don't want your quarter inch drill. They want a quarter inch hole. So they just want to get their job done. They don't care whatever the tool they use. They want to get their job done. To understand what it is, I have a couple of examples. For example, 20 years ago, if I want to buy a train ticket, I would just go in a physical store. I just have to stand and get... Today, I don't have to do it. I can just get it from the mobile app. Same job, train ticket, purchasing a train ticket. The way I can get it done, I can sit it at my home. I can do it here. It's much faster. The tools will change, and it remains the same. So the new tools will make your job getting things much faster. Another example, Netflix. Netflix, when they started, they were selling CDs, but now nobody is going to watch with the CDs. Everybody watched with their mobile phone or a desktop or their computer. Still, you're watching the movies, but the way you watch the movie is using the tool list as changed. How about for coding? Another example, you being a developer, now you have a co-pilot, for example. This is just an example. Co-pilot can help you as a companion to get your job done easy, but still your job is to build a useful software. Another example, AI example. There's a documentation site where you can do a search. What is there in your documentation? But here is the README documentation where with AI, it can also help you what you wanted to do, what are the steps, it can be more advanced, it can understand you what you're trying to achieve, and it can provide you more details. And for example, Stripe did with a chat GPT. They have a documentation experiment where you can ask something and it can give you more detailed, concrete example what you have to get it done in a much faster way. And this is another example. Since we are talking about community, this is at airport. This is at before COVID, before corona. They were asking me near the restrooms, how was your experience? But now they're clever. After COVID, you can just scan it and just share your feedback or concerns. Still the same job, feedback, but doing it in differently. So think about how you can enhance developer experience with the tools you're building, how their job, the fundamental job can be done in a better way. And there are a few examples. For example, this is from Xeta. Xeta provides you a query database and it gives you TypeScript and JavaScript code and you as a developer don't have to write this and depending on what query you want to perform, it gives you a code, you just have to copy paste this. So getting the same job done much faster because you have the code snippet, it's easy to consume this data. And looking into the interface, compared to the user interface, there are some interface we need to consider when we are building it for developers, that is, of course the code editors, command line, APIs, SDKs, and documentation. And also while thinking about all these interface, there will be a troubleshooting. There could be errors. And this is a typical journey of a developer consuming your tool, your product, right, getting started, reading docs, trying to use your tool. But there could be some troubleshooting. There could be some issues. How are you going to provide those parts? Make it easy for them. And this is a great example from Cypress. For example, if I get an end-to-end automation tool for UI automation, where there is an issue, if there is an issue, they also provide you how to fix it. This is a great way. This is a great way you can help your customers if you're just building some great developer tools. And you can see here, this is where the documentation that goes, details what's the problem, how to fix it. So making their life easier to fix these issues. Another viewpoint, before we go into community part, developer efficiency. What is developer efficiency? Let's take a simple example. As a developer, I'm building a some UI application. How quickly I can make changes on my editor, and how quickly I can see the changes in the UI. The faster I can see the changes, the higher the efficiency is. Let's say if I'm working on a monolithic application, I make some changes. It takes one or two minutes to build and deploy and show the local preview. Then it's a low efficiency. Similarly, if you're working on a unit test, if it gives you an instant feedback, that's a high efficiency. If it takes some minutes, it's a low efficiency. So think about, I just talked about only those two examples, but we are talking about validating changes on local environment, validating and following some standards, security standards, and deploying and sending it to production. High efficiency environment is where your tool is efficient, making the life easy for developers to build faster. At the end of the day, you're able to help them to get their job done much quicker. And always aim for using your tool. Your tool should be aimed to get your eye-efficient environment. And there are more details about what are the low effectiveness and high effectiveness. And the last part of this talk where how can we improve developer experience by community? We talked, we understood what is user experience, what is developer experience, but now how this talk community is going to play and help you. The first point is how open are you to get a feedback? Are you ready to get a feedback? If not, then your users will just ignore and go. If you're not ready to listen to feedback or if your system is not ready to accept feedback, they just struggle in the middle and they go, you never get the feedback. But what are some of the examples you can try? For example, this is from Next.js documentation, and you as a user, you can just enter your email and you can just give you a feedback and previously the email also was optional. You can just send them the feedback. And we did a similar thing at Localize. We have the developer portal and I created a simple Google form. I replicated the same thing, an optional email field and also what's the problem. You know what? So much of feedback I get every once in a month. It is so much of useful. That way our documentation is up to date. So first tip is open for feedback. Do you have forms? Do you say you're ready to hear feedback? Opening up where your customers will be more place. So that's one point. And second, very, very, very important point. If you take one, take away from my talk is this one. Provide value to community before expecting returns. What I mean by this, let's say, let's take this example. This is a tour guide who kind of explains and provides value, show all the historical moment. And at the end of the tour, you're going to give them tips based on how happy with that guide. Similarly, what I've seen is a lot of product managers, including me, before I have a Slack community, I straight away reach out to those who ask questions. Those who have problems, hey, I'm working on a new project. I would like to get a feedback. Do you want to be a beta tester? No, they will not come. How are you expecting you to come and help you? Because it's not their problem. It's your problem. I don't have any credibility. I don't have any trust to them. How can you expect them to help you? So the big lesson I learned is build trust. How can I build trust? By helping them. By helping their problem. Trying to help their problem. And also recognize community contribution. This is a great example from Contentful, Format 36 Open Source Repository. Even if I do a small documentation contribution, or even open a bug and suggest a fix, my picture and what type of contribution will be listed here. This is a great way to recognize them and hey, I contributed to this project. I can really feel good thing about it. So recognizing community contribution is another thing you can definitely do. And as I was explaining the point of building a trust, it's not going to happen in a couple of days or even a couple of hours. It might take a couple of months, but it's very fundamental in order to get a valuable community, a feedback for your product. And this is also another very interesting pyramid. One percent of your pyramid is you can expect as a contributor. Let's say I have thousand community members. You can expect at least around 10 people might be your true contributors or champions. They would like to contribute. And nine percent of those contributors are, they might comment, they might add, they might read, and they might, hey, this could be better. Let's say we have a Slack channel, Slack group, and one percent of the passionate champions are talking about your open source tool and challenges, and nine percent of them might be commenting or interacting or like and sharing. So the remaining 90 percent of your community is just observing and don't expect them to be kind of like interacting, but they're just consuming the content. It applies the same thing for even social media. Only one person will be sharing the content regularly. Around nine percent will be interacting, and 90 percent they just consume, they just scroll. And you can also learn interesting tactics from social media influencers. If you have seen social media influencers, they always know the pattern, hey, please let me know in the comment section. Please let me know what you think. These comments, these feedback from the community is actually helping them to prepare what is my next big content I need to create. Same thing I've seen. People are using the LinkedIn polls to collect what is my next topic I should write for. It's, again, getting the ideas from community and prioritizing what they should focus on. And this one percent, what you see here, it's very important you identify who are those one percent of your contributors are. And it's important you reward them. Of course, we, as developers, we love swags. We love conference swags. We love these open source tool swags. And it's up to you to identify those one percent contributors and reward them based on type of contribution they are doing. And you can go one step further if you have more time, and if you wanted to do more in a systematic way, like Balsamic, for example, they have a customer advisory board where you can list down and you can expect, come up with a plan, what is best way they can contribute to your roadmap, and also what those, your community contributor is going to get based on their contribution. And there are some ambassador programs from various developer tools where you can clearly mention what are the benefits they're going to get, so that way you're rewarding your one percent community contributors and also inspiring them so that they can create more such content and contribute. And once you have, okay, I'm going to wrap it up, once you have two more points, once we have those one percent contributors and you have a trust, then you have a chance to go deep dive user testing session with community developers. That's where you can go, do a peer programming session, you can go even more than one hour and understand, build something together with your community, and you understand the pain points, where they're getting stuck, what you can improve, and also asking them to think aloud also helps you to kind of get you learn which you'll not get it from just from user interviews by talking. And another tip I can give you is sharing observation. Along with you, it would also be great if you can also go with your product manager and your designer, they can be a passive observer. That way you can speed up getting feedback and you can align and you don't have to discuss and argue, hey, I don't agree, but if they are observing, they also agree and the feedback and conclusion will be much faster. And this is what I try to explain, that we all have different views, but once we attend these peer programming sessions, we start to feel that, yes, that's pain is real and we all have after the peer programming session, all the team members agree that the problem exists, we need to fix this. And I can recommend these two books. If you wanted to do the user testing and peer programming session, which gives you more about how to do that and also what questions you need to ask, more open-ended questions. And I use automation tools like Calendly and Zoom. Zoom works perfectly well for me because as soon as somebody books a user testing session, I get a Zoom link and email schedule. So it works perfectly and I can also record and watch it later for research purpose. And another tip is this is a great place. The physical events are a great place to get a feedback. This is where you can find developers and if you're hosting, if you're sponsoring any of this event, and this is where you can talk to your developers and ask for feedback. For example, Auth0 did a Dev Day event. They're running the user testing of their website in the event itself. So this is a great place to find a lot of developers. I highly recommend if you're sponsoring any event, utilize that opportunity so you can meet a lot of developers. An internal community, I would try to wrap it up. This is another very important tip, dog footing, which is start using our tools built by product companies in the company itself. And, oh, I don't have time, but I would like to show this. This is a great advice from Kelsey about Kubernetes, how you give Kubernetes core engineers to install the Kubernetes on their system, how they struggle, and how they improve the Kubernetes later. Friction log technique is if anybody joins your company who has a fresh mindset, they can log all the good and bad experience about using your product. And this technique is used by Stripe. And that way you know where the pain is, where people are struggling, because those new joiners and new developers have a fresh perspective, where you as a developer who's building a product might miss that fresh perspective. And I use it for marketing because I work at a marketing team at Localize, where I also, if I want to send an email to a developer audience, I do a very quick test with our internal engineers. It doesn't have to be 30 minutes. It can be just five minutes or 10 minutes session. And I just ask, like, hey, what are you expecting from this email? What do you understand? And we can also improve and make the email shorter and also make it more developer-focused. And with that, I will conclude my talk. So here are my takeaways for you. Open for your feedback. Find out the channels where you can get a feedback. Always ask for feedback. Slack community always tell that we are here looking for feedback if you have any feedback. And also, some of the companies even go one step further. They put your calendar link where you can book a call. A community member can book a call and talk to you. And provide value to your community members before you expecting them return. Always solve their challenges. Build a trust. And once you have a trust, go deep-dive user testing sessions. That way, you can understand their pain points. And participate in-person events and talk to a lot of developers. And this is a great chance to get a lot of feedback if you have a sponsoring the event and get your feedback for your tool. And in terms of internal community, do the dog footing. Use your internal engineering resources. Friction log techniques. If new developers are joining your company, that's a great way to get a lot of feedback for your product because they will be viewing it from a fresh perspective. And do a lot of quick user testing with your developers itself if you are doing any developer-related improvements. Because starting with internal community is much easier than looking for developers from outside, from community. Because it takes time. Building trust takes time. But you can start today by talking to your internal community, building internal community of developers. With that, I'm going to finish my talk. Thank you very much. If we have time, I can take a couple of questions. Any questions? Thank you very much.