The behaviors that you repeat have the most profound impact on your life. And the systems that produce those behaviors then are probably one of the biggest points of leverage that you have for your personal life and your career. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. The things that you do over and over, the simple form of this might be habits. But it's not just habits because that word comes with a lot of baggage. It's not necessarily bad baggage. The habits that we create for ourselves can be garbage. Good habits or bad habits. Habits are usually something that we choose. In fact, almost universally when you hear somebody talking about habits, they are things that we have the agency to change. Our habits are important for a lot of reasons. Perhaps the most important reason is that the things that we do over and over have a compounding impact on our outcome. We learn the most from things that we do repeatedly. This seems kind of odd. You might think that we would learn the most from things that we do sporadically. This is intuitive. We might think that a variety of experience actually gives us a better learning platform. But the truth is that the things that we do repeatedly we learn from because we can see the small changes between them. The things that we do repeatedly obviously have added up effects over time. And those effects kind of self-feed, especially when we're talking about things like skill development. As you become better in one particular language, let's say, for example. As you continue to use the same language over and over, and this is not just habitually, just doing it without thinking about it, but doing it very intentionally, choosing a specific framework, architecture, whatever that is, a series of tools. As you become better with those tools, each iteration changes in a positive direction. In other words, it improves. And so the amount of effort that you needed to put forth in the first 10 iterations to get something done, to get some productive. You know, progress towards some goal. That effort is reduced dramatically after 100 or 1000 iterations of the same level of effort. In other words, you get more done. You're more productive in a particular direction. Once you've done this thing over and over, you're developing expertise. And so as we continue to invest in single directions, invest in habits. It's not just about the goal. It's worthwhile to consider the things that generate our repeated behaviors. Think about this for a second. We, of course, do it to ourselves. Some of our choices, for example, generate repeated behaviors. The most obvious of these might be where you choose to live. Where you choose to live will generate a repeated behavior of, well, living in that place. Whatever that requires of you. Whether it's a 20-minute drive to the closest grocery store. Or if you have neighbors that are very close by that you interact with on a daily basis, just by virtue of being close to them. Your physical situation creates some kind of repeated behaviors. Of course, this isn't the only major decision that generates repeated behaviors. But if you're using a functional language, you're going to have a different way of looking at the average problem that you're solving. Versus if you're using a computer. Versus if you're using a more traditional object-oriented language. So I'm going to categorize these kinds of generators. We're going to call them engines for the sake of this episode. And we're going to categorize them into two different categories. Which we're going to talk about right after we talk about today's sponsor. Thank you. This episode of Developer Tea is brought to you by... LaunchDarkly. LaunchDarkly is joining us once again as a sponsor of this show. Software powers the world. LaunchDarkly empowers all teams to deliver and control their software. DevOps and feature management are reimagining how we build and release new products. On November 9th and 10th, LaunchDarkly is hosting Trajectory Conference 2021. It's a two-day event for software innovators who want to break orbit. Not. Not systems. Trajectory is a fully virtual conference that focuses on the technology, people, and processes that continuously deliver better user experiences and more powerful software. You can register for free by heading over to www.trajectoryconf.com. That's www.trajectoryconf.com. Thanks again to LaunchDarkly for sponsoring today's episode of Developer Tea. LaunchDarkly. In today's episode, we're talking about generated, repeated behaviors. These are not just habits that you choose. They are behaviors that you engage in repeatedly. Everyone, for example, engages in the behavior of eating and drinking repeatedly. So, to call this purely a habit is probably not a good idea. not sufficient to explain that behavior. If we were to talk about the kinds of food or where people tend to eat or what time they tend to eat, or maybe if they choose to fast some days, these are the kinds of things that you might call a habit. But repeated behaviors are not necessarily purely habits. We said that there are essentially two kinds of engines. These engines create or at least encourage the repeated behaviors. One type of engine is a situational engine. A situational engine is most often created by some large choice in your life. We already talked about one, where you choose to live. And it may not necessarily be up to you, per se. Not everyone can choose where they want to live, as a very simple example. But often, our situational engines generate behaviors, and we can change the way that our situation generates those behaviors. We'll talk a little bit about that in a minute. The other kind of engine is a preferential engine. A preferential engine. This is something that you have chosen. Where you had multiple options, where you had agency, that could easily be changed. In other words, a situational engine is much harder to change. The transition between one situation versus another situation is much harder than the transition between one preference and another preference. And arguably, there's probably somewhat of a gradient between these two types. But it's likely that you're going to have a situation where you have multiple options, where you have multiple options. You would know which one of these you're talking about in your personal life, in your personal situation. For example, you may have organized your life so that you are very nomadic. In other words, you can move from one place to another much easier than someone who has put down roots and has bought a house. Maybe they have a mortgage. So you kind of have to decide or categorize the types of engines that you have in your life. On your teams, on your jobs, some of the engines that we can look at are process engines. And this isn't the forum where you're going to hear us fight about agile versus some other methodology or some sub-methodology. But rather, understanding that whatever of the methods that you choose, whatever processes you choose, they're going to create and reinforce various behaviors. And it is behaviors not only for you, but also for the people in your life. And so, if you're going to employ you, it's behaviors for the people who are using your software. As a simple example, if you have releases every other Friday, then people who use your software may wait until that Friday to use that software so they can get the latest release. The important factor here is to recognize that a lot of the repeated behaviors that we engage in, that others engage in around us, come from these engines. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. than another, the engine is precipitating a behavior. Now it might be a secondary behavior, right? So in other words, because you are releasing on Fridays, you might choose as a team to avoid, you know, adding new features on Thursday so that the release can be thoroughly tested on that Thursday before the release. There's a lot to think about when it comes to these engines though. Not only do they precipitate behaviors and then those behaviors lead into other behaviors as second or third or fourth order effects, but these engines also tend to create paradigms. A great example of this is in software programming languages, the idea that your language encompasses all possible utility of a given programming language. This is best summarized in Paul Graham's article, Beating the Averages. And this was written back in the early 2000s. And Paul is well known to be a fan of Lisp. In this article, he talks about something called the Blub Paradox. Blub is a fictional programming language that is the perfect middle of all languages. If you were to organize, you know, every language out there into, uh, terms of how powerful it is, Blub is right in the middle. It's the average of all languages. And so he coined this idea of the Blub Paradox. This is what he, what he says in the, in the article. As long as our hypothetical Blub programmer is looking down the power continuum, in other words, language is less powerful than Blub, he knows he's looking down. Language is less powerful than Blub are obviously less powerful because they're missing some feature he's used to using. But when our hypothetical Blub, programmer looks in the other direction up the power continuum, he doesn't realize that he's looking up. What he sees are merely weird languages. He probably considers them about equivalent to power in Blub, but with all this other hairy stuff thrown in as well, Blub is good enough for him because he thinks in Blub. In this Blub Paradox that Paul Graham is talking about, the hypothetical language has become a paradigm for the programmer. And it's an engine for so many of their behaviors that when they look at some other engine, right, especially one that has more features, another language that has more features than Blub, they can't really think about changing all of those kind of ingrained behaviors. If they look at something less powerful than Blub, they can simply see it as less powerful. And they choose to kind of, return back to their preferred engine. And so there's a lot of inertia in trying to change your engines, right? In trying to upgrade your engine because changing all of those behaviors seems unnecessary. It seems like a departure from what is comfortable. It seems like a departure from what has made you successful to this point. And there are a lot, a lot of, biases and kind of cognitive dissonance that will cause us to reinforce the belief that our particular engines are the best engines. That the behaviors that they create are good behaviors. And that we couldn't possibly imagine upgrading our engines. But this is the thing that I want you to understand. Instead of focusing on those behaviors, right? Instead of focusing on the downstream effects of those engines, I want you to inspect the engine itself, and imagine what new benefits could come from changing, upgrading that engine. Now, to be clear, I am not telling you to go and try changing languages, you know, every single week. That kind of goes against the principle that we were talking about in the beginning, that we learn the most from the things that we repeat. But if we are repeating the wrong actions as a result of choosing a poor engine for our behaviors, then it makes sense, to take the time to inspect the engine itself. Recognize that these large kind of generators of behavior are the highest leverage place for us to improve. Some of the most common examples of these engines, we've already talked about them, the self-enforcing habits that you've chosen, the ones that you have picked for yourself, that you've established through behavioral patterns, right? That's a huge generator of behavior. Other ones are choosing programming languages. We've already mentioned this. Don't be too quick to change because you may not actually know what those behaviors are. You may not have explored all of the habits that could come from a particular language engine. Other ones are processes. A really important one is decision-making processes, right? This is a very critical engine to pay attention to. How do you make decisions consistently over time? This is an engine because it's going to change the way that you make decisions for every decision, not just this particular one. If you have a decision-making framework, this pays you back over and over and over. Develop a list of these engines in your life. The biggest ones, you know, you don't have to be 100% comprehensive, but think about the habits that you have and the repeated behaviors that you have. Some simple examples might be, you know, your daily routines, right? When do you wake up? Where do you go in a given day? What kind of food do you eat? Who do you talk to? What's on your mind? What is your leisure activities? All of these things are probably things that you repeat on a regular basis. And then think about the various systems that influence those decisions. Some of those systems you may have a little control over, or they may be much more difficult to change, but others, especially the ones you may have a little control over, may be much more difficult to change. but others, especially the ones that land more on that preferential side of the gradient between preferential and situational, you may have a lot more agency over. Inspect those preferential engines that create your habitual behaviors. Once you've had a chance to inspect these, imagine what would happen if you were to change them. Now, in combination with your personal values, your goals, the things that we've talked about on other episodes of Developer Tea, what kinds of systems could you change? Which of these engines could you adjust so that you generate better behaviors that lead you more towards your goals or fit more in line with your values? Thanks so much for listening to today's episode of Developer Tea. Another huge thank you to... LaunchDarkly. You can join the fully virtual TrajectoryConf. That's TrajectoryConf, C-O-N-F dot com. That's totally free registration for LaunchDarkly's event on November 9th and 10th. Thanks so much for listening to this show. Developer Tea wouldn't exist if it wasn't for you. And if the show has provided you even one insight, hopefully that makes it worthwhile. Thank you so much for listening. And until next time, enjoy your tea. See you soon.