Vox

Leitura de 16 min

Astrology and The Barnum Effect

Summary

The episode begins by noting that about 25% of adults in the United States believe in astrology, which is widely considered a pseudoscience. The host, Jonathan Cottrell, explains that the persuasive power of astrology and similar practices stems from psychological biases rather than scientific validity. He introduces the concept of the Barnum effect, named after P.T. Barnum, where people believe vague, general statements are highly personalized descriptions of themselves.

Cottrell illustrates the Barnum effect by reading generic statements from a Wikipedia page, such as “you have a great need for other people to like and admire you” and “you have a tendency to be critical of yourself.” He explains that factors like the Pollyanna principle (focusing on positives), being our own worst critic, and general gullibility make us susceptible to believing these statements are uniquely tailored to us. This effect extends beyond astrology to many areas of life.

The discussion then applies the Barnum effect to software development. Cottrell creates three developer-specific Barnum statements: feeling incompetent at times despite overall competence, wondering about skills beyond coding, and not accomplishing daily goals as planned. He dissects why these resonate with most developers, linking them to common experiences like imposter syndrome, curiosity about alternatives, and overestimation of daily productivity.

Finally, Cottrell connects the Barnum effect to practical development scenarios, such as receiving user feedback about poor experience. Teams often jump to generic solutions like optimizing application speed, which may seem insightful but are actually broad responses applicable to many situations. The episode encourages developers to be wary of easy, blanket diagnoses for complex problems and to recognize when their perceived unique struggles are actually shared experiences.

Recommendations

Concepts

  • Barnum Effect — A psychological phenomenon where individuals believe vague, general statements are highly personalized descriptions of themselves, named after P.T. Barnum and coined by psychologist Paul Meehl.
  • Pollyanna Principle — The tendency for people to remember pleasant or positive items more accurately than unpleasant ones, which contributes to why Barnum statements are effective.

People

  • P.T. Barnum — The American showman after whom the Barnum effect is named, referenced for his style of entertainment that played on people’s beliefs.
  • Paul Meehl — The psychologist who coined the term ‘Barnum effect’ in a 1956 essay criticizing certain psychological tests, comparing them to P.T. Barnum’s shows.

Topic Timeline

  • 00:00:00 — Introduction to astrology and its prevalence — The host states that about 25% of US adults believe in astrology, which he defines as using celestial objects to determine things about life. He frames the episode’s goal: to explore why astrological messages feel persuasive and how this relates to developers’ beliefs about their code. The host introduces himself as Jonathan Cottrell of Developer Tea.
  • 00:01:37 — Astrology as pseudoscience and the Barnum effect — Cottrell notes experts consider astrology pseudoscience. He reads generic, flattering statements (e.g., “you have a great need for other people to like and admire you”) to demonstrate how people believe vague descriptions are personalized. He explains psychological reasons: the Pollyanna effect (focusing on positives), being self-critical, and gullibility. This phenomenon is named the Barnum effect, after P.T. Barnum, coined by psychologist Paul Meehl in 1956.
  • 00:05:57 — Applying the Barnum effect to developers — The host transitions to how the Barnum effect applies to developers. He emphasizes that while individuals are unique, developers share similar experiences and backgrounds, creating common ground. He states the effect influences both low-level coding (debugging) and high-level self-perception (confidence).
  • 00:07:17 — Developer-specific Barnum statements — Cottrell tests three Barnum-style phrases tailored for developers: 1) Feeling competent but sometimes slow, leading to fear about job security; 2) Enjoying coding but wondering what else you could do; 3) Not accomplishing daily goals but being proud of progress. He analyzes why each is broadly applicable, linking them to imposter syndrome, human curiosity, and overestimation of daily productivity.
  • 00:10:50 — Practical implications in development work — The discussion connects the Barnum effect to concrete development scenarios, like receiving user feedback about poor experience. Teams often generically conclude they need to optimize application speed—a common, seemingly insightful response that may not address the specific problem. Cottrell warns that developers can mistake these blanket judgments for deep insights into their unique situation.
  • 00:13:02 — Conclusion and call to action — Cottrell hopes the episode was challenging and encourages listeners to research the Barnum effect further. He advises developers to guard against accepting easy, generic descriptions that seem to diagnose their problems accurately. He thanks the audience and prompts them to subscribe to Developer Tea.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-07-13T09:00:00Z
  • Duration: 00:13:51

