What is the most effective way to make a living in astrology? Assuming this audience is representative of most adults in the United States, then about 25% of you possibly believe in astrology. If you don't know what astrology is, effectively is looking at celestial objects, things like stars or planets, and where they are in the sky relative to your position or relative to each other, and then using that information to determine something about your life now, or someone else's life now. Forgive me if my definition is lacking, but the data show that 25% of the population believe in astrology. They believe that it is valid, a valid way to think about events in their life. In today's episode, we're going to discuss a little bit about why the messages of astrology are somewhat persuasive or at least believable, and we're going to discuss how that applies to your code, not how your zodiac sign applies to your code, of course, but instead how you can believe something about your code that is really quite a generic answer. And we'll talk about when this actually happens. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on this show is to help driven developers become better at what they do and connect to their career purpose so they can have a positive influence on the people around them. For the most part, experts scientists would agree that astrology and its claims have been largely recognized as pseudoscience. This means that astrology claims to have some scientific backing, something underlying that is based on science, but in fact it is not science. It is in conflict with something in the scientific method. And we can get a sense for how this plays out. If I read you a few of these phrases, perhaps you think that this episode is personalized for you, and I'll go ahead and read them. Number one, you have a great need for other people to like and admire you. By the way, this is coming from a Wikipedia page. We'll talk about which Wikipedia page in just a moment. Number two, you have a tendency to be critical of yourself. And number three, you have a great deal of unused capacity in which you have not turned to your advantage. And number four, while you have some personality weaknesses, you're generally able to compensate for them. Now, there's a whole litany of these kinds of phrases that you probably resound with. You probably resound with these specific phrases that I pulled out. This is shown to be true in many studies on the subject that when someone believes that something that is beyond their understanding is in control of a given statement, they are more likely to believe that the statement is valid. And there's a couple of reasons for this that are likely. Number one is called the polyanna effect. This is essentially focusing on the positives and trying not to focus on the negative aspects of something. Number two is the fact that we are our own worst critic. So people simultaneously think very highly of themselves while also being quite critical of themselves and quite insecure. And lastly, we are essentially gullible. As long as we don't expect that someone is lying, then we tend to believe them. These aren't the only things that play into why these phrases are effective. Of course, the phrase itself must be kind of capturing these concepts. The idea of polyanna principle, the tendency for people to remember pleasant items more accurately than unpleasant ones or positive over negative. The phrase must reflect that principle. Of course, there are plenty of other biases that may play into this as well. Studies have shown that you can have a group of people and you provide them with a phrase like one of the ones that we've already mentioned on this show. You give them all the same phrase and then you have them rate just how personalized they believe that the phrase is. It turns out that most of them believe that the phrase is personalized. So it goes beyond just believing in astrology or another kind of pseudo-science, magical, fortune-telling kind of thing. And it goes into our psyche a little bit. It goes into how we perceive the world. This effect has a name. It's called the Barnum effect. The Barnum effect is indeed named after PT Barnum. It was coined by a psychologist named Paul Meal. Paul wrote an essay called Wanted. A Good Cookbook. In the essay, Meal criticizes these psychological tests. This is in 1956, various psychological tests. And he compares them to the kind of test that PT Barnum would give in his shows. So the idea is that there are certain ways, certain kind of beliefs that we may attribute to be more personalized than they actually are. And therefore, more applicable, more salient, more important to understand and to pay attention to, than just a generic statement that might be true and in fact is true about almost everyone. So how does this apply to our code? How do we understand how the Barnum effect can apply to our code? Well, first, we have to understand that while we are all unique human beings, we have very similar experiences. We have very similar kind of shapes to our lives. We also have typically very similar responses to circumstances. This is especially true for people who work in similar fields, have similar backgrounds, and live in similar cultures. Now, keep in mind that we're not claiming that everybody has the same taste or that they have the same perspective on all of the experiences, but rather that our experiences are all quite similar. And this is kind of a simple reality and much of our culture is based on this reality. We call it common ground. The idea that we can make a joke as developers, that other developers will understand because of their similar experiences. This is incredibly important to understand the Barnum effect and how it might play out in our careers, both at the absolute coding level when we're debugging, for example. And in higher level things like how we view ourselves and how confident we are as developers. So, we're going to try a few phrases out on this show that might exploit the same effect except for developers. And we're going to try three simple phrases and these probably won't resound as tightly to you as the previous ones, but let's go ahead and try them out anyway. The first one. You often feel that while you are incredibly competent in some areas, sometimes you go slow. So slow that you're afraid you aren't even qualified for your job. This leads you to fear losing your job security. A second phrase. While you enjoy coding, you've often wondered, what else you might be able to do well. phrase number three. While you didn't accomplish as much as you probably wanted to today, you can be proud of the accomplishments you did make and head in tomorrow with confidence. So these three phrases, if you dissect them from the perspective of the Barnum Effect, you can start to see how they might apply to everyone. For example, almost everyone at some point, they hit some kind of roadblock. They go slow while they're coding. So most people who have a job as developer, they have a job because they are at least competent enough to be valuable to an employer. So while you're competent in some areas, sometimes we're labeling a specific time, but sometimes you go slow. Sometimes you run into a bug. Sometimes you run into something that you just don't understand. And this can bring up feelings of imposter syndrome. It can make you feel like you aren't qualified for your job because you felt inadequate. In that moment, you were unable to solve the problem. And of course, these fears could very much so lead to fearing losing your job security. So that explains how the first phrase that we mentioned is essentially applicable to every developer. The second phrase, while you enjoy coding, you've often wondered what else you could do well. Of course you have. Humans consider alternative options on a regular basis very often. So if you weren't thinking of this, then you probably would when you read this particular phrase or when you hear this particular phrase, and you probably wouldn't reject it anyway. Because very few developers would point blanks say that they'll never be good at anything but code. Third and final phrase, while you didn't accomplish as much as you probably wanted to today, you can be proud of the accomplishments you did make and head into more with confidence. This is playing off of the reality that most people overestimate what they're able to do. Most people overestimate what they're going to accomplish in a given day. And so at the end of the day, you have a pretty good shot of guessing right if you guessed that someone didn't finish everything that they wanted to finish. So these things have implications to your careers. We've just shown this Barnum effect, the idea that you can believe something that is specific to you. And we aren't talking about astrology here, right? We're talking about reasoning. We're talking about experiences that you may have that you may feel are individual, but in fact, they are not. And you can experience a very similar thing when you are coding. This is especially prevalent when you're debugging an application or when you're refactoring an application. For example, imagine you receive feedback from your Q&A department or from customers or from users that says that the user experience is poor. It's very possible, if not likely, that your team will come to the conclusion that you need to optimize the speed of your application. This is very often true that speed has a major impact on usability and therefore on user experience. However, these kinds of conclusions are fairly easy to make and they're fairly easy to generalize to almost every scenario. Almost every scenario where a user, especially, is complaining about user experience. User experience often means that a team will try to optimize. And really what we're pointing out here is that sometimes we have reactions to scenarios, to bugs, to problems, to thoughts that we believe are mostly individual, that they are special, that they're somehow limited to us. And in fact, many times those responses are applicable in more than that scenario. Sometimes that means that those responses are not necessarily going to solve the problem directly. Instead, as we've talked about in previous recent episodes, those responses make sense. They are a good narrative. In the same way that a Barnum phrase would make sense to you and therefore you may believe that that phrase is special, that it's authoritative. These judgment calls that can be made in blanket form over multiple scenarios you may believe are much more insightful to your situation than they actually are. I hope today's episode was interesting and challenging. I hope that you will go and look into the Barnum effect. It's a little bit of a difficult concept to describe and to explain exactly how it filters down into our day-to-day work. Really you have to be on your guard for taking on kind of descriptions, easy descriptions, quick descriptions that seem to be diagnosing your problem and dissecting your problem well. But in reality, your brain is tricking you. Thank you so much for listening to today's episode of Developer Tea. If you're enjoying these episodes, I encourage you to subscribe in whatever podcasting app you're using right now to listen to this episode. Thank you so much for listening and until next time, enjoy your tea.