We tell ourselves powerful stories, not just stories about ourselves or stories about others, but even down to the moment to moment information that we're trying to decode in our minds. We create stories about the world around us. It's one of the most important ways that we see the world. We make meaning out of things. In today's episode, we're going to pay respect to this incredible ability that we have, but also talk about how it can lead us down some frustrating and dangerous paths, even when we have our eyes wide open to these problems. 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. When we receive information, our brain goes to work. We begin trying to make connections and fill in the blanks. Not only do we begin to make connections, but we start to form a picture. And we get connected to that picture. We start to believe the picture as soon as anything discernible pops out from it. In fact, research even shows that the order that we receive information in can affect how we wait that information. They can also affect how we contextualize that information. Let's take a simple example of having multiple people on a hiring committee. This is very common to have, let's say, five or six people on a cross-functional panel or something. And the goal is to try to get as much input from multiple angles as we can. Again, well-intentioned, our eyes are wide open to the problem of having only one person interview, a given candidate. So we're trying to get multiple angles, multiple perspectives. Hopefully not just engineers, for example, are interviewing your candidate, but also folks from, for example, a product organization. So we have these five or six people on a panel. And it's time to have our kind of debrief, right, the end of the interviewing process. We begin to share notes and we order people by whoever decides to speak up first and they're going to share their opinion. Well, let's say that the first person shares a strong opinion that they want to hire this person. Now it's time for the second person to go. And the second person agrees strongly with the first person. Now it's the third person's turn to go. And they have decided to strongly disagree. Now there's an interesting thing that's happening narratively in our minds when we see this play out. Initially, we see one person who has strong feelings, step up and volunteer to go first. Well, this just so happens to kind of be a natural thing that's going to happen if you allow people to volunteer. The people who want to share their opinion are going to raise their hand to do so. So the opening argument, so to speak, is going to likely be a strong one. Interestingly, when you have two people that go back to back and they both agree and then a third person disagrees, that third person might be seen as somebody who is intentionally breaking from the crowd. However, this wouldn't be the case if they went first. If they went first and someone else who agreed with them, that the person shouldn't be hired, went after them, then the third person who does want to hire that person would look like the person that's breaking from the crowd. So obviously, order matters. Interestingly, order can also change what people say in meetings like this. You could have the first five people, for example, they all agree that this person should be hired. And let's imagine that the sixth person had some reservations. But now that they've seen everybody else make their arguments for why we should hire this person, they're much more likely to restrict those original opinions that they had. However, if they had gone first, they may have been much more likely to share those opinions. So the ordering of the information matters, both to the people who are producing that information and to the people who are in some way consuming that information. This is largely due to the fact that we don't view most things in isolation. We draw connections between the elements that we see and we get attached early to the connections that we drew early on. In other words, we started to build a picture, let's say when those first two people got up and they agreed that this person was hireable, should be hired. We start to build a positive picture of the candidate that we wouldn't have necessarily built had the other people gone first. So this concept has a specific name, it's called excessive cohesion. This idea is that as we get information, we try to create in our minds a cohesive story that ties everything together. Interestingly, this applies in a very practical way in your job as an engineer. We're going to talk about that after we talk about today's sponsor, Doppler. Developer Tea is proudly supported by Doppler. The scary days of configuring, managing and sharing secrets across your different teams and clouds are over. Doppler is the first universal secrets platform that enables Developer To automate the pain away of managing secrets and various environment files. Doppler is your team's central source of truth for secrets and app config across all environments and clouds. Whether your secrets are in Docker, AWS, Fursel, Serverless or anywhere else, Doppler works where you work. And as your stack evolves, Doppler remains simple with over 11,000 customers of all sizes of companies from startups to enterprises use Doppler to keep their secrets and app config in sync across devices, environments and team members. Say goodbye to your infiles and set up Doppler for your team in less than four minutes. You can get started at Doppler.com slash L slash Developer Teathat's Doppler dot com slash the letter L slash Developer Tea and of course that'll be in the show notes. Thanks again to Doppler for their support of Developer Tea. We make sense of our code all the time. All of these strange ways of thinking this excessive cohesion. It applies to the way we think about our code. The way we think about bugs that are happening in our code. The way we think about performance improvements. Even the way we think about how to implement a given feature. All of it is subject to these same errors in thinking that we've already been talking about. It's not just hiring when we start to debug something. Let's take this as an example. We might use information to develop a story. The story of the bug. How did it come to be? And when we try to build a story, we often are filling in gaps without using reasonable evidence. We might think we're using reasonable evidence. For example, we might pull from recent memory bugs that we've experienced in the same code base. And this isn't all that bad of an idea. In fact, it might even be a good idea. Whatever bugs you had yesterday or probably going to look at least somewhat like bugs are going to have today. Because the same people who wrote the code that produced those bugs wrote the code that produced these bugs. But here's where this can go wrong. You could have had an extremely strange or rare occurrence that happened recently. You could have had a bug that was very unlikely to happen. Or you may have even heard about one from somebody else or read about it on hacker news or heard about it on a podcast. You may just have it in your mind. And because of something called recall bias or availability heuristic, you're going to recall this information as if it happens more often than it does. In other words, because you experienced it in some way, you're going to overestimate how likely it is that that is the cause of this particular issue that you're having. Now, this isn't the rule and we certainly aren't saying that you're going to be wrong about the way that you debug. Sometimes your experience and the connections that you're making with previous kind of pattern matching and that kind of thing are going to override. They're going to outweigh this recency bias that we've been talking about here. But this doesn't change the underlying mechanism of the problem, which is that our brains are always trying to make these connections. We're trying to create a story around the information that we have. And when the information doesn't make sense on its own, we have to connect the dots ourselves. And that is when the error happens. Sometimes in order to connect those dots, we draw on information that isn't totally reliable. We've talked about many ways that we develop unreliable information in our minds. For example, substituting questions. We've talked about that on the show in the past in particular. But however it happens, this unreliable information makes its way into the story. However, on the flip side, we should take a moment and appreciate the fact that we can do this. If we were constantly having to evaluate every single input as a raw piece of information that had no kind of collective picture with any other piece of input. If we had to take everything into account and calculate it all, we would be paralyzed with all of that work. Instead, we allow our brains to kind of do these automatic calculations. They're very rough, these heuristic movements. And on the other side, most of the time, we turn out in some functionally capable way. But when it matters the most, for example, when finding the bug is more important than creating something that we can understand, it helps to take measures that reduce this kind of storytelling. As a simple example, instead of just having one software engineer who is experiencing a bug that they created, try to fix that bug, we can bring in a second engineer to work alongside them. This allows some of that recency bias, the code that they were working on, for example, may no longer become part of that story. Or at least, you'll have a second voice that doesn't have the same recency bias as you. Instead of listening to each person's argument about why we should hire a particular candidate, instead of waiting until somebody else has had a chance to speak before we explain what we think, we might record that information. I think this is a recommendation I've given in a previous episode. The critical thing here is that we recognize that this is something that happens on a regular basis, and we try to identify the places where that could be detrimental. Once we understand where is it exactly that we need to be really clear about what is evident or what is something that we have very clear data on, versus where we kind of filling in those gaps. We have that picture. We can start to create ways of getting around some of that storytelling, and hopefully creating a clearer picture of reality. Thanks so much for listening to today's episode of Developer Tea. Thank you again to Doppler for sponsoring today's episode. More than 11,000 teams from small startups to enterprise level companies are relying on Doppler to keep their secrets and app configuration in sync. Go and check it out Doppler.com slash L slash Developer Tea that's D-O-P-P-L-E-R dot com slash the letter L slash Developer Tea. Thanks so much for listening to this episode. If you enjoyed this discussion, if you would like to talk more about excessive cohesion or maybe share your story of when you created a story about a bug or about a candidate or about something else with the other listeners of the show, please do that as in our Developer Tea Discord community. Head over to developertea.com slash discord to join for free today. Thanks so much for listening, and until next time, enjoy your tea.