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 Cutrell, 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 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. The most important reason is that the things that we do over and over have a compounding impact on our outcomes. We learn the most from things that we do repeatedly. The 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 iterations. 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, not 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. So the amount of effort that you needed to put forth in the first 10 iterations to get something done, to get some productive 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 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 living in that place. Remember 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. Choosing a particular language, a particular programming language, this generates repeated behaviors, both at the very atomic level, like, for example, writing more parentheses if you're choosing JavaScript versus Ruby or something. But also at a meta level. 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 more traditional object-oriented language. I'm going to categorize these kinds of generators. We're going to call them engines for this sake of this episode. 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. This episode of Developer Tea is brought to you by LaunchDarkly. LaunchDarkly is joining us once again as a sponsor of the 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 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.t trajectoryconf.com. That's www.t trajectoryconf.conf.com. Thanks again to LaunchDarkly for sponsoring today's episode of Developer Tea. 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. To call this purely a habit is probably 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 two, 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, where you 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 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, in your job, 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 that 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. In one way or 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 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. 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 every language out there into terms of how powerful it is, Blub is right in the middle. That's the average of all languages. He coined this idea of the Blub Paradox. This is what he says 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. He's less powerful than Blub, 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 to power continuum, he doesn't realize that he's looking up. What do you say he's 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. It's an engine for so many of their behaviors that when they look at some other engine, especially one that has more features, another language that has more features than Blub, they can't really think about changing all of those ingrained behaviors. If they look at something less powerful than Blub, they can simply see it as less powerful and they choose to return back to their preferred engine. There's a lot of inertia in trying to change your engines, 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. There are a lot of biases and 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 that we couldn't possibly imagine upgrading our engines. This is the thing that I want you to understand. Instead of focusing on those behaviors, 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'm not telling you to go and try changing languages every single week. That 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. 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. 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 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 your daily routines. 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. 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 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. 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 Launch Darkly. You can join the fully virtual trajectory comp that's trajectory comp conf.com. That's totally free registration for Launch Darkly's event on November 9th and 10th. Thanks so much for listening to this show. Developer Teawouldn't exist if it wasn't for you. And if the show has provided you even one insight, hopefully that makes it worth your time. But also, I'd like to ask you to share that experience in the form of a review and rating on iTunes. As you certainly know at this point, this is the way that podcasts continue to grow and sustain themselves, it's all on your shoulders. No pressure. Thanks so much for listening. And until next time, enjoy your tea.