Geoff Schmidt joins me to discuss GraphQL, Apollo, and how the responsibilities are shifting and roles are changing to give more leverage and better separation of concerns between client side and service architectures.
Geoff Schmidt joins me to discuss GraphQL, Apollo, and how the responsibilities are shifting and roles are changing to give more leverage and better separation of concerns between client side and service architectures.
Today's episode is sponsored by LaunchDarkly. LaunchDarkly is today’s leading feature management platform, empowering your teams to safely deliver and control software through feature flags. By separating code deployments from feature releases, you can deploy faster, reduce risk, and rest easy.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com/contact.
If you would like to join the new experimental DIscord group, reach out at developertea.com/contact, developertea@gmail.com, or @developertea on Twitter.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
If you build or consume APIs, and if you're a software engineer, you probably do, then you've probably also heard of GraphQL. In today's episode, we're talking to Jeff Schmidt. Jeff is the CEO and co-founder of Apollo. Apollo is a managed version of GraphQL. That's probably underselling it a bit. It is what they say is the industry standard GraphQL implementation, providing the data graph layer that connects modern apps to the cloud. We talk about GraphQL and what it affords you and your team in today's episode with Jeff. I'm excited to have this discussion. Before we get kicked off, I do want to remind you, if you are a driven engineer, you listen to Developer Tea, you enjoy the kinds of content that we put out on this show, I want you to do two things. One, if you can leave a review in iTunes. This is one of the best ways to help the show continue to do what we do by reaching more developers. The second thing I'd love for you to do is reach out to me directly on Twitter or via email. You can find me at at developer tea or developer tea at gmail.com and join our discord community. This is a group of developers who are asking meaningful questions. We're talking about the development of a software. We're talking about career development. We even have a room in the chat or in the discord community called no stupid questions. We have a career discussion, a job prep or job interview prep. Come and check it out. You can email me at developer tea at gmail and I'll send you an invite to that discord. Let's jump straight into the interview with Jeff Schmidt. Jeff, welcome to the show. Awesome. Yeah. Thanks for having me. So I'm excited to talk with you for a variety of reasons for anybody who hasn't heard of either GraphQL or of Apollo GraphQL. Can you just give us a two minute elevator pitch for those people who have apparently not been not been out from under the rock for a good bit? Sure. Look, things used to be simple. Or at least simpler than they are today. You'd use something like Ruby on Rails or PHP or ASP.net or Spring or all these different technologies to build your website. And they were based on a web server and a database and HTML and CSS going over the wire from that server to your web browser. And now we live in a much more complex world of apps. A way that the app way of building things is different from the website way of building things is every app has an API inside of it. So you're going to have React on the front end. You're going to have a web server or something like that. Or you'll be using Swift, your Android libraries. And you're going to need a way to get all that data out of the cloud and into the device. And there's sort of the conventional way of doing it, which is to build these product APIs. You've got to take all these different databases, microservices, all the different places this information lives because it's probably not just one database anymore. And you have to somehow package this up in a form that your app's going to consume. So any given screen in an app, it's going to have a lot of different pieces of data from a lot of different sources on it. And somewhere you have to recombine all that stuff so you can fetch in a single round trip so you can populate your UI. So without GraphQL, you'd probably build a different REST endpoint for each different screen in your app that gives that particular combination of data you need for that screen. And you'd probably have a tier in your architecture, some kind of gateway tier or backend for frontend tier where you have to write a bunch of code just to do that server-side repackaging of your data into the form your app needs. And the idea with the, we call it the data graph. Is we're going to let you have one schema that's an abstraction layer that lets you take all those different services and data sources and you can query them with this query language called GraphQL, which is almost like a version of SQL that's been adapted for frontend development. Except instead of querying a database, it queries like your whole cloud, all your microservices, all your databases. So what that means is now, instead of having to build all these different product APIs and write a ton of code, code that can't make your app good, it can only make it bad. That's just kind of shuffling data around. Yeah. And joining it different ways. Instead, as you're building your UI, you can just try to GraphQL query and say, Hey, this is the data I want to pull. This is how I want it joined together. Inject that right into my UI for me. So it saves you a ton of time. It eliminates a lot of code that really is just boilerplate in a lot of ways. And it's a more automated and declarative way to handle this problem of getting data out of the cloud and into your app. So what that means is you can build apps a lot faster. You can build features a lot faster. And another great thing is you can. Yeah. Get started with it very simply and easily. It's a layer that you just put on top of whatever APIs you already have and you can adopt it incrementally. So it's a great fit if you're moving to react or building mobile apps, any mobile app really that talks to the cloud and you have more than one or two data sources in the cloud, or you just want a better way with better typing, better tooling to manage all the data coming from the cloud as well as potentially your local state inside your application. How about that? Was that about the right altitude? Yeah. I think that's perfect. So, you know, as I'm listening, I'm putting on my skeptic hat or at least I'm putting on my, you know, software engineering manager hat that says, OK, I see change on the horizon and it scares me. Right. So so here's here's what I want to ask you. I'm going to represent to you one of the pieces of value in my mind when I hear this as as somebody who has worked on both front end and back end and is seeing that full. stack is probably a very difficult term now to apply like accurately. The full stack is is so much broader than I mean, you have like the front of the front end, you have the back of the front end, and then you have this weird overlap middle place and then you have back end and DevOps. And then, you know, there's there's such a broad variety of these different responsibilities that it's starting to become really blurred. And one of the things that attracts me about GraphQL, especially for a company that has a lot of different clients that are all, you know, kind of hub and spoke style, they're all talking to the same data sources or they're talking to the same, you know, kind of fundamental underlying models and schema or whatever. Something that attracts me to it is, OK, the clients get to have the responsibility of choosing the stuff they want. They can kind of and I think this is kind of the original value proposition of GraphQL to begin with this idea that, hey, you know what, I'm going to build the data the way the data wants to be built. And you're going to build the UI the way the UI wants to be built. You're going to build the client the way the client wants to be built. And those things are are loosely coupled. GraphQL allows for people to ask for what they need. In a safe and responsible way by creating these kind of constraints, the proper level of constraint, you know, not providing full query access, for example, directly to a database. But also giving some level of flexibility. Hey, you know, I want these fields. I want these joint. You know, I want these relationships to come in. I want this kind of pagination, whatever. And the client can decide that instead of every single view that I ever make. I have to figure out. How am I going to do pagination on this? Or how am I going to make it to where the payload can be, you know, customizable? Do I have to go through and actually whitelist my own fields, you know, on this specific endpoint and then also on another specific endpoint? I don't have to do that anymore. Right. That this is all stuff that I can focus on, you know, optimizing the database the way it needs to be optimized, or I can focus on the other fundamental aspects of. The backend that I need to focus on without having to worry about what fields get included in what payload. Yeah, that's exactly right. And I, I think another way of looking at it is about, this is about correctly separating concerns. You have two different concerns that if you couple them together, you have a big mess and that mess isn't so evident if you have like one day, one database and one front end, everything's pretty simple, but in modern architectures where you've got multiple multiple apps and multiple backends. Or even as just as your app gets more complicated, we're not talking about two or three rest endpoints. We're talking about a hundred rest endpoints. Count them up. See how many you have. You might be surprised or you might be surprised to discover that you don't know. In which case my question for you is how are you securing those rest endpoints? The way you want to separate the concerns, I think in a modern app is a little different. And sometimes one way of thinking about it, if I compare the data graph to the API approach. The point. API approach versus this like query language based approach. Uh, I come back to three words. It's agile, abstract, and declarative. So agile, you might change your rest API in any major way. Um, once every year or two, right. Or if you want to remove a rest endpoint, you're probably asking around the office, emailing a mailing list. So is anybody, is anybody using this endpoint and you hope the person who's using the endpoint isn't on vacation because you don't necessarily have a way to. Reliably audit all your codes. You know, every single line of code for every single version of every single app you ever shipped. In every geo, uh, every version, uh, that might be out there that might call that API endpoint. So, um, it's typically hard to evolve rest APIs in an agile way, but you have this great tooling, so you can do it. It's abstract. The front end and the backend can evolve independently. You can refactor your monolithic back into microservices. Um, you know, you can build more front end apps and because there's the right abstraction layer in the right place. There isn't that tight coupling. And so those development processes and concerns don't get mixed together. And finally, it's declarative, uh, just like, um, like SQL is declarative. Uh, though I think you point out one of the great things about GraphQL is it really hits a sweet spot about the right level of expressiveness, uh, for product development. But it's declarative in the sense that you don't say, um, how to do something. You say what you want to have happen. You say, Hey, this is the data I want. And you have your query planner is a piece of software. It's a human being. So as when you start using the data graph, when you start using GraphQL, you start to develop this perspective saying I was really acting as a human query planner. I, I had an app that had this piece of data that I needed. I had to write a whole bunch of un unrolled code and I had to think about the parallels. And I had to think about all these concerns. They can actually be handled in a very automated, consistent way by the query planner inside Apollo. And, um, that means that now I can say, Hey, I know exactly which data is going to which place I can understand. Why? Things perform a particular way versus another way. And I don't have as much of this code that is boilerplate that can't, my, can't make my app, bad, can't, can't make may have good. It can only make it bad. So agile, abstract, and declarative, those are kind of the things I'd come back to that are the benefits of separating those two concerns properly. This is so interesting. Um, and, um, this is unusual for developer T to talk even this long about the tech specifically, I know we're only about 10 minutes in, but, um, I. I do want to take a moment to kind of pay homage to this idea that so often our back end and our front end end up having this really strange kind of mirror effect where the back end, if you're used to writing an MVC or something like that. I'm thinking of my many experiences writing Ruby on Rails where it's like, okay, I'm going to go to the front end. I'm going to implement a feature. And then I have to turn around and go to the back end and say, okay, I need to add this field to this response. And then I'm going to go back to the front end. And then there's some kind of data mismatch between the two. Maybe I want to change the field name. And I have to do this constant back and forth between the two. And it turns out that this behavioral perspective that you would normally have, this client side perspective, it's almost like the back end has to reach up and break out of the water a little bit and say, okay, here's what the client is going to ultimately look like. It's like it's creating the foundation for the client to work on. And the client can't move. Like you said, it can't abstract away from that foundation without the back end saying, oh, here we go. We're going to have to. Develop this thing all the way through that vertical stack. Well, that's not necessary. Right. We don't have to have that. We can allow the front end to exist in its own foundation or come up with a completely different metaphor entirely. We don't have to think about foundation as the metaphor for the front end. It can exist on its own and think more about it as a service rather than a foundation. Yeah, I think you nailed it. We'll continue our discussion with Jeff right after this message from a sponsor. Let's say your team is rolling out some new features. Maybe you are actually building a GraphQL endpoint, but you don't want to release it to everyone all at the same time. Or maybe you have finished the code, but the marketing of the feature hasn't really been released yet. LaunchDarkly is going to help you with this problem by allowing you to release your features totally decoupled from your code. It's today's leading feature management platform, empowering your teams to safely deliver and control software through feature flags. By separating code deployment from feature releases, you'll deploy faster, reduce risk, and rest easy. Isn't that what we're all after? It's a little bit of rest after a long time. A long sprint of hard work trying to push out features. The last thing we need is a nerve-wracking experience. And that's exactly what LaunchDarkly is going to take away from your process. With LaunchDarkly, IBM went from deploying twice a week to over 100 times a day. Now, if you've been paying attention to the last couple of years in software development research and productivity research, you know that deploying often. Is a good thing. We've been able to roll out new features at a pace that would have been unheard of a couple of years ago, said IBM's Kubernetes delivery lead, Michael McKay. You can learn more about how LaunchDarkly is going to make your releases boring and give you some better sleep. Head over to LaunchDarkly.com to get started today. That's LaunchDarkly.com. Thanks again to LaunchDarkly for sponsoring today's episode of Developer Tea. I'll see you next time. Bye-bye. I don't have to, like, drop all of our existing code. And I'm interested. I don't want to talk about the details of how that happens as much as I want to discuss this kind of managerial perspective of what does it allow, right? What is the important kind of flexibility option here? We say, okay, you know, this is a very low-risk thing to adopt. In the same way that TypeScript, for example, you can adopt TypeScript by just adding a few types. You don't have to go full bore and replace all of your code on day one. There's some benefit to doing a larger scale operation, but TypeScript is something that you can incrementally adopt. So I want to talk about that incremental adoption with you. What is the value of that over something like, let's say, changing the entire database structure out so that you're directly doing this on a database or something? Yeah, I think one of my perspective I increasingly have on the world is the world and especially the technology world runs on trust. What is trust? I would say trust is just, if I can get statistical for a second, it's your priors. It's the data you already have about what might happen. In a particular situation. I hope I'm not getting too abstract here, but not at all. When you adopt a new technology, there's a lot that can go right. The reason you're picking this new technology is you think there might be some big benefit you're going to get. And the history of technology is just a series of incredible innovations that just happen faster and faster, each of which has unlocked so many amazing benefits for us. But there's also the chance that something could go wrong and we can all probably rattle off a list of technology. What was inside the box didn't live up to the label on the box. Or maybe even worse, it did exactly what it said on the box. And then there are all the other questions you should have asked about how it's going to play out in like two years or five years or 10 years. So I think a lot of stuff that's happening in IT now is about understanding how we build the trust with a new technology to roll it out more broadly. And so I think there's one model where maybe in the past we said, I've got this big new idea. idea. We're going to have to change everything in our company. It's going to be this big top-down decision. The board's going to be involved if we move to this other way of doing things. Could throw our business under the bus, right? Could have a huge benefit. That's a big, tough, scary decision to make. It is a very waterfall way of approaching things. It's very disconnected with the reality on the ground. It means you're going to adopt less new technology. It's going to be riskier. So I think a much better way to adopt new stuff is if you can, if you think about the time versus or the investment versus value curve, you take a little risk, you make a little investment, you see how that plays out. You make another little investment, you see how that plays out. So we tried to design Apollo around the needs of teams who wanted to try out a new technology and see the value for themselves without having to take a huge risk. So I think that's really the benefit. If you can take a little nibble and see how it tastes, and if you like how it tastes, maybe take a bite and see how that goes. And ramp up your investment and ramp up the risk you're taking as you see more proof points and as you build that trust. I just think that's a really great model for how we can build technology so they're more adoptable. And I think the things that are more adopted are going to spread faster. And the other thing is, developers want standard technology. We want our skills to be portable. If we know how to do things with a particular technology, we want there to be a lot of jobs we can get where, we can use that technology. And likewise, if we pick a particular technology for our code base and our app, we want to be able to hire lots of people that already know that. So that's why, from my point of view, easy adoptability is so important for a technology to survive today because you have to get that critical mass. Yeah. So you mentioned this idea of, I'm going to go back to statistics here with you because I think that's a good direction to take this. If you're thinking about effort versus value, right? And, and, and, and, in my head, I'm imagining this is a basic graph, right? And on the bottom you have effort on the, you know, on the left side you have, have your value for each unit of effort. You know, hopefully you're going to see a commensurate linear level of value at least. Right. Yeah. But I don't think you're linear with the graph. Right. Yeah. You know, I hope that, you know, that's, that, that typically isn't enough, right? It's not enough to say, okay, you're going to spend one level of effort, or one unit of effort and get one unit of value, whatever those units are. I think that there has to be a major jump in those early units in order to retain people. And I think that's kind of what you're saying, this idea that adoption should be easy. Well, the only way that you're going to make adoption easy is if you say, okay, we spent like three days and made things drastically better. Now, with that said, I don't know that you can maintain that level or that kind of like steep upward graph. Maybe you can, but at some point it might level out a little bit. You're going to have a little bit less value per unit of effort. And then I think there's this interesting moment on that graph on the further right side where it goes back up again, right? It starts to get exponential again when you start, for example, eliminating the old end points. So now you're no longer having to maintain old end points because your clients have all moved off of them and you can eliminate them. So you have the ability to. Focus you have less of your requests are going to be split between these two different things and you can put all of your energy and your efforts into building one thing, which again increases the value of that thing exponentially, in my opinion. So I'm interested in if you had to draw that graph out, would you draw the same way or would you draw it differently, both in the ideal state and where GraphQL is today? Yeah, I think I would draw the graph. I draw the graph. I draw. I draw that chart as a chart. That's a better word. An initial bump of enthusiasm when you first type in a query and see your own data coming back, you built a simple schema, you've connected to some data sources. And by the way, it's all designed so you don't need the back end teams buy in to do that. This is designed to be something that can be adopted just by a product engineering team. And that's really powerful because the more cross team coordination we can eliminate, the faster, the less investment you need to kind of see it working. So that that first moment where you see your own data come coming back is pretty magical. And then you have to make a little bit of an investment to push it through into production. But then people are typically delighted with that experience. And I think from that point, what you see is you see a couple little I mean, you see linear with a few steps, like a few kind of positive bumps as you maybe start to adopt some more features like, you know, Yeah. like, hey, this gives you a full stack static typing system. If you're going to set up the TypeScript integration, you can do type checking that's consistent across the front and the back end. It's really darn cool. And there's a couple of those really darn cool things. But if you zoom out, the curve is actually an exponential pretty much straight through. And here's why. And this is unlike most technologies, by the way. I think there's a lot of technology to have more costs at scale. Like things get harder. You're like, gosh, this thing looked this new database looked great. When I was putting 10 megabytes of data in it, this query language that promises the moon, you know, sure, sure delivers fast results. But then when you put a lot of data in it or you divide it over multiple nodes or whatever, you start to find the breaking points. One of the reasons the graph has spread so quickly is that the graph is fundamentally it has network effects. It's fundamentally like a marketplace in a way that few other technologies really are. It's more like the phone system. It becomes more valuable the more stuff's on it. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Because what happens is everything I've described so far is kind of like the experience of implementing the graph on a single team. But as you add more data sources to the graph, there's less and less that you have to do. If you want to, like once your data is there, now you're not adding new data sources. You're just querying what's there. And so you end up with this. Each next app you put on the graph is less work. And each additional data source you put on the graph can now reach more apps. And sometimes the backend perspective is, hey, I built this really cool capability. My KPI is I want to get this used by as many users as possible. So inside of a larger organization, for example, I might want to make it very easy for these app teams or these client teams or these business units to adopt this functionality. So the graph becomes more valuable on both the supply and the demand side, the more people are on it. And then you get these second order beneficiaries like, wow, now I understand where all my data is. Like I can say with certainty who looked at a particular medical record, like you get these suddenly other like mind blowing benefits of now we have a language to talk about our data. We can do things that just weren't even on our radar before. So I think the general shape is the same shape as something like Skype or Facebook, right? Because it has that network or that marketplace effect. But there's a series of like really cool kind of bumps, new technologies or new features you can unlock when you get to scaling points, both in single teams and kind of in the enterprise. Yeah. So you talked about this interesting thing just now, the new language that this enables. And I think there's a psychological thing happening here on teams that I'd like to discuss a little bit more. The idea that the product team can now be more aware, depending on how you engineer it, of course. But they can be more aware. They can be more aware of the actual data schema of that graph. And I think that can unlock a different way of thinking about product than, let's say, for example, if you were just to have a ticketing system where they request data, right? Because it allows them to explore the data in a different way. And, you know, my time as an engineer working with other product engineers has been, you know, oh, I know that this is possible. And the only way I know it's possible is because I've spent time with this data, right? I know that I can cross these things together and get this unique thing that we're not using right now that could provide an interesting feature. It's almost like the features birth from the data or from that schema rather than the other way around where the schema, you know, follows the feature. I think it can be the other direction. And I'm interested in that language. How does that work? How does that work? How does that work? How does that work? How does that work? How does that work? How does that work? How do you see that changing the way that product teams think, both practically and theoretically? Yeah, as usual, I think you've gone right to the heart of the matter. Let me zoom out a little bit. You know, the way I see it, so we've made, as a species, we've made trillions of dollars in this IT computer stuff, right? The transistor, the operating system, and then the internet, the mobile phone, the cloud, you know, decades of work by so many people, trillions of dollars of investment. Why do we do it? Why do we do all that stuff? Fundamentally, all of that stuff, everything I just listed, that's just the infrastructure. That's the railroad tracks. That's not the train. That is the cost we had to pay to get to where we are today. It's the apps. It's the products that create the value. The app is the point of value creation. It's the reason why we built all of that stuff. And now we're in this really cool point in time in history where we have this incredible platform. We can deliver these incredible apps all over the world. We can deliver these incredible apps all over the world to a billion people with these highly scalable tools where everybody can access them instantly using the internet from their pocket. It's so cool. It opens up so many opportunities, and it's really the increasing maturity of kind of that underlying platform. Now what we have to focus on is how we make that valuable. So I really feel like product developers are going to be the heroes, are already the heroes of the next chapter of technology. And if you go back not too many years, there's this stereotype, oh, all the real work is the back end. And if you go back to the past, you'll see that the product developers are going to be the heroes of the next chapter of technology. And so I think that's going to be the key. And I think that's going to be the key. And I think that's going to be the key. I've heard them called like fluffy coders. I've heard them called HTML in 30 days coders. I think that is an absolutely antiquated mindset that completely misses the point about where value is created. Value is created by the app developers, by the product engineers. We need to do everything we can to enable and empower the product development team because they're how we get a return on all the investment. We made in all that other stuff. So the question is, what do we do to really make the increase the leverage and the reach of product developers? And I think product developers are also a very special group of people because they're able to meld the human perspective. Like, how do we create something that's usable and also solves a business purpose? It lets someone solve a problem that they have with the technology perspective. How do we make all this stuff work under the hood? So product engineers end up being. Really where the rubber meets the road in terms of all the investment we made in technology and how we're going to make it useful to humans. So that's why at Apollo, our mission is to help app developers help the world because we believe in the incredible potential of all this technology and we believe it's app developers that's going to make all this technology really serve humanity. So that's the whole perspective from which Apollo exists. And to talk about your question a little bit more, how are we not serving product developers today that we could serve them better? And I should say when I say app developers. I mean, as distinct for I mean, the product developers, I mean, distinct from the service developers on some level, it's all the app. But I think there's increasing distinction of the service engineers that kind of build all these cloud capabilities for us that are reusable, very orthogonal. And then the product developers are the app developers that turn these into experiences that people can have, like in their web browser, you know, on their mobile phone. Like if you if you have a Peloton bike, like on a piece of exercise equipment, like ubiquitously throughout your life. And I think these two. Groups end up having different cultures and different psychologies, and we need to understand the role that all of these play in how we get these these amazing applications out there in the hands of our users. The back end team, the service engineers here, we're thinking about we're thinking about scalability. We're thinking about security. We're thinking about availability. We're thinking about a bunch of engineering concerns. There's about scaling and protecting like the kind of core business assets, core logic, core services that we we have in the cloud. And that's a group of people that really needs to think about the keeping these services orthogonal. Like I want the product service to just do product. I want the user service to just do users. I want the inventory service to just do inventory because I want these to be very reusable, modular building blocks because I don't know what the future holds. Like we might build any number of different features or use these amazing capabilities in lots of different ways. So it makes sense that this team thinks about these things as these sort of separate building blocks. What's happened? But but that's not how users are going to consume them. Like if I'm using like a ride sharing app like Lyft or Uber, the capabilities in the cloud are a real time marketplace of riders and drivers and maps and navigation and reviews and payments. I don't care about any of those things as a user. As a user, what I care about is I'm here and I want to be there and I need all that stuff combined together to build a solution for me. So somewhere we have to do that combination step. And that combination step is. The step where you're looking at it from the point of view of a user or creating value. So it makes sense that the services teams are going to think about their, you know, the long term modularity and orthogonality and maintainability of these services. But we have to do more to enable the product development team to take that stuff and combine it into the experiences that actually create value. So I think that's what you're getting at. This is about a new set of tools that kind of shifts the balance a little bit or maybe doesn't take anything away. At the same time, they may have taken theijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij you can look at a couple ways. One is we invested trillions of dollars in the cloud and all these servers and stuff. We don't get a return on that unless we build some cool apps on top of it. But maybe a more optimistic way of looking at it is there should be a high quality app for everything. Apps are our gateway, our people, our door to this whole world of possibilities that's opened up by all this cool stuff we've built on the internet. And we just can't build this stuff fast enough. There's so much more that we can do to unlock all that value faster. If we can let product engineers focus on creating these great experiences for users, understanding what people need, understanding how technology makes that possible, instead of just basically cleaning up the, I won't say cleaning up the services team's mess because there's a reason it is that way and that's the way it should be, but just repackaging the data in a different form. It's about getting the product engineers to a higher level of leverage in terms of what they can contribute. Thanks so much for listening to the first part of my interview with Jeff Schmidt. I'm excited to have him on for the second part of the interview and I would love for you to listen to it. But the only way you're going to be able to do that is if you either remember to come back or if you subscribe so you don't have to remember anything. Subscribe to whatever podcasting app you're currently using. Thank you again to LaunchDarkly for sponsoring this interview. Today's episode, you can make your launches really boring. Your feature launch is really boring by using this managed feature flag industry standard solution. Now head over to launchdarkly.com. Thanks so much for listening to this episode. Don't forget to reach out to me if you would like to join the discord community. You can reach out to me on Twitter at developer T. You can also reach me at developer T at gmail.com. Thanks so much for listening and until next time, enjoy your tea.