In the last episode we talked about feedback loops and in today's episode, we're talking about how that feedback loop can lead to automatic responses.
Take a moment and imagine three or four days ago. Replay a mundane event, like your commute. Imagine each movement and turn you need to make to arrive where you need to go.
In the last episode we talked about feedback loops and in today's episode, we're talking about how that feedback loop can lead to automatic response systems and how to build better feedback loops that encourage continuous learning.
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.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Deploy a server in the Linode cloud in minutes. Developer Tea listeners can get a $20 credit and try it out for free when you visit: linode.com/developertea and use promo code: developertea2019
P.s. They're also hiring! Visit https://www.linode.com/careers to see what careers are available to you.
I want you to take a moment and imagine three or even four days ago. Try to replay a mundane event. Let's take transit. Imagine that you are headed to work or headed to school. Imagine each individual movement and each turn. That you have to take to arrive wherever it is that you're trying to go. If you're like pretty much every other human, these things seem to happen automatically. In fact, many of us have had that experience where we realize once we arrive at the place that we're going, that we didn't really even think about where we were going. And sometimes we even go to the wrong place. Even though we knew where we were supposed to go. This kind of automatic behavior can be really bizarre, but it's also incredible. It's amazing that we can tune out this kind of surrounding information and focus on other things, sometimes entirely daydreaming, while we are operating our normal everyday lives. In the last episode, we talked about feedback loops. And as it turns out, feedback loops are responsible for this kind of behavior. My name is Jonathan Cottrell and you're listening to Developer Tea. And my goal on the show is to help driven developers like you find clarity, perspective, and purpose in your careers. The feedback loop discussion that we had on the last episode is really important context for this episode. We explained kind of the concept of a feedback loop. In short, a feedback loop is a process that allows developers to create feedback loops. In short, a feedback loop is a process that allows developers to create feedback loops. A feedback loop starts with some kind of measurement, whether that's an implicit or explicit measurement, whether it's quantitative or maybe you're just feeling something. You take some kind of input, a measurement of some kind of stimulus. And then you evaluate that measurement. And that evaluation converts that raw information into meaningful information that you can then act on. And that evaluation converts that raw information into meaningful information that you can then act on. Your actions, in a perfect feedback loop, would have a direct impact on the next measurement, your actions, in a perfect feedback loop, would have a direct impact on the next measurement, and therefore, the next evaluation, and, you guessed it, on the next action. Feedback loops are, in many ways, the kind of base unit necessary for learning. The experimental process is based on this concept, The idea that you can try something, which would be the measurement, The idea that you can try something, which would be the measurement, measurement evaluate that measurement against a hypothesis something that you had guessed would happen change a variable and then start it all over again and understanding feedback loops and building better feedback loops this is fundamental to becoming a better engineer a better manager a better product owner a better worker in general because once again it is the fundamental unit necessary for learning so we're talking about better ways of building these feedback loops kind of principles or guidelines for building good feedback loops in the last episode we talked about validating your inputs in your feedback or in your rules and then the loop cycle timeline in other words the amount of time that you spend from measurement to the next measurement and this is important to our example at the top of the show we talked about these automatic rules that we have and we're going to discuss today a concept for examining those rules if you've ever found yourself sitting in front of your workplace instead of the grocery store because you followed some automatic rules what we often call muscle memory or sometimes we call it having our brains replaced and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have taken these actions and you may have Linode. With Linode, you can deploy a server in the Linode cloud in just a few minutes. The critical point here is that Linode is offering $20 worth of credit for new customers. We'll tell you how to get that in just a moment. You can build pretty much anything on Linode. They have a brand new cloud manager, by the way, because Linode is built by developers. I don't know if you all know this about Linode, but it's a bunch of developers that run a company for developers. They have developers internally that are building code. In fact, you can find Linode's code at github.com slash Linode. The manager is at github.com slash Linode slash manager. In fact, if you want to go and work at Linode, they have jobs open at linode.com slash careers. The reason that this is relevant in an ad read for this company is that when you have a company of developers who are providing your service, they understand your needs. For example, if you wanted to automate your deployment and you want to do it with your specific way of doing things, you can do that. Linode offers an API and a CLI to do those things. You can provision, secure, monitor, and backup your cloud. But it's not just developer friendly. It's also leading in the industry. You can pick from any of the 10 worldwide data centers. Last year, that was eight. The newest data centers from this year are in Toronto and Mumbai. Coming soon to Linode, by the way, object storage, Linode Kubernetes engine, and GPU processors. So for those of you who are getting into machine learning, you should check out Linode. Head over to linode.com. This is how you get that $20. Linode.com slash developer T. You can use the developer T 2019 at checkout. Thanks again to Linode for sponsoring today's episode. I'm David T. of developer T. So we've revisited this model of what a feedback loop looks like. You have some kind of stimulus, which you measure either implicitly or explicitly. You evaluate your measurement. You make meaning out of it. And then you take an action in response to whatever your evaluation was with hopes of impacting the next measurement. And then everything starts over again. But there's a lot of information in there. And I'm going to take a look at a couple of things. But there's a lot of information in there. And I'm going to take a look at a couple of things. But there's a lot of information in there. And I'm going to take a look at a couple of things. There's an interesting thing that can happen when you leave the feedback loop the same way, when you have it stay static like this. In that evaluation to action step, even though you have some kind of valid information, some valid measurements, some valid stimulus, something that is clean, right, a quote clean whenever it arrives at your evaluation process, the problem that you can face is that you have rigid or incorrect rules or models that guide your evaluation to action. So how do we fix this? Well, it seems pretty obvious when we frame it this way, but this is an entire area of research in organizational thinking. Organizations tend to have these kinds of feedback loops. They have some kind of stimulus, they measure it, and then they have these set up policies, ways of reacting to particular measurements. And sometimes those policies are wrong, or at least they're wrong in terms of producing the results that they want. And this is typically the case if your policies are too rigid or maybe they're out of date. They haven't changed along with changing circumstances. So the fix for this, and you can Google this, it's not something I came up with here on this podcast, it's called double loop thinking. So essentially, what I'm going to do is I'm going to go to my Google search. I'm going to go to Google search. At the top, click on evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution correct. So the information that you're gathering may not change at all, but the way that you evaluate and then react to that information may change entirely. And of course, as a result of that, when your reactions change, the feedback loop changes entirely and your measurements are probably going to reflect something different. So I'll give you a very simple example of this. Let's imagine that you are a manager and you are evaluating whether the work that your team is doing is on time according to some milestone planning that you have done together. And when the team is behind, you have a simple rule to apply more pressure. And so the team will respond to that pressure by working more hours and theoretically being more productive. And initially, the measurements that you take, they seem to reflect that this is a good strategy, that you actually are producing more work. And so the first week rolls around, the second week rolls around. And unfortunately, around the third week, you have continued to apply more pressure under the assumption that the more pressure that you apply, the more work that gets done, and therefore, the closer you get to being on time. But unfortunately, in that third or fourth week, it turns out that your measurements reflect that the team is not producing very good work. In fact, the team seems to be producing less work than before, than before you started applying any pressure at all. And so following the same rules that you have set up, because you're falling behind once again, you continue to apply more and more pressure. Now, obviously, this is an exaggerated example. Hopefully, if you're listening to the show, you can see, the obvious problems with applying more and more pressure with this linear assumption about the way that humans respond to pressure. And if you were to have this kind of rule, you can imagine that the feedback mechanism is actually damaging. It's self-damaging. Because the more pressure you apply, the worse things seem to get, even though they initially turned out better. If instead, as you apply more and more pressure, you're falling behind, then you're not getting as much feedback as you were trying out this new approach of applying a little bit of pressure, you could step back and evaluate from more of a principled approach, whether that adjustment makes sense or how the model works, the different pieces of the puzzle. If you were to look at the model itself, if you were to look at the rules and evaluate if they seem like they're going to work out, you may find that there are errors in those models, or there are errors in your thinking, and not just small ones, not just incidental ones, but major ones, like in this example. And this is the second loop that we've been discussing, the second loop that we mentioned, the double loop thinking, that first loop being your normal feedback loop, but that second loop including some of the evaluation of your rules. So that is the third, the third guideline for building better feedback loops to engage in double loop thinking. Now, this doesn't mean that you're constantly questioning whether or not your approach is valid, although there is a good argument for questioning often whether your approach is valid, but it does mean that you should do this on a regular basis. You should evaluate your models. All right, let's go through one final guideline at the end of this episode here, and that is quite simply establishing new loops, where they are clearly missing. And additionally, this is kind of a bonus guideline, eliminate or interrupt loops that aren't helpful. The reality is in places where we often want to improve, we don't have sufficient feedback loops established. We either aren't measuring something, or maybe we're measuring it very poorly. We have some kind of abstract measurement for it, some kind of implicit measurement that needs to be converted to an explicit measurement. And so, we're going to go through some of those. And I'm going to go through some of the things that we've done in the past. And I'm going to go through some of the things that we've done in the past. And I'm going to go through some of the things that we've done in the past. Or maybe we aren't doing any kind of formalized feedback loop at all. And so, in these areas, it's important to identify this, particularly from a level of where you want to improve. Going back to our previous episode, the last episode of Developer Tea, identifying places that you want to improve is the first step to understanding where you need to look at your feedback loops. But it's also important to recognize that feedback loops, they don't live in a vacuum. And they often overlap with other feedback loops. So, if you have some set up, for example, maybe you are copied on every email that comes into the support queue, and you're using this as some kind of feedback mechanism, whether you're doing that on purpose or not, this can add noise, and it can decrease the effectiveness of your other feedback loops. So, it's important to not only add feedback loops in places where you, you know, want to improve, but also recognize that having too many can make the environment a little bit too noisy. We'll talk about signal to noise ratio in another episode of Developer Tea, in maybe the next episode, actually, because this extra volume, the extra signals that you have, can impede on your ability to clearly hear the signals that you care about. Thank you so much for listening to today's episode of Developer Tea. Hopefully, you can easily see that feedback loops are incredibly important to your growth as an engineer, to your growth as a human being. Today's episode wouldn't be possible without our sponsor, Linode. Head over to linode.com slash developer tea and use the code developer tea 2019 at checkout. Remember, that ends at the end of this year. So, you have about 15 days or so by the time this episode comes out to go and take advantage of that $20 worth of credit that you've earned. So, if you're interested in learning more about the software that Linode is providing, head over to linode.com slash developer tea. And then share this episode with them. This is the best way to help the show continue to exist by helping other people find the show. Today's episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.