References

Podcast Info

Transcript

[00:00:00] Assuming this audience is representative of most adults in the United States,

[00:00:10] then about 25% of you possibly believe in astrology. If you don’t know what astrology is,

[00:00:18] effectively is looking at celestial objects, things like stars or planets, and where they

[00:00:24] are in the sky relative to your position or relative to each other, and then using that

[00:00:29] information to determine something about your life now or someone else’s life now.

[00:00:36] Forgive me if my definition is lacking, but the data show that 25% of the population believe

[00:00:45] in astrology. They believe that it is valid, a valid way to think about events in their life.

[00:00:53] In today’s episode, we’re going to discuss a little bit about why the messages of astrology

[00:00:59] are so important to us. And we’re going to talk about why they’re so important to us.

[00:00:59] Are somewhat persuasive, or at least believable. And we’re going to discuss how that applies to

[00:01:05] your code. Not how your zodiac sign applies to your code, of course, but instead how you can

[00:01:12] believe something about your code that is really quite a generic answer. And we’ll talk about when

[00:01:17] this actually happens. My name is Jonathan Cottrell, and you’re listening to Developer T.

[00:01:21] My goal on this show is to help driven developers become better at what they do and connect to their

[00:01:26] career purpose so they can have a positive influence on the future. And I’m going to talk

[00:01:29] around them. For the most part, experts, scientists would agree that astrology and its

[00:01:37] claims have been largely recognized as pseudoscience. This means that astrology claims to

[00:01:44] have some scientific backing, something underlying that is based on science, but in fact, it is not

[00:01:51] science. It is in conflict with something in the scientific method. And we can get a sense for how

[00:01:58] this plays out. If I read you a few of these phrases, perhaps you think that this episode is

[00:02:04] personalized for you. And I’ll go ahead and read them. Number one, you have a great need for other

[00:02:11] people to like and admire you. By the way, this is coming from a Wikipedia page. We’ll talk about

[00:02:16] which Wikipedia page in just a moment. But number two, you have a tendency to be critical of

[00:02:22] yourself. And number three, you have a great deal of unused capacity, which you have not

[00:02:28] turned to your advantage. And number four, while you have some personality weaknesses,

[00:02:34] you’re generally able to compensate for them. Now, there’s a whole litany of these kinds of

[00:02:41] phrases that you probably resound with. You probably resound with these specific phrases

[00:02:47] that I pulled out. And this is shown to be true in many studies on the subject,

[00:02:55] that when someone believes that

[00:02:58] something that is beyond their understanding is in control of a given statement, they are more

[00:03:05] likely to believe that the statement is valid. And there’s a couple of reasons for this that are

[00:03:11] likely. Number one is called the Pollyanna effect. This is essentially focusing on the positives and

[00:03:18] trying not to focus on the negative aspects of something. Number two is the fact that we are

[00:03:25] our own worst critic. So people,

[00:03:28] simultaneously, think very highly of themselves while also being quite critical of themselves and

[00:03:35] quite insecure. And lastly, we are essentially gullible. As long as we don’t expect that

[00:03:45] someone is lying, then we tend to believe them. These aren’t the only things that play into why

[00:03:51] these phrases are effective. Of course, the phrase itself must be kind of capturing this

[00:03:58] these concepts, the idea of Pollyanna principle, the tendency for people to remember pleasant items

[00:04:06] more accurately than unpleasant ones, or positive over negative. You know, the phrase must reflect

[00:04:13] that principle, right? And of course, there are plenty of other biases that may play into this

[00:04:18] as well. And so studies have shown that you can have a group of people and you provide them with

