 Hello, everyone, and welcome back to the Octa Developer Octa Towers. And I wanted to introduce you to somebody who's going to talk about this subject right here, what it's like to build a .NET SDK. And I have somebody who's built our own .NET SDK here at Octa. And that is Ms. Laura Rodriguez. Thank you so much for joining us. Thank you, Heather. Thank you, everyone. Thanks for having me here today. Now, I would like you to give a little bit of information on your background kind of as an introduction so people know who you are and how you came to be here. Yeah, so I've been with Octa for three years now working as a .NET SDK engineer. But I have been a software developer for more than 10 years at the beginning building web applications for different customers in different languages. But here at Octa, I'm focused primarily on building the .NET SDKs. Right, right. And I figured you'd be the perfect person because we get questions all the time about the differences. So I know that I started in .NET with just doing some real basic applications. I built some APIs later. And but it is a kind of a different role, right, to suddenly go from building a website to something like this that is installable or usable stuff like that. So our first question is, what is it like to move from building applications to building an SDK? Yeah, this is a great question because you can think about, well, it's all about coding, right? But it's not because your customers are totally different type of people, right? On one side for applications, you usually have customers that they only worry about the final product. And as soon as they have the functionality they want, it doesn't matter the changes you do in the back end. If you do breaking changes, if you handle errors differently, if you have tech dab, if you don't have documentation, it doesn't matter. But when your customer, like it's another developer, you have to pay attention to all the things. You can't make changes all the time you want. And you need to be super careful about any new features you introduce, how you document that. And of course, breaking changes. I think one is, yeah, that's the most important thing that you need to keep in mind. I think we're all allergic to breaking changes. Oh my god, yeah, yeah, for sure. And it was, was your workload different? Was it still coding the same in .NET? Was it just what it was wrapped in? Well, it's different because in the past, when I was building applications, I had to focus not only on the back end side, but also like in the front end, right? I was like a more like a full stack developer, right? And I had to work with designers, UX people, the customer, and the interactions are different, right? Because you need to use the proper language, which it's not always super technical, right? With all these stakeholders to build the application they want. But when building an SDK, you talk to other developers in the language, like the language you know, right? And it can be very technical, so you can be super specific. And we can basically talk about different technical problems. And we are all about, we are all on the same page when discussing these these type of challenges. I mean, they do very technical actually to do those dives, right? Because you're running into a lot more technical verbiage, like you mentioned. Yeah, for sure. Yeah, for sure. And now when building SDKs, yeah, your conversations, our discussions are mostly technical, right? Mostly back end stuff and APIs and errors and those kind of things. Yeah. Absolutely. But I missed building applications. To consume your SDK, you mean? Yeah, exactly. Yeah, yeah, yeah, yeah. So maybe your samples are like one of your favorite, more favorite parts? Yeah, that's what, you know, that's what I love building sample applications. Because it reminds me to those times when I was a full stack developer, and I had to deal with all those kind of things. And also I use myself as like a tester of my own SDK. So usually it's when I build my sample applications, I discover features that I would like to implement or things that I don't like so much. And then I just put an issue on my backlog to try to handle that in the future. But yeah, I use myself as, you know, as a tester of my own SDK when building applications and samples. Nice. So now that you moved clearly from my realm and to SDK realm, what do you, what you knew from the beginning that you discovered along the way? Yeah. So, you know, one of the things that I found super useful when building SDK, it's something that I just mentioned that first, before, before building a feature in your own SDK, you need to build an application first and try to emulate how it looked like to consume your SDK, right? At the beginning, I started right from the SDK side, right? Like into the solution from the beginning and not as a consumer of my own SDK. I think that's super useful. And you can find challenges super early in the process of designing a feature and test that solution in a real life sample. So I believe that would, yeah, that would be a good advice for my, yeah, for my beginning. Yeah, for sure. And that's something that you discovered later, maybe you got a little too into the weeds or something and it was harder to consume because you didn't consider that at first? Yeah. Basically, I started, for example, I needed to introduce a new feature or new APIs. So instead of like having a real sample application that consume the interfaces that I had to provide, I started first like digging into the business logic, the backend of that interface, instead of, hey, this is how the developers are going to use this, right? And this is the most important thing for SDK maintainers, like building applications that developers will enjoy to use it. So, yeah, that change of perspective, it's really, really helps when you have to design especially complex features. Yeah, yeah, for sure. It's on and to kind of go deeper into that a little bit, especially when it comes to some of those complex features, what is the biggest challenge to maintaining an SDK? It's like a black box that I don't know a whole lot about. I'm sure people at Microsoft know, JWS knows, you definitely know you're a doctor. So what has been the biggest challenge to being an SDK maintainer? Yeah, well, this is another great question. Well, I have two to mention, one is specifically related to .NET. Well, you probably know how many versions had been released so far. And as an SDK maintainer, you have to try to support all these versions, right? Because we have customers that still use .NET framework. And we have other customers that they are on top of the latest versions. And you have to support both. And trying to make everyone happy by supporting like a wide variety of .NET versions had been super, super challenging. And then as like a general concern when building SDKs or the challenge we have, it's of course breaking changes, right? Sometimes you realize that there's something that's not working as expected, or maybe you want to introduce a new feature and the design that you have at the moment doesn't work. And you can provide an elegant solution to incorporate a new feature or solve a bug or whatever. But you can't do that because you are going to introduce breaking changes, right? So you need to deal with that. You need to be pragmatic. And you just put that elegant solution in your backlog for the future. And just do like the best you can to keep all your developers happy. The ones that are using your SDK already and the ones that will be using that feature soon. So yeah, that balance between should I release a new version or I just, yeah, I just, yeah, the developers will hate me. So, okay, let's see what we can do. Well, that is definitely something that I would worry about even with my own websites. You know, when I'm when I'm putting things together, APIs, for example, are maintained as well. Like, how do you do versioning? How do you let developers know? It's not enough to just like post on your website. You have to make sure that you have meaningful response codes coming back with meaningful data as to why that no longer works. If you have, if you can't change your end point. So definitely challenges. But along the way, is there anything that is your favorite part? What is your favorite part of being an SDK engineer or maybe something that you're really proud of? Yeah, well, what I love the most, it's like making the life easier for developers. Again, when when you're building this, we do we usually do the hard work for them, right? Because we do this wrapper that do a lot of stuff behind the scenes. And but then seeing developers using that SDK, using just one line of code to like make a lot of things in background that that we do. I really enjoyed that, like making the their life easier. Yeah, get to be the magic wrapper where nobody really knows it's under under there and how much work went into you just how exactly you just see one method and you just call one method. But hey, all the work that I had to do to implement that method. So yeah, but I really enjoyed that. Like finally, again, using that SDK in a sample application and discovering, hey, I just need to do these three calls to make this work. And so beautiful. I love beautiful. Yeah, for sure. For sure. Yeah, I love that. And then I have another one that as well, you know that our SDKs are all open source, right? So talking to the community directly receiving feedback, trying to help them to use our our SDKs, I love that part as well of the building open source SDKs. You can see other people's pull requests against it and suggestions and everything. For sure. For sure, because we are humans, of course, everyone else can have better solutions and we are open to that. And that's the way you learn, right? Yeah. So so I love to have others point of views. And and yeah, also, I like to be part of a community, right? Not just a maintainer. Hey, we are, we want this SDK to be great for you and for me. So let's do all together. So that's, that's another good part about being an open source SDK maintainer. Yeah. Yeah, and it's a lot of work. Do you have any advice to someone new? Because I know that there's always going to be someone maybe new like coming into octa, that I'm sure you probably had to keep, you know, get up to speed with everything. What advice do you give them and or anybody else who's going to start doing this journey? Yeah, so to be like good SDK, I believe that you don't I mean, you not only have to provide a good like solution that follow the language patterns, the language guidelines, but you also have to provide good documentation, right? Because even if you have the most elegant patterns in your SDK, if like people don't know how to use them, then I mean, there's there's no point with that SDK. So it's not only about building an SDK, it's also about providing other ways for developers to get started easily and just focus on their own applications. So that's a good advice. Provide samples, provide good instructions in your read me if you have like a GitHub repo, something that that it should be easy to get started, right? And also you should keep in mind that of course, you will have probably beginners that will use your application and they are just trying to get started. But you also will have those customers that want or developers that want to implement those complex cases, you need to provide a way for all of them right to solve their issues. And and you need to think about what options you can provide in addition to that SDK. It's not about it's not only about coding, it's like it's like teaching a subject to different levels in school at the same time and knowing that they will work for each of their skill sets. Yeah, for sure. And you should be open to learn as well, right? Because like, well, in our case that we have all our our rebus like available on on GitHub, like you should be open to learn from others as well, right? And that's that's the awesome thing about this, like it's it's not about you teaching, of course, probably there are a lot of people learning from from maintainers, but that maintainers also learned a lot from the community. And that's that's great. Yeah. Oh, I couldn't agree more. And I'm so glad that you have been the most amazing person to work with. I have to figure out like all the new stuff coming down is what you've got lots of new stuff. And we love your feedback header. Thank you. Thank you. So how do if somebody has a question, let's say they're starting to build our SDK, how can people reach you? Yeah, so they can reach out to me on my Twitter account. It's here. I believe it has my GitHub account as well. So you can follow me there. But yeah, feel free to reach out with any questions you have. Yeah. Yes, awesome. Thank you so much for being here. And I can't wait to see what you really think. Thank you.