We're in the last month of the last year of this decade. And when the clock rolls over, the time won't be any different, although our perceptions may convince us otherwise. But when the clock rolls over midnight and it's 2020, then we start a new decade. And this change, this moment in time, has many people looking back at the last 10 years. And thinking about what they've done, what they've become, what they've contributed to, and also thinking forward to the next 10 years. Imagining what those 10 years will hold. Almost unanimously, if you were to ask the people who are listening to this podcast right now, would you like to improve in the next 10 years? Almost unanimously, everyone would say yes. Similarly, if you were to ask people, if they feel like they have improved of the last 10 years, once again, most people, maybe not as unanimous as the first question, but most people would say yes to some degree, I have improved. And there's a lot of other interesting questions that we could ask about looking back in time versus looking forward in time. But in today's episode, I want to focus in on that self-improvement aspect. What is our kind of operating system for self-improvement? My name is Jonathan Cutrellng and listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in your careers. And this is a common topic on this show. How do we get better? And this is such a big topic. It will never be done talking about it, and there's not three points that we could summarize in a single episode that would tell you how to get better. There are a lot of principles in self-improvement, and there's a lot of luck involved in becoming better as well. But I want to talk about one fundamental aspect of improvement. And this is centered on the process of learning, and more specifically on the process of feedback loops. We've talked about feedback loops on the show before, but we're going to dive in a little bit more on this concept of feedback loops and constructing the right feedback loop for whatever you are improving on. And in fact, we're going to take this discussion across at least two episodes because there's so much to discuss about feedback loops. They seem simple. I mean, you first think about this. You first think about the idea of a feedback loop. You think, okay, well, I want to take some kind of information after I do a thing and use it to change in some way whenever I do the thing again. And this basic understanding of feedback loops is better than no understanding at all, but there are really important things to keep in mind when you build your feedback loops because you can end up building a feedback loop that is more harmful than it is helpful. So we're going to talk about ways to explicitly structure your feedback loops so that they are more effective. And we have at least eight things that I want to talk about in these two episodes. There may be more as we go along. But first, I want to kind of step back and talk about what exactly we mean when we say a feedback loop. So because it's a loop, we can start at any point in that loop, but we'll start with the measurement. This is often considered kind of the beginning of a feedback loop, but again, there is a continuous loop happening, so there's not really a beginning. We start with the measurement, then we move to the evaluation stage. We take whatever we measured and we make sense of that measurement in some way. We interpret it. And then we decide what to do about what we interpreted. And the thing that we do affects the next measurement. So in other words, as we measure and evaluate and then react to some stimulus or something that we can measure, that reaction will affect the next measurement. A very simple example of this is actually found in the human body. As it turns out, not all feedback loops that we experience are ones that we set up explicitly. In fact, most of the feedback loops we experience are not explicit. But as you sit in a room, as you are sitting on, let's say you're sitting at your desk, and the temperature in the room begins to get colder and colder. Wait, your body will respond. It's not a measurement in the same sense that you measure the temperature by checking the thermostat. You're not involuntarily checking the thermostat, but the signal that your body is sending to your brain, tell it, hey, it's getting colder. And in order for me to maintain my body temperature, my normal body temperature, then I need to respond in some way. Specifically, if it's cold enough, our body is automatically redistribute. Where the blood is going in our bodies. Instead of going to our skin, it will go to our torso. And in the simplest version of this feedback loop, we would continue making adjustments like that one until our core body temperature is stable at what it's supposed to be at. And the same is true when cooling down. If the temperature is rising and it's higher than our body temperature, if we are in an environment where the temperature around us is going above 110 or 120 degrees, our body will respond in a different way. Once again, until we get back to that normal temperature. And not all feedback loops are as simple and not all of them necessarily terminate like your maintaining of the body temperature would, but all learning starts at this fundamental concept of some kind of measurement or intake of information. It doesn't necessarily have to be a direct measurement, although when you set up your feedback loops, that's most likely what you will look for, the thing that you can measure that is meaningful. And then evaluation, some kind of processing of that information. The reason that the evaluation is important, that we separate that as a stage, we become clear when we talk a little bit more about this. And then the reaction, what do we do about what we've evaluated? And then the cycle starts all over again. And the reason that we talk about this in terms of a cycle is so we can understand that sometimes, once again, feedback loops are not to our advantage. They can be harmful to us. A good example of a feedback loop that is well-intentioned, but ultimately kind of self-feeding in a negative way would be a panic attack. Imagine that you're walking up a flight of stairs and you lose your breath. And losing your breath triggers some fight or flight mode and you feel some level of anxiety. And because of that anxiety, you start to breathe a little bit faster, causing you to hyperventilate and feeling the sense of losing that breath again. And so the cycle continues and it's hard to escape that cycle without intentionally interrupting it from the outside, breaking that feedback loop and sending a different signal. So it's important to understand that feedback loops are incredibly powerful. They're not always good and they're certainly not always bad, but they are the kind of the fundamental building block of learning. We're going to take a quick sponsor break and then we're going to come back and talk about a few kind of guidelines for building good feedback loops. Support for today's episode comes from Give Well. Giving is hard. When you donate, how do you know what a charity can actually accomplish with your money? For example, imagine that you want to help children and you found two trustworthy organizations, but they run entirely different programs. One can save a child's life for every $300,000 donated. All the other can save a child's life for every $3,000 donated. If you could tell the difference up front, you'd probably put all of your money on the one that was a hundred times better at saving children's lives. This is exactly what Give Well helps you do. It's very difficult to know what charities will actually accomplish with your donation. Give Well spends 20,000 hours each year researching which charities can do the most with your money. They recommend a short list of the best charities they've found and they share them with donors like you. Give Well focuses on preventing children from dying of cheaply preventable diseases and helping people in dire poverty and that's what your donation can go and impact. You can learn how much good your donation could do by visiting Give Well.org slash Developer Tea. Here's the important part. Their recommendations are free for anyone to use. And number two, Give Well doesn't take any cut of your donation. Finally, the last point here, first time donors will have their donation matched up to $1,000. If they donate through Give Well.org slash Developer Tea. That's Give Well.org slash Developer Tea. Once again, your first donation is going to be matched up to $1,000 and Give Well doesn't take a single cent of what you give. Thanks again to Give Well for sponsoring today's episode of Developer Tea. This topic on feedback loops, this is an incredibly important topic. It's kind of fundamental to being a good software developer and you can go back in previous episodes where we've talked about this in cross reference. There's a ton of information on what it means to have good feedback loops. Feedback loops are a topic of conversation in pretty much every professional circle. And it's a meaningful conversation because there's such an important mental model to carry with you. This idea that you have some kind of stimulus, some kind of evaluation to make meaning from that stimulus response, some kind of action that you take as a result of the meaning that you made. And then things start back over. That action that you took somehow affects the next measurement, the next stimulus that you receive. Very quickly for the end of today's episode, I want to cover two guidelines for making your explicit feedback loops a little bit better. And as expected, this topic is big enough to span multiple episodes. We said at least two were probably end up doing three because there's so much to talk about with feedback loops. But I want to give you this first guideline to get started with this discussion. And that is to validate the inputs of your feedback loop. Validate the inputs of your feedback loop. What does this mean? Well, let's imagine that you are trying to get better at a sprint. You are a track runner and you're trying to improve your sprint times. And let's imagine that you have someone who is taking your times on a stopwatch. But the problem is that the stopwatch is faulty. From time to time, when you press the button, there's a bit of a delay. And also from time to time, the stopwatch will randomly stop in advance. So it won't actually count your time accurately. Well, if you knew that, then you would know that basing your actions or your reactions off of that stopwatch is probably a bad idea. The inputs are invalid. Another place where inputs are often invalid is when developers make estimates about the work that they're going to do. In particular, if you have a system where making an estimate, the estimate itself is a measure of your job performance. But now the inputs are starting to get a little bit muddy. Because developers are going to be incentivized to make different estimates if it affects their job performance. And so instead of having accurate estimates, you start to have, quote, performance estimates. These are vanity numbers and they ultimately aren't really measuring much other than the developer's willingness to break from the norm. And so the thing that we're trying to measure, which is the amount of effort necessary to complete a given type of work, it's no longer available to us. We've changed the system so that the measurement, the thing that is being measured, is shifted even though it's called the same thing. It's important to validate our inputs, not just at the conceptual level, like for example, making sure that some kind of hard measurement is actually measured correctly, but also from the human level, making sure that the things that we are measuring, we're not affecting them by measuring them. And this plays right into the next guideline that is incredibly important when you create your feedback cycles or your feedback loops. And that is the cycle time, the amount of time between a given measurement and a change that you make and try to measure again. If we try to change too often, then we can't really accommodate to the change to accurately measure how well it's going to work on into the future. And so we end up having this high turn of change. Let's imagine that you're trying to change your process as a team and you're changing so often or even changing the people on the team so often that nobody ever gets accustomed. It's like this constant, endless onboarding, a treadmill of onboarding, if you will. But if you don't change quickly enough, the feedback loop becomes less valuable. You don't really have the ability to change in the ways that you need to change. And while your process may be stable and the outputs may be predictable, you may be losing a lot of opportunity for improvement. So these two things, these two ideas of validating your inputs and then secondly, ensuring that you're timeline, your cycle time is enough time to measure in a way that represents how well something is working. Rather than measuring only the effects of the turn, these two things go hand in hand. Because if your cycle time is too low, well, that invalidates your inputs, right? Your measurement ends up being invalid because your cycle time, your turn, your process turn, ends up affecting the measurements too much. These two guidelines can help you make better feedback loops, but how do we decide on these feedback loops to begin with? How do we know what to measure and how to evaluate and then what to do about it? That's what we're going to talk about in the next episode of Developer Tea. Thank you so much for listening to today's episode. Thank you again to GiveWell for sponsoring today's episode. Head over to givewell.org slash Developer Tea and you'll have your first donation matched up to a thousand dollars. Today's episode wouldn't be possible without spec.fm and our wonderful producer Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.