Note: This is an edited and condensed transcript of the podcast and will differ slightly from the original recording.

Interviewer (Sid Maestre): Today, I’m very happy to be joined by Brian Rinaldi from LaunchDarkly. Brian, thanks for coming on the podcast today.

Brian Rinaldi: Thanks for having me, Sid.

Interviewer (Sid Maestre): Can you share with me how you got started in the tech industry and your path to becoming a developer experience engineer? I believe it’s a relatively new job title, so I’m curious to know your thoughts on that.

Brian Rinaldi: I started my career as a history major in college during the dot-com boom and began building websites, running conferences and user groups, and writing articles. That led me to a career in developer relations over a decade ago, and my first role was with Adobe. Since then, I’ve had other roles, all dev rel-ish, which is a term I use to encompass the various job titles in developer relations. At LaunchDarkly, where I currently work, the focus is slightly different than pure dev rel. While I still do public speaking, my role is more about creating solutions that improve people’s experience when getting started with LaunchDarkly. A lot of what I write is about integrating LaunchDarkly with different frameworks or languages, making it easier for people to get started.

Interviewer (Sid Maestre): As an interviewer, I like to ask my guests what their definition of developer experience is because I believe that the industry is still trying to define it. So, I’m curious to know what your thoughts are on the topic.

Brian Rinaldi: I completely agree that developer experience is a broad and vague term and it varies from company to company. At LaunchDarkly, my focus as a developer experience engineer is to make it easier for developers to onboard and use our product. This includes providing resources and tools to help streamline the process and improve the learning curve. Documentation is a significant aspect of developer experience, and I contribute to our docs even though we have a dedicated docs team. While some companies may focus more on developing tools to ease the onboarding process, my role is more content-focused.

Interviewer (Sid Maestre): I’m interested in hearing more about LaunchDarkly’s products and the problems they solve for developers. While I’m familiar with the company and have even used it at previous companies, I think it would be beneficial for you to give me a summary of your products and the specific issues you address for developers.

Brian Rinaldi: LaunchDarkly is a feature management platform that helps companies manage their releases in a way that reduces risk and allows for faster development. As a developer, using feature flags in LaunchDarkly enables me to work straight off of the trunk without the risk of breaking the build because I can enable or disable features as needed. This allows for testing and ensures that the features are released to everyone only after they are tested and working.

Interviewer (Sid Maestre): I’ve heard of feature flags being used for various purposes. While I wouldn’t necessarily call it “different editions,” you could use them that way if you wanted to. Is that the same case with LaunchDarkly as well where you could turn features on and off for customers based on their subscription?

Brian Rinaldi: Yes, entitlements are possible with LaunchDarkly and I’m currently working on a project where we’re discussing how to use LaunchDarkly for entitlements. This type of use case would involve a permanent feature flag, as opposed to a temporary one that gets removed after testing. Companies can use this feature to enable beta programs for specific groups of users and to give access to certain features while excluding others. This is not a new use case, and LaunchDarkly is adapting to ensure we have the resources to support it.

Interviewer (Sid Maestre): I was a developer experience director at my previous company and I worked with folks who were building SDKs and managing our docs and working on API governance. So for me, that’s what my focus was because that’s what the company needed.

But I’m curious for you, you said you do a lot of content in your role. Can you, tell me more about that?

Brian Rinaldi: So, I work on a developer relations team at LaunchDarkly. When I first joined the company, I was the only person on the team. At that time, the dev rel team was primarily focused on external communication, like conferences and high-level thought leadership content, without providing many practitioner-based resources or actual code to help integrate LaunchDarkly into products.

Originally, I was mixed in with the docs team and the developer experience team, which focused on building tools for improving developer experience. However, after a reorganization, I got moved over to developer relations, which broadened my focus. I still work on building guides and articles to help companies integrate with LaunchDarkly, but I also have more responsibility for external-facing content like conferences, blog posts, and videos.

My first project was creating a guide for using LaunchDarkly with Next.js, where I walked users through the integration step by step and provided a GitHub repo as a resource. I still work on similar projects, but my role has broadened a bit to include more external-facing content. In terms of my title, you could say I’m a developer advocate, which is similar to a traditional DevRel role.

Interviewer (Sid Maestre): It seems like you have a strong technical focus. I can relate to your approach of delving into communities, understanding their needs, and creating sample code. I’m a big advocate of starter apps, so wherever I go, I always look for ways to make it easier for users to try out the SDKs or tools we provide. It’s not enough to just give them the code; we need to make it more turnkey and help them understand how to get started.

Brian Rinaldi: Our SDKs are such a critical aspect of our product that they have their own dedicated team. As a result, our developer experience team has always been somewhat separate from the SDK team, even when we were part of the engineering department. This is because the SDKs have a unique role in how they integrate with our product.

Interviewer (Sid Maestre): I noticed that LaunchDarkly has a wide range of SDKs available on their website and I’m curious to learn more about it. Specifically, there are 14 different server-side SDKs and 15 client-side SDKs, which seems like a lot. Can you explain the reasoning behind having so many SDKs?

Brian Rinaldi: There are no limitations on which programming languages can be used with feature flags. Multiple languages can be used within the same project for different parts of a feature. Using LaunchDarkly’s SDKs is preferred for implementing feature flags because they provide unique features that are critical for efficient flag evaluation. For example, when using the server-side SDK, it pulls down all the rules for all the flags in the environment and stores them in an in-memory cache, making flag evaluation extremely fast. If a change is made in LaunchDarkly, it gets pushed to the server immediately, and the flag can be turned off almost immediately. However, if something outside of what the SDK does is needed, such as creating a new user profile, the API would need to be used.

