What happens next? This is a question that developers should learn to ask more frequently. And not just developers, but anyone who is trying to develop a stronger sense of intuition, better decision making. This question of what happens next is not easy to answer. And that's what we're talking about on today's episode. My name is Jonathan Guttrell and you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. Here's why this question is so important. Really what we're talking about when we say, what happens next, is what happens after the first and most obvious thing happens. Let's say, for example, that you are trying to increase the competency for a given subject on your team. And so you decide that you're going to pour some resources. Let's say you are the decision maker, you decide where money goes, and so you're going to pour some resources into learning about that particular subject. Now, what happens next? Of course, the first thing that happens, the most obvious thing, is that the people that you are providing this training to, they might go and take this training and you may have some higher competency around this training. But what are the second order effects of this decision? What happens next? What happens after the second order evolution? next? What happens after these people receive their training? What are the other effects that there may be on, let's say, for example, people who are not a part of your team? Perhaps they feel that somehow it's unjust that these particular team members are attending training, that they would like to have the same kind of resources spent on them for their training. Or it's possible that the next time that you experience some kind of shortage, some talent shortage, that you believe that the go-to option is to spend more money on training rather than, for example, maybe a better option. Maybe there's somebody within the company that you don't yet know about that actually already has that competency. And if you were to collaborate with those other teams, you would be able to spend more money on training. Maybe collaborate with a manager to determine who else may have that competency, then the training resources that you could spend in a better spot may be wasted. So it's obvious that thinking about second order effects makes sense for managers. It makes sense for people who are trying to make decisions with money, for people who are looking at the long-term effects on a given system. But how can it make sense? To think about this more deeply for the average software engineer, someone who isn't in that management or leadership position. That's what we're talking about right after we talk about today's sponsor, Red Hat. Command Line Heroes is an original podcast from Red Hat about the people who transform technology from the command line up. The all new season returned this summer to explore the job of being a coder. It's a three-episode podcast. It's a three-episode podcast mini-season where author Clive Thompson joins host Saranya Barak to share his insights from over 200 interviews with coders for his latest book. The three-episode mini-season will cover the many paths to a coding career where software engineers work and what they expect from each other. Past seasons have ranged from the history of open source to the origins of popular programming languages and most recently the creation of Microsoft Office Word. So if you're interested in the future of software engineers, you can find us on our website at www.commentlineheroes.com. And if you're interested in more of the latest and more advanced software, head on over to the podcast platform of your choice. Maybe the one you're using right now to listen and subscribe to Command Line Heroes. Thanks again to Red Hat for sponsoring today's episode of Developer Tea. So here's the critical thing about thinking about second order, third order, fourth order effects, right? These are the things that happen beyond the original decision. Most of the time, the rewards that we receive and the recognition that we receive from our co-workers, from our managers, the raises we get, they're often based on the first order effects. Think about this for a second. If you were to, let's say, speed up the front page of your company's website, I don't know. If you were to do something that was easy to measure, it was easy to see the value that you generated, and it was easy to see the first order effect. The idea that people would come to the website, maybe the measurement of how long it takes for that front page to load would go down, and so you receive some kind of recognition. This is a first order effect and its immediate response. And it makes sense in a lot of ways that our reward systems would be based off of first order effects. The reason for this is that second order, third order, fourth order, et cetera, those are harder, to measure. It's harder to see the direct impact that, you know, speeding up your website is going to have on, you know, how long a customer stays with the company, right? Maybe they, maybe they will stay longer with the company, maybe that is a positive second, third or fourth order effect. Now, just to be clear, a second, third, fourth order effect, these are things that happen, you know, well after the initiating action that caused that thing to happen, right? And the reason why they're so hard to measure is because of that delay. Something else has happened in between and it's hard to disambiguate whether the original action that you took was actually the reason that this second, third, fourth order effect occurred or whether it was the first order effect of a different action. This idea of focusing on the downstream effects and finding ways to measure those downstream effects, this is so important. This is the real point I want to drive home. That's because most of the time is spent in the second and beyond order effects. Most time is spent past that first order effect and into the multiple. And that's because our decisions compound. When we make one decision, it changes all of our future decisions, right? This is when we're not going to get into the kind of the philosophy of the different decision paths we might take. But when we make a given decision, it changes the future of all of our other decisions and every other decision is built on top of that one. But this is the critical factor here. All right. Once we make a decision, the effects of that decision will last indefinitely. We can't really measure exactly what those effects are, but they will last indefinitely. You've changed kind of the landscape of what's going to happen, whether the scope of that is within your company or within your personal life or if it's much larger. So there is a way to kind of generate an understanding or an appreciation of the future. For these in order effects, I guess, one plus in order effects, right, these anything beyond the initial action, and that is to develop empathy for other people. Now, this seems disconnected, but I'm going to draw the draw the line between these two things here. If you develop empathy for other people, you'll realize that a large amount of our life experiences are the result of different, different, different circumstances. Okay, downstream effects. A lot of our life experiences are the result of one plus in order effects. These are decisions that were made that maybe initially had one effect, but then they snowballed into this other different effect. Developing empathy for other people's situations, their experiences, this helps you see more clearly the one plus in order effects that have occurred from particular decisions. This is an easy way to provide you with a microscope or maybe a biographical lens on these effects that we're talking about, the downstream effects of our decisions. Thank you so much for listening to today's episode of Developer Tea. I hope that you will shift your focus. You can't forget the first order effects, but shift your focus to the downstream effects. Thank you so much for listening to this episode. Thank you again to Red Hat for sponsoring this episode. Head over to redhat.com to find out more. Head over to the podcast listening platform of your choice. Whatever you're listening to right now will probably work great. Look up Command Line Heroes. This episode and every other episode of Developer Tea can be found on spec.fm. This episode was produced by Sarah Jackson. My name is Jonathan Cottrell. Until next time, enjoy your tea.