[00:04:25] a, you know, a phrase like one of the ones that we call the Pollyanna principle. And so,

[00:04:28] we’ve already mentioned on this show, you give them all the same phrase, and then you have them

[00:04:32] rate just how personalized they believe that the phrase is. It turns out that most of them believe

[00:04:38] that the phrase is personalized. So it goes beyond just believing in astrology or another kind of

[00:04:46] pseudoscience, magical, you know, fortune telling kind of thing. And it goes into our

[00:04:52] psyche a little bit. It goes into how we perceive the world. Now, this effect has a name. It’s

[00:04:58] called the Barnum effect. And the Barnum effect is indeed named after P.T. Barnum. And it was coined

[00:05:05] by a psychologist named Paul Meele. Paul wrote an essay called Wanted, a good cookbook. In the essay,

[00:05:13] Meele criticizes these psychological tests. This was in 1956, various psychological tests.

[00:05:21] And he compares them to the kind of test that P.T. Barnum would give in his show.

[00:05:28] So the idea is that there are certain ways, certain kind of beliefs that we may attribute to

[00:05:35] be more personalized than they actually are, and therefore more applicable, more salient,

[00:05:42] more important to understand and to pay attention to than just a generic statement that might be

[00:05:49] true, and in fact is true, about almost everyone. So how does this apply to our code? How do we

[00:05:57] understand how the world works? How do we understand how the world works? How do we

[00:05:58] Barnum effect can apply to our code? Well, first, we have to understand that while we are all unique

[00:06:05] human beings, we have very similar experiences. We have very similar kind of shapes to our lives,

[00:06:12] and we also have typically very similar responses to circumstances. This is especially true for

[00:06:20] people who work in similar fields, have similar backgrounds, and live in similar cultures.

[00:06:28] Now, keep in mind that we’re not claiming that everybody has the same taste or that they have

[00:06:32] the same perspective on all of the experiences, but rather that our experiences are all quite

[00:06:39] similar. And this is kind of a simple reality, and much of our culture is based on this reality.

[00:06:46] We call it common ground, the idea that we can make a joke as developers that other developers

[00:06:52] will understand because of their similar experiences. This is incredibly important,

[00:06:58] to understand the Barnum effect and how it might play out in our careers, both at the absolute

[00:07:04] coding level, when we’re debugging, for example, and in higher level things like how we view

[00:07:10] ourselves and how confident we are as developers. So we’re going to try a few phrases out on this

[00:07:17] show that might exploit the same effect, except for developers. We’re going to try three simple

[00:07:24] phrases, and these probably won’t resound as tightly.

[00:07:28] to you as the previous ones, but let’s go ahead and try them out anyway.

[00:07:33] The first one, you often feel that while you are incredibly competent in some areas,

[00:07:38] sometimes you go slow, so slow that you’re afraid you aren’t even qualified for your job.

[00:07:43] This leads you to fear losing your job security. The second phrase, while you enjoy coding,

[00:07:50] you’ve often wondered what else you might be able to do well. Phrase number three,

[00:07:58] while you didn’t accomplish as much as you probably wanted to today, you can be proud

[00:08:03] of the accomplishments you did make and head in tomorrow with confidence.

[00:08:09] So these three phrases, if you dissect them from the perspective of the Barnum effect,

[00:08:16] you can start to see how they might apply to everyone. For example, almost everyone at some

[00:08:23] point, they hit some kind of roadblock. They go slow. They go slow. They go slow. They go slow.

[00:08:28] While they’re coding. And so most people who have a job as developer, they have a job because they

[00:08:34] are at least competent enough to be valuable to an employer. So while you’re competent in some areas,

[00:08:42] sometimes we’re, you know, labeling a specific time, but sometimes you go slow. Sometimes you

[00:08:49] run into a bug. Sometimes you run into something that you just don’t understand. And this can bring

[00:08:57] up feelings of imposter syndrome. It can make you feel like you aren’t qualified for your job

