If you've ever listened to a motivational speaker or even this podcast from time to time, you have probably heard the statement that your aptitude or your ability to grow, your ceiling is determined by your attitude or your beliefs, your ability to envision that growth. In today's episode, we're going to talk about this a little bit further, but instead of talking about it from the perspective of motivation, we're going to talk about it from the perspective of perception and how we may be missing things. This is going to apply at a very practical level to the way that you write code and the way that you debug that code, but it will also apply at a much broader level to the way that you communicate with other people and the way you operate in general. I'm really excited about this topic. It's a broad-reaching discussion on cognition today on Developer Tea. My name is Jonathan Cutrell and I'm the host here on Developer Tea. My goal is to help you connect to your career purpose and to help you do better work so you can have a positive influence on the people around you. In order to do good work and in order to understand what you care about, your purpose, your passion, the underlying things that you care so much about yourself, it's important to understand yourself. More specifically, to understand how your brain works, how you work, how you see the world. That's what we're talking about in today's episode. There's a series of videos out there that I encourage you to go and watch to kind of experience this stuff for yourself. The concept is called selective attention. I don't want to give away anything to anyone who hasn't seen these videos so I encourage you. Go ahead and pause this episode because there's going to be some spoilers in here that will ruin the bit of illusion, the psychological effect that we're trying to outline. Go ahead and pause this if you want to go and watch those first. The idea is simple. In all of these videos, the concept is to show selective attention as well as inattentional blindness. Both of these concepts are essentially the same thing, but you can go and find this if you've got the invisiblegrilla.com. There's quite a few good illusions there. One of the most commonly cited ones comes from a video from 1999. Essentially, you're asked to watch the basket ball being passed around by a group of people and count the number of times that it's passed. Of course, focusing on the ball, you miss something as you might be able to guess. You miss a person in a monkey suit and a grilla suit walking across the screen. The sound's crazy. It seems like that would be really obvious to you. You would see it happening, and yet it's so easy to miss. Now how is this possible? Why are we talking about this on developer T? Well we won't get into the mechanics of why it's possible on today's show because, quite honestly, I don't have a perfect answer for that. I don't think that psychologists totally understand why. We know that we can observe this. We can watch this in multiple studies, multiple scenarios that's been shown over and over and over. Even though most of the time, these biases are best shown in visual environments. They also happen outside of visual environments. Our attentional blindness is not just about what we see, but also just what we put our attention on. Now, hopefully you can start to see how this is going to show up in your day-to-day work inside your code. But I want to talk about one other perception phenomenon, a psychological phenomenon, that will affect the way that you code as well. That's called expectancy, cognitive expectancy. This is different from expectancy theory, which is talking about motivations. In this scenario, we're talking about cognitive expectancy in terms of what you expect to see versus what you actually see. This isn't only seeing, by the way, it's perceiving in some way. It's feeling or hearing. This can be a really powerful experience. So, there's a couple of good examples of this. One that is very popular, recent phenomenon. Last year, the gold or blue dress, this perception. And once you see it in one direction, it's hard to see it in the other direction. Once you see it as blue, it's hard to see it as gold and vice versa. And even more recently, with Yanny and Laurel from that audio clip. And sometimes we actually get clarity on what the actual word is or what's in the picture that we're looking at. The interesting thing that's happening here, specifically as it relates to the hearing, the word, and then not being able to return to your previous hearing of that word, is cognitive expectation. And there's a really excellent article about this exact phenomenon that you can experience a little bit more thoroughly if you go to the Atlantic. The article is called a sound you can't unhere, and what it says about your brain. And this impacts the expectancy, the cognitive expectancy. And what you're hearing is essentially a filtered voice. And it's very difficult to make out anything reasonable. And then you hear the unfiltered recording of that same voice saying the same thing. And then when you hear the filtered version again, you now can understand what's happening. The original filtered recording, you're going to be able to make sense of it. You can hear what's actually being said, even though previously you couldn't. And this permanence, the fact that you've experienced this, this expectancy, cognitive expectancy, is a really powerful phenomenon. It happens in other arenas too. And so when we combine all of these psychological phenomena and perceptive phenomena, we can kind of build a picture that helps us operate a little bit better. We're going to expect something in what we expect changes what we perceive. What we are focusing on changes what we perceive. This is a good explanation as to why that very simple bug keeps on going missed. That you keep on looking at the same exact code and something's wrong, but you can't figure out what it is. It's like you have some blind spot, right? This explains some of that blind spot that you are focusing on something. And maybe you didn't even realize what you're expecting or you don't even realize what you're focusing on. But because you have that expectation or because you have that specific focus, something else is slipping by. And for some reason, specifically when writing code that solves some kind of algorithmic challenge, right? Some kind of code golf challenge. I seem to not understand why my code is not producing the output that I was. And we're going to talk very quickly about two antidotes to the psychological phenomenon. And the first one, it shouldn't come as a surprise, getting someone else's opinion. This is one of the reasons pair programming can be so powerful, so important. And is to have someone else looking over your shoulder so that when you have that in attention, blindness or that selective attention or when you fall prey to this expectancy bias, someone else may not have that same expectation. Someone else may not have the same focus that you have. They may be focused on something different or they may be actually focusing on trying to catch a bug rather than solving the problem. And so you have two different kind of parallel processes. If you want to talk about that as a metaphor, two brains, one brain is processing on this particular thread and this other person, your pair programmer, they're processing something entirely different. If you've ever paired programs, you've probably experienced this phenomenon. For a lot of the time, the pair programmer may be providing very simple suggestions. Like for example, maybe we should change that variable name or have you thought about using a module instead of a class or providing some kind of test case that the primary person that's driving at that moment wouldn't necessarily provide. But then every once in a while, there's a moment where the pair programmer catches something that the primary driving programmer didn't catch. And this is very often between this kind of gap, this attentional blindness gap or the expectancy bias, this cognitive expectancy gap. The next antidote doesn't require another person, but it does require you to think a little bit differently, to shift your mindset a little bit. And usually what this means is taking away assumptions and context, backing up, zooming out a little bit, and then re-approaching whatever it is that you're implementing, the code you're writing, whatever it is that you're doing, and talking through it from top to bottom. Don't skip anything, don't assume anything. As you talk through it, you can even find good points to kind of verify and check that things are going how you assume they're going, use some kind of logging, some kind of inspection techniques. This can be really helpful. So as you're walking through, very often what you'll find is that you've missed something that again seems obvious when you walk through it one step at a time. This is often referred to as duck debugging, but I want to add this extra bit of zooming out a little bit. Very often we kind of jump to a small portion of the code that we think needs to be explained. The duck debugging procedure. We focus it only on one area that we already come in with the assumption that this is the area of the code that is broken or that's producing something unexpected. Often we find that the bug is actually somewhere else. And we expected, once again, that cognitive expectation, we expected the bug to be in this piece of code, this kind of siloed area that we're only evaluating this area. Perhaps because this is the area that we've been working on most recently, we expect that the bug came from this area. And often it takes a long time before we look anywhere else. If you simply zoom out one level or even two levels. So for example, if you're debugging part of a method, zoom out to the whole method or perhaps one layer further, where is this method being called? Zoom out a little bit further to what is the context, where this method is being called. Is there anything else that may be affecting the way that this method works? And hopefully from this perspective, from the zoomed out perspective, it's not that much of a difference in time to walk through a little bit of extra code. Very often it can save you loads of time simply by catching a bug that you didn't expect. Now here's the interesting thing about these psychological phenomena. They're not only applicable in concrete scenarios like writing code. Of course they're going to be applicable in your meetings with clients or with co-workers. If you walk into the meeting with a particular expectation, you may miss a hugely important piece of information that you just didn't expect to get. The same is true with attentional blindness. You may be missing something because of your focus on a different thing. And avoiding these has very similar types of antidotes. Having other people check you is one of the most important antidotes. And if you want to take away anything from this episode, it is to consider the perspective of others, even if it's just to defeat this attentional blindness phenomenon. Thank you so much for listening to today's episode of Developer Tea. My name is Jonathan Cutrell. Once again, you can find me on Twitter at at J. Cutrell. You can also find the show on Twitter at at Developer Tea. Thank you so much for listening. Thank you to BitRise for sponsoring today's episode. If you develop mobile apps, then I encourage you to check out what BitRise has to offer. They do mobile continuous integration and delivery for you and your team. Head over to spec.ofimslush.bitRise to get started today. Thank you so much again for listening to the show on a regular basis. The best way to get Developer Tea and not miss out on future episodes is to subscribe wherever you are listening right now. Until next time, enjoy your tea.