What happens next? This is a question that developers should be asking more frequently. If you're trying to develop a stronger sense of intuition, this episode is for you.
Command Line Heroes is an original podcast from Red Hat about the people who transform technology from the command line up.
A new season was released on July 14th, in which Author Clive Thompson joins host Saron Yitbarek to share his insights from over 200 interviews with coders for his latest book.
This 3-episode mini-season will cover: the many paths to a coding career, where coders work, and what coders expect from each other.
Head on over to the podcast platform of your choice to listen and subscribe for free to Command Line Heroes.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
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.
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. We're traveling and listening to developers. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Here's why this question is so important. Basically 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 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, right? 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 team members 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. And 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 mini season where author Clive Thompson joins host Serrani Barak to share his insights from over 200 interviews with coders for his latest book. The three episode mini season will cover the mini 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 revolutionary hardware. 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. These are the things that happen beyond the original decision. Most of the time the rewards that we receive, 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 for 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 it's 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, etc. Those are harder to measure. It's harder to see the direct impact that speeding up your website is going to have on how long a customer stays with the company. Maybe they will stay longer with the company. Maybe that is a positive second, third or fourth order effect. Just to be clear, a second, third, fourth order effect, these are things that happen well after the initiating action that caused that thing to happen. 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 entirely. 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. This time is spent past that first order effect and into the multiple resulting effects after that. That's because our decisions compound. When we make one decision, it changes all of our future decisions. We're not going to get into the philosophy of the different decision paths we might take. 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. This is the critical factor here. 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 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. There is a way to generate an understanding or an appreciation for these in order effects. I guess one plus in order effects. Anything beyond the initial action. That is to develop empathy for other people. The seems disconnected, but I'm going to 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 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. Having 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 Developerty. I hope that you will shift your focus, you can't forget the first order effects, but shift your focus to the downstream effects. This is long-term thinking at its finest and even though we are configured to provide feedback, to provide rewards or even the opposite of that to provide our punishments or negative reinforcement on those first order effects, I hope that you will see the value in focusing more on those downstream effects. Thank you so much for listening to this episode. Thank you again to Red Hat for sponsoring this episode. 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 episode of Developerty can be found on spec.fm and this episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.