Interviewer (Sid Maestre): When you compare using the API versus using the SDK, the SDK uses all of the public APIs, but presents them in a user-friendly interface that includes extra features. While it’s possible for customers to create these features themselves, it doesn’t make sense to add more complexity to their codebase when the problem has already been solved. Additionally, since the company has a stake in keeping the SDK working well for all customers, it’s in their best interest to maintain and update it regularly.

Brian Rinaldi: I think implementing that on your own is entirely possible, but why would you want to get into the business of maintaining it? You get all of that built-in with SDKs, which improves the developer experience. Our SDKs are not just a pure wrapper over the API to make it simpler to use. They add a ton of features that you just won’t get if you go directly through the API.

Interviewer (Sid Maestre): I really like how you described the difference. You could potentially be using three different SDKs inside of the same application because things are written in different languages by different teams. You know, that’s why that totally answers my question of why you have such broad support for so many different languages on the client-side and server-side.

Now, you mentioned that there was a team that owns that. Is that considered part of your product? Is there a specific engineering team at LaunchDarkly that owns it with product managers and all that?

Brian Rinaldi: It is a core part of our offering. Yeah, there’s an SDK team that has a product manager who determines what new SDKs we’re going to work on or updates to the existing SDKs and so on. It’s such a big task that even a couple of developer experience engineers couldn’t do it as a side project.

Interviewer (Sid Maestre): It’s interesting that you mentioned how many developers maintain SDKs on the side for fun, which I think summarizes a lot of people’s lives. At LaunchDarkly, SDKs are like a first-class citizen as far as the product goes. This leads me to another question I’ve been curious about: when our API changes, how do those changes get integrated into all the artifacts we provide to developers, such as documentation, SDKs, code samples, and starter projects? How do we manage that at LaunchDarkly?

Brian Rinaldi: Most of the time, the changes we make to LaunchDarkly are small and won’t cause big issues across the board. The docs and SDK teams are notified, and we use a tool to track everything. But we are currently working on a major project that will require a lot of changes and coordination across teams. There is a master project in place, and I work with the docs team to update examples and resources related to the change. The SDK team has a lot of releases waiting to roll out with this big change. We have engineering resources working on the LaunchDarkly dashboard and the underlying application, while the SDK team makes changes to the SDKs, and the docs team updates all related content. Each team has its own leadership, and managing communication across all of them is essential for a project of this scope. I typically hear updates through the docs team since my work relates to content and GitHub resources. So, I don’t have as much insight into how engineering and the SDK team work together, even though the SDK team is part of the engineering group.

Interviewer (Sid Maestre): I’ve had situations where a product change affected the API, which flowed through to developers using it, resulting in feedback about property changes or additions/removals. This caused us to scramble to communicate and figure out how to make things right or get on the right path. It seems like you guys have good coordination in place to avoid those kinds of issues.

Brian Rinaldi: At LaunchDarkly, we have a feature called “feature flags” that helps us coordinate changes effectively. We are the biggest user of our own product, so we use it heavily. When we make changes, we first turn on the feature flags for the people who need it, including myself. This way, we can release changes to a smaller group of users before rolling it out to everyone, which decreases the risk of any problems. We gradually turn on the feature flags for more users, and then move onto Q&A testing. Finally, we release it fully for everyone to use, including the API, dashboard, and SDKs. This approach helps us avoid any unexpected problems or poor experiences for our customers.

Interviewer (Sid Maestre): When I visited LaunchDarkly, I noticed that there were two different menus: one for API docs and another for LaunchDarkly docs. I was wondering what the reasoning was behind having these two different groupings.

Brian Rinaldi: In general, most LaunchDarkly users, including developers and product managers, won’t need to use the API directly. The LaunchDarkly docs cover how to use the dashboard, manage users, and integrate with different SDKs. The API docs are for users who need to automate certain tasks or do something outside the scope of the tools provided. It’s important to keep the two separate and encourage users to use the SDKs instead of jumping straight to the API.

Interviewer (Sid Maestre): You mentioned that you’re on the developer relations team and I think that’s a really important part of developer experience as we’re coming out of this pandemic. What are the plans for LaunchDarkly in 2023 that you can share?

Brian Rinaldi: We plan on doing more events than we did in the past. My schedule will be relatively booked with travel and events. We also plan on doing more streaming, including live video on other platforms such as YouTube. This means more campaigns and more live and recorded videos. Our goal is to keep doing what we’re doing but with more events and live streaming. We also plan to run our community conference at the end of the year, but we haven’t decided whether it will be virtual or in-person.

Interviewer (Sid Maestre): Do you know of any developer experience challenges that remain for the company? It really feels like you’ve done a great job with your SDKs and tooling but I’m curious from your perspective, what challenges remain?

Brian Rinaldi: One of our biggest challenges is our surface area, which makes it difficult to have all the necessary tools for integration with different frameworks and environments. For example, our server SDK is node-based, so using it in non-node environments like Deno requires some workarounds. It’s something we’re working on, but getting enough resources to do everything is a challenge. It’s hard to prioritize where to put our resources to have all the necessary tools for easy integration with everything. Unfortunately, we just don’t have the resources to cover every tool one might want to integrate with.

Interviewer (Sid Maestre): Are there any tools or anything that you’re seeing out there or you’re playing with nowadays that you’re really excited about?

Brian Rinaldi: Astro. It is a static site generator that uses an “islands architecture” to send only JavaScript for dynamic components and pages to the client, reducing the amount of JavaScript that needs to be shipped. Astro can use React, Svelte, Vue components, and more together. It allows for bringing already-built components to new projects and still benefiting from its architecture.

Interviewer (Sid Maestre): Thank you so much, Brian, for joining me today. I loved hearing about your career and LaunchDarkly and wishing you all the best. Looking forward to seeing you around in 2023.