[00:09:02] because you felt inadequate. In that moment, you were unable to solve the problem. And of course,

[00:09:11] these fears could very much so lead to fearing losing your job security. So that explains how

[00:09:19] the first phrase that we mentioned is essentially applicable to every developer. The second phrase,

[00:09:24] while you enjoy coding, you’ve often wondered,

[00:09:26] what else you could do well. Of course you have. Humans consider alternative options on a regular

[00:09:33] basis very often. So if you weren’t thinking of this, then you probably would when you read this

[00:09:40] particular phrase or when you hear this particular phrase, and you probably wouldn’t reject it

[00:09:45] anyway, right? Because very few developers would point blank say that they’ll never be good at

[00:09:52] anything but code. Third and final phrase,

[00:09:56] This is playing off of the reality that most people overestimate what they’re able to do.

[00:10:11] Most people overestimate what they’re going to accomplish in a given day. And so at the end of

[00:10:16] the day, you have a pretty good shot of guessing right if you guess that someone didn’t finish

[00:10:21] everything that they wanted to finish. So these things have implications to your job security.

[00:10:26] As we’ve just shown, this Barnum effect, the idea that you can believe something that is specific

[00:10:33] to you. And we aren’t talking about astrology here, right? We’re talking about reasoning. We’re

[00:10:38] talking about experiences that you may have that you may feel are individual, but in fact,

[00:10:45] they are not. And you can experience a very similar thing when you are coding. This is

[00:10:50] especially prevalent when you’re debugging an application or when you’re refactoring an

[00:10:55] application.

[00:10:56] For example, imagine you receive feedback from your Q&A department or from customers or from

[00:11:03] users that says that the user experience is poor. It’s very possible, if not likely, that

[00:11:11] your team will come to the conclusion that you need to optimize the speed of your application.

[00:11:17] This is very often true that speed has a major impact on usability and therefore on user

[00:11:23] experience. However, these kinds of conclusions,

[00:11:26] fairly easy to make, and they’re fairly easy to generalize to almost every scenario. Almost

[00:11:34] every scenario where a user especially is complaining about user experience. User

[00:11:40] experience often means that a team will try to optimize. And really what we’re pointing out here

[00:11:47] is that sometimes we have reactions to scenarios, to bugs, to problems, to thoughts that we believe

[00:11:56] are not true. And so we’re going to try to optimize that. And we’re going to try to optimize that.

[00:11:56] And we’re going to try to optimize that. And we’re going to try to optimize that. And we’re going to

[00:11:57] try to optimize that. And we’re going to try to optimize that. And we’re going to try to optimize that.

[00:11:57] Mostly individual, that they are special, that they’re somehow limited to us. And in fact,

[00:12:04] many times, those responses are applicable in more than that scenario. Sometimes that means

[00:12:12] that those responses are not necessarily going to solve the problem directly.

[00:12:19] Instead, as we’ve talked about in previous recent episodes, those responses make sense.

[00:12:26] They are a good narrative. In the same way that a Barnum phrase would make sense to you,

[00:12:35] and therefore you may believe that that phrase is special, that it’s authoritative,

[00:12:42] these judgment calls that can be made in blanket form over multiple scenarios,

[00:12:50] you may believe are much more insightful to your situation than they actually are.

[00:12:57] I hope today’s episode was interesting and challenging. I hope that you will go and look

[00:13:02] into the Barnum effect. It’s a little bit of a difficult concept to describe and to explain

[00:13:07] exactly how it filters down into our day-to-day work. Really, you have to be on your guard for

[00:13:15] taking on kind of descriptions, easy descriptions, quick descriptions that seem to be diagnosing your

[00:13:23] problem and dissecting your problem well.

[00:13:26] Thank you so much for listening to today’s episode of Developer Tea. If you’re enjoying

[00:13:34] these episodes, I encourage you to subscribe in whatever podcasting app you’re using right now

[00:13:39] to listen to this episode. Thank you so much for listening, and until next time, enjoy your tea.

Visão de gráfico