You hear it on this show all the time that context is critical. That virtually nothing has meaning without context. And we can't really answer questions without context. In today's episode, we're going to break apart one way of looking at context. My name is Jonathan Cutrella listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. And context is everything. Some context is implied. We don't have to think about, for example, whether it's day or night, the environment provides the context. Other context is based on pre-established habits or norms. Some things that we experience on a regular basis might provide the backdrop that we would call context. But other context is not these things. Other context may actually be muddied by those same things that otherwise might be reliable sources of context creation. So I want you to think about context a little bit differently, especially when you're making critically important decisions. In recent episodes of the show, we've had this discussion around when to apply these kinds of practices, this kind of thinking, these types of decision-making tools and razors and that kind of thing. And almost always, these things could be applied to any situation, but should only be applied to critical decisions. Most of the time, the critical decisions will help you make those smaller decisions and having good heuristics for those smaller decisions is probably more effective than having good tools and processes to make those decisions. So when you're thinking about critical decisions, establishing context and taking the appropriate amount of time, in other words, probably more time than you usually spend to make a decision, to establish and explicitly understand the context is very important. So I want to talk about context in terms of staging. And we'll use the word layers to discuss context here. There's a lot of terms that you can imagine applying to this, but basically we're talking about kind of zooming up or zooming to the past, the thing that creates the situation, and then zooming into the future to imagine the after effects in given scenarios. So in some ways, the zooming back, you could imagine that zooming backwards in time, this is what we're going to call an outer layer. You can imagine that the outer layer of the context that we're trying to describe, intuitively we might think that there's really only one of those. There's really only one context that we need to describe, but the truth is, when we're looking at the past, we have less clarity than we think when we're describing our current state. And I'll give you a perfect example of an argument for this. When you're describing the problems that your organization is facing, this is very clearly a guessing game of sorts. Of course, you can use data to help create your case, but we can't just simply observe the past and describe it for what it is. We have to be able to describe. We have to be able to describe an argument for our perception of the event that created this current context. So if you have a hypothesis of something that is causing a problem, let's imagine that you have a startup, and you have, let's say you are over a lot of the products technology, you have a bug error rate that is higher than you want it to be. That's the problem. And you're trying to describe what is causing this bug error rate. We're writing code that has bugs and it more often than we would like to. So you may have multiple hypotheses as to why this is happening. This is creating multiple outer layers. Think about this. If you approach with the wrong outer layer, then you've created the wrong context to make this decision. You've essentially created a fictional context to make a decision under. So the idea is your outer layer, even though you are able to observe and record and reasonably explain the current context, you know, kind of the effects of it. You can see very clearly that the error rate is higher than you want it to be. You may not be able to describe why. And this is a part of that outer layer. And so having multiple layers, you can look at the possible reasonings, the possible contexts under which you're making the next decision. And it should be taken into account for each of those layers, right? You don't want to just choose one and move forward. You should imagine applying the same solution from a different outer layer and determine whether or not that could have serious, deleterious effects, right? In other words, if the reason that you have poor, you know, bad error rates is because of the seniority of your engineering team, then adding headcount that is less senior may exacerbate the problem. However, if it's a problem of capacity, then adding headcount that is of any seniority might fix the problem. So it's important to keep this in mind, this idea that your outer layers of context need to be considered and validated all the way through. Now, how do you pick one? How do you know which one is right? That's an exercise that we can't really cover in this episode. It's hard to determine which of your diagnosis pathways is going to be correct. There are ways that you might be able to test your hypotheses, right? Having multiple people weigh in might help you calibrate to what is most true. If you only have one person who believes that the cause is the seniority over the headcount, and then you have four other people, five other people even that believe otherwise, then it makes sense to consider why there's a disparity or why that one person believes something different. So why are we talking about the outer layer? What is the reasoning here? What are the reasoning that I want you to consider the outer layer is because it's very possible. If you're not considering, if you're not setting up this context correctly, then you may have some built-in assumptions, right? You may have some built-in context that you add automatically that is error prone. In other words, you may try to solve the wrong problems. Remember maybe you have a different scale in mind for the problems themselves. I'll give you another example. Let's imagine that you have a page on your website and 95% of the people who go to this page immediately leave your website. This isn't a trick question. It's not a checkout page or something. It's just a page that for whatever reason, maybe it's a 404 or some other kind of page, but immediately at the point that somebody visits this particular page, they end their session and they don't come back. Now this seemingly could be a problem, right? Immediately you think, okay, 95% of people who visit this page. But if you're thinking in terms of layers, then you need to understand one more metric. How many people out of all of the sessions, out of everyone who comes to this site, how many people actually come to this page? If the answer to that is let's say half a percent of people or even one tenth of a percent of people, then this 95% number has a much clearer context. When you have the outer layer of information, you can make a better decision. You have a clearer perspective of what is leading to what, what kinds of problems are connected, what kinds of information is connected, rather than making those connections implicitly yourself. For example, the implicit knowledge that you may have brought to the table is maybe the average number of views that you give them page on your site gets. So you establish some base rate and you imagine that 95% of the average page viewers are bouncing on this particular page. So this would be an incorrect conclusion that's brought about by an implicit context. Does that make sense? You're creating a conclusion based on some information that you assumed or you brought to the table that was intuitive maybe to you. This error can cause you to make the wrong decisions. For example, to pour a bunch of time into correcting this page, making this page stickier, maybe removing the page altogether so people don't go there and then therefore exit. So bringing your own context to the table, you may have a lot of waste, a lot of error. And ultimately, this can leave you doing work that you don't really fully understand. You don't have a clear picture as to why that work is happening, why it's necessary and what it's accomplishing. We're going to take a quick sponsor break. And then we're going to come back and talk about the inner layer. What happens after you've chosen a particular direction? With your decisions. Today we are so grateful for the support from today's sponsor, Compiler. Compiler is a brand new podcast from Red Hat where you will get the tech industry's hardest questions answered. I had a great discussion with Brent and Angela about Compiler and about their experience on it here. We discuss what they think is the most important moment in the season. If you could distill the entire season down into one moment that you feel like was really important for listeners to hear, do you have a moment like that? I would have to say it is our mentorship episode that's coming. A lot of folks are familiar with mentorship, may or may not have had mentors in their lives, but there are so many gems that folks can take away from this podcast. Maybe that's the one that might have the biggest takeaway. I'm sure there are going to be others, but that one kind of sticks out right now. There's this moment in our first episode. That episode centers on the question should managers code. We did an interview for that episode with a manager and she is a data scientist. During this interview, she got really vulnerable with us and it really comes through in the interview. She really misses being an individual contributor sometimes and kind of what it feels like to not currently be doing what you got in the industry to do in the first place. I encourage you if this sounds interesting. Certainly the rest of the show is that much better. Go and check out Compiler wherever you find a podcast. Thank you so much for the support to Compiler. We've talked about the outer layer of context, the idea that as you try to make a decision or solve a problem that it makes sense to go out multiple layers to understand what led to that problem to try to calibrate that understanding by seeking out multiple perspectives. All of this leads to some decision that you make. What's critical to understand is that even with perfect context, there's a lot of variability and noise and static that's going to cause some decisions, some randomness to cause some decisions to simply not go as planned. There's also a high likelihood as you make decisions that something about your hypothesis is wrong. If you're adjusting a previous hypothesis, you might adjust in the wrong direction or maybe the basis of your hypothesis is wrong altogether. It's important to understand that as you move towards the inner layer, that this might become the new setting, a new outer layer. You might be creating the context to solve forward, to move forward and make a new decision. Another thing that often happens with context creation and the inner layer of context is that we try to judge the decision based on what happens afterwards rather than judging the decision or the quality of the decision based on the information that we had available when we made the decision. In other words, we're judging as if we could have predicted the future when no one can predict the future. It's important to understand that this inner layer, what happens after you make the decision is both important to think about ahead of time. In other words, think about the second and third and fourth order effects you can consider those to be inner layers. You continue going down. There's not really a limit to this. It's important to think about those ahead of time as you're making the decision. You consider what happens after what are the multiple possible routes that making this big decision could lead to what are the inner layers that I'm not exploring that I should explore. But it's also necessary and important to think about the inner layer as a tactical tool for making a better decision. You're not just thinking about how can I predict what will happen, but you're also thinking about in what context does this decision affect the future. A simple example of this. Imagine that you have an event-oriented website or an event-oriented application. The application needs to be available for the event that's taking place in real time. You make some decisions in order to make the app available to make the website live during that period of time, and then it will expire or maybe it'll go into an archive state. If you're making decisions for this application based on a long-term frame of mind, in other words, your inner layer, after the decision that you've made, the effects that occur afterwards, if you're trying to optimize, for long-term growth, it's very possible that you're going to make trade-offs that are not optimal for the short-term life that is guaranteed, the short-term life of this application. You've guaranteed it by the virtue of the application being event-driven. In other words, it's not going to be necessary for this to have long-term optimization. If you think about this, and this is a very concrete example, but it's just as critical to think about less concrete examples of the same idea, when you're thinking of the inner layer, you're thinking of the context, the context in which the effects of your decision will play out. Thanks so much for listening to this episode of Developer Tea. Hopefully, this helps you build the idea of context, at least from a temporal perspective, so that you can start to make slightly more contextually aware decisions. Again, remember, this isn't necessary for every small decision, although you can imagine that even the small decisions could benefit from a little bit of this thinking, thinking about the before and the after of a given action that you might take, or a given piece of code you might write. This is very much so a valid concern we are making larger decisions that have a bigger impact on your life. Thanks so much for listening. Thank you again to today's sponsor, compiler, answering, and having discussions about some of the most complicated questions in the tech industry. You can find compiler wherever you find podcasts. If you want to continue having conversations like this one, and love for you to join the Developer Tea Discord, head over to developertea.com slash discord. Thanks so much for listening, and until next time, enjoy your tea.