ยซ All Episodes

Tradeoffs Of Control Optimized To Serve Your Goals

Published 5/11/2022

The background noise in today's episode wasn't just a mistake, it was a choice. A tradeoff.
Tradeoffs represent a decision of control and energy. You will make them every day, but towards what goal?

When you make a tradeoff and decide where to put your energy, you are necessarily deciding not to put it elsewhere. So, do so with purpose and intention.

๐Ÿ™ Today's Episode is Brought To you by: LaunchDarkly

This episode is brought to you by LaunchDarkly. LaunchDarkly enables development and operations teams to deploy code at any time, even if a feature isn't ready to be released to users. Innovate faster, deploy fearlessly, and make each release a masterpiece. Get started at LaunchDarkly.com today!

๐Ÿ“ฎ Ask a Question

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.

๐Ÿ“ฎ Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting https://developertea.com/discord today!

๐Ÿงก Leave a Review

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.

Transcript (Generated by OpenAI Whisper)
You're listening to Developer Tea, my name is Jonathan Cutrell. In today's episode, when I talk to you about trade-offs, in the background of this episode, you might hear some background noise, and I specifically decided to call this out rather than avoid it or try to compress it because it's actually relevant to today's conversation. You see, the background noise is something that I can't really control. There are many things in our careers that we won't be able to control either. But interestingly, we often go through so much cost, so much pain, so much effort to try to mitigate the things that we can't control. Think about the bugs that you can't predict that are going to occur in production. The ones that are sitting in your code right now that you imagine if you were to go and spend a week of time, you could find one or two of these bugs. Think about all of the possible things that could go wrong with your coworkers, so you go out of your way to make sure that those things are not going wrong. Today's episode, we're talking about these trade-offs because the reality is there are things that we can't control, and they'll always be there. But sometimes we imagine those things matter more than they really do. We're going to talk a little bit more about why and what we can do about it right after we talk about today's spot. Today's episode was brought to you by Launch Darkly. Launch Darkly is feature management for the modern enterprise, and it's fundamentally changing how you deliver software. Here's how it works. Launch Darkly enables development and operations teams to deploy code at any time, even if a feature isn't ready to be released to users. Rapping your code with feature flags gives you the safety to test new features and infrastructure in your production environments without impacting the wrong end users. When you're actually ready to release that code more widely, all you have to do is update the flag status and the changes are made instantaneously by Launch Darkly's real-time streaming architecture. Go and check it out. With Launch Darkly, you can innovate faster, deploy fearlessly, and make each release a masterpiece. Head over to launchdarkly.com to get started today. Thanks again to Launch Darkly for sponsoring today's episode. We won't always control everything. Even for the things that we do have control over, even when we're discussing the things that we can impact, we can't impact everything all the time. The things that are within our control are only within a certain amount of control. In a way, the things that we choose not to exert control over, we might as well not be able to control. We have this relationship with control over the world around us where we have to be very selective about the things that we're actually taking the time and the energy to control. So often, so much of our success depends on this decision. Much of our misused efforts are in the area of trying to control things that we can't. Perhaps, an even more insidious category is that we do have some control over, but realistically, it would be better if we spend our time elsewhere. What does this have to do with trade-offs? Well, the way that we spend our time is all about trade-offs, choosing what we will exert control over, choosing what we'll focus on, how we spend our time is entirely about trade-offs. And often, we're responding to implicit standards, demands that we're placing on ourself, demands that we assume are placed on us, different strivings towards goals that we didn't even define ourselves. For example, we might implicitly assume that our goal in our career is to continue getting promotions and continue getting raises, never really asking ourselves if that goal makes sense. And so we try to exert control over our earning power and giving up control over, for example, our time, or maybe our autonomy, our enjoyment of our role. In our job, we might assume that delivering code that has zero bugs in it is of utmost importance. And so we'll tend towards overspending on verification, on manual testing, trying to cover every test case. In this spending, often doesn't do much for what we really care about. And see, this is where we need to create some clarity, because all of these implicit standards, we assume that if we follow them, good things will happen. We'll somehow arrive at our destination, but we haven't even defined what our destination is. In order to make trade-offs, we have to know what we're trading towards. In order to make decisions about our target income level or our target defect rate or what tool we are going to use for a given project or what shirt we're going to wear today for our Zoom calls, all of these trade-offs, small and large, are driven by some goals. Sometimes those goals are identity-based. This is the kind of person that I want to be. Some of them are some kind of state you want to arrive at. You want to be retired, for example, by a particular age. Some of them are experienced-oriented. You have a list of things that you want to experience or do in your life. No matter what kinds of goals you have, the way that you spend your time, the focus you provide, how you are optimizing, the things that you decide to control, that is the fuel that you can use to get you towards those goals. So I'd encourage you to try to uncover those implicit things, those standards that are placed on you, whether that's standards that are placed on you by yourself, by your culture, by your team, by your boss, maybe by your peers, wherever those standards are, try to take them from that implicit standard. You're assuming that this is the goal and create explicit goals. This means that you're going to identify what level of focus is appropriate. What level of control is appropriate over the things that you can control? As a person recording a podcast, I implicitly assume that my listeners don't want to hear background noise. But the trade-off here is that, honestly, if you're listening to this and you hear background noise and you turn the podcast off because there's a little bit of that every once in a while, then you're probably not here for the primary purpose that this podcast exists anyway. Having these kinds of trade-off decisions, making decisions on what you exert control over, where you exert your focus and energy is an exercise in understanding the finite nature of your energy, of your influence, of your time. I want to give you a word of caution. This is not easy every time. Sometimes it is. It is knowing that you don't want to focus on, for example, learning everything you can every programming language. That seems like a pretty easy call to make. You want to focus on fewer languages. But where the rubber really meets the road is when these trade-offs become difficult. When you actually have to start measuring something and then adjusting your standards based on your measurements. If you're defect rate, the acceptable defect rate in your code base is one bug per week and you're getting two bugs per week. You might need to adjust your testing strategy. But by how much, this is where the hard work is done and where I don't really have it perfect answer for you on this podcast. Instead, my goal is to get you to back down from things that are absolute standards. Or for that matter, arbitrary standards. Choosing an arbitrary number for your test coverage, for example, or choosing an arbitrary amount of time that you spend testing a particular feature, this is a recipe for failure. Instead, look at your results, look at your goals, look at the purpose for these standards to exist and the work backwards from there and always be willing to adjust those standards if your goals are not being met. Thanks so much for listening to today's episode of Developer Tea. Again, a huge thank you to Launch Darkly for sponsoring today's episode. Head over to launchdarkly.com to get started with feature flagging, enterprise level, feature flagging for free. That's launchdarkly.com. If you enjoyed this discussion and you don't want to miss out on future episodes, go ahead and subscribe in whatever podcasting app you use. But I'm going to ask you to do something else. Join the Developer Tea Discord community. We also have a channel where you get notifications whenever there's a new episode of the show that's coming out. You can also discuss your career questions that you have about your career. There's job notifications. There's a book club. There's a bunch of interesting discussions happening in this community. developertea.com slash discord. Thanks so much for listening and until next time, enjoy your tea.