Vox

Leitura de 15 min

A Problem Solving Paradox

Summary

In this episode of Developer Tea, host Jonathan Cattrell delves into a psychological phenomenon known as ‘prevalence-induced concept change,’ where our definition of a problem expands as we make progress solving it. He references a Harvard University study where participants identifying blue dots began classifying previously ‘purple’ dots as blue as the actual blue dots diminished, demonstrating how our perception shifts even when we’re aware of the bias.

Cattrell connects this phenomenon to software development, illustrating how it can manifest in endless refactoring loops where code never feels perfect enough, or in the paralysis of choosing a programming language as research reveals flaws in every option. The core paradox is that as we reduce a problem’s prevalence, our conceptualization of it grows, making us feel like we’re making no headway.

To combat this, Cattrell suggests two main strategies. First, leverage diversity by collaborating with people who have different backgrounds and perspectives. Their differing viewpoints can help identify blind spots and provide a more balanced picture of problem evolution and progress. Second, establish clear rubrics or acceptance criteria to define what ‘solved’ means for a given problem, which helps prevent over-investment of energy and provides a clear stopping point.

He cautions that metrics must be chosen carefully to avoid ‘vanity metrics’ that can be gamed without solving the underlying issue, using the example of fake reviews to artificially boost a company’s online rating. The episode concludes with the reminder to continuously ask oneself, ‘Am I doing the most important thing I can be doing right now?’ as a key question for career advancement.

Recommendations

Companies

  • Reaktor — The episode’s sponsor, a digital product studio with Finnish heritage based in New York City. They partner with companies like HBO, Supercell, Viacom, and Finnair, and are hiring developers.

Studies

  • Harvard University study on prevalence-induced concept change — The core research discussed in the episode, which demonstrated how people expand their definition of a problem (like identifying ‘blue’ dots) as the problem’s prevalence decreases.

Topic Timeline

  • 00:00:00 — Introduction to how problems and memories change over time — Jonathan Cattrell introduces the episode’s theme: how problems change over time. He references the philosophical and neurological idea that experiences and memories are not static. He states the episode will explore ‘prevalence-induced concept change,’ where our definition of a problem expands as we work on it.
  • 00:01:07 — Explanation of the blue dot study demonstrating the phenomenon — Cattrell details a study where participants were asked to identify blue dots on a screen. As the actual number of blue dots decreased, participants began classifying dots they previously called ‘purple’ as blue. This happened even when incentives were introduced to avoid false positives, showing the bias persists despite awareness.
  • 00:03:51 — Defining ‘prevalence-induced concept change’ and its developer implications — The phenomenon is formally named: prevalence-induced concept change. It causes people to redefine problems as they are reduced or solved. Cattrell explains how this can make developers feel they are making no progress, as the goalposts seem to move. He transitions to discussing practical implications for software developers.
  • 00:05:10 — Practical examples: endless refactoring and language choice paralysis — Cattrell gives two developer-specific examples. First, in refactoring, you may continuously find new ‘cracks’ and refactor already-refactored code in an endless pursuit of perfection. Second, a new developer choosing a language may research JavaScript, then Go or Python, only to find problems with each, causing the initial problem (‘learn a language’) to expand frustratingly.
  • 00:06:52 — Strategy 1: Combat bias with diversity of thought — The first proposed strategy to combat this bias is to connect with people who are not like you. Cattrell emphasizes that diversity in background, experience, gender, and even preferences provides differing perspectives. These perspectives help address blind spots and give a better, consensus-driven picture of how a problem is truly evolving.
  • 00:08:22 — Strategy 2: Establish rubrics and acceptance criteria — The second strategy is to identify a clear rubric or acceptance criteria that defines when a problem is ‘solved.’ This creates a stopping point and prevents over-investment of energy. Cattrell warns of the risk of ‘vanity metrics’—like aiming for a 4.5-star review average—which can be gamed (e.g., with fake reviews) without solving the real problem.
  • 00:10:44 — Conclusion and the key question for career advancement — Cattrell concludes by reiterating the importance of vigilance against this psychological phenomenon. He suggests leaning on others, using explicit success definitions, and continuously asking a key career-advancement question: ‘Am I doing the most important thing I can be doing right now?’ He credits the Harvard study and thanks the sponsor, Reactor.

Episode Info

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

References

Podcast Info

Transcript

[00:00:00] you’re probably familiar with the philosophy that things change over time the idea that

[00:00:10] an experience is different if you have it one day followed by the next day and that when you

[00:00:16] revisit your memories even your memories change even at a neurological level this has been kind

[00:00:24] of shown to be the case in today’s episode we’re talking about how problems change over time

[00:00:29] my name is jonathan cattrell and you’re listening to developer t and my goal on this show is to help

[00:00:34] driven developers connect to their career purpose so they can do better work and ultimately have a

[00:00:39] positive influence on the people around them so in today’s episode we’re talking about this idea

[00:00:45] that problems change over time and more specifically this is coming from some research that came out

[00:00:51] recently the idea is that problems gain new definitions we expand our definitions of problems

[00:00:59] as we revisit that problem over and over in the study for example they had some of the the

[00:01:07] participants of the study they looked at a screen and they were told to identify the blue dots on

[00:01:11] the screen and as the blue dots diminished in other words as the problem’s prevalence was lowered

[00:01:17] the dots that they previously had classified as purple they started classifying as blue

[00:01:25] now this even occurred when they added an incentive

[00:01:29] okay an incentive to not have any false positives in other words if they were to

[00:01:36] not get any of them wrong right even if they didn’t get all of the right ones

[00:01:41] then the incentive was a little bit of cash right of course the study is is much larger scale than

[00:01:48] this as we solve larger problems our definition of those problems change so what does this

[00:01:56] ultimately mean for developers and what are some ways that we might be able to

[00:01:59] combat this problem we’re going to talk about that right after we talk about today’s awesome

[00:02:04] sponsor reactor a reactor is a digital product studio based in new york city and it’s spelled

[00:02:11] with a k i’ve said this on every episode that reactor is sponsored but i want to explain a

[00:02:17] little bit more reactor is spelled with a k rather than a c because it started as a finnish company

[00:02:23] a company based in finland and they of course have moved to

[00:02:29] a product studio based out of new york city as we’ve already mentioned but

[00:02:33] this finnish heritage is actually really important to this company for example if you decide to go

[00:02:38] and work at reactor on your first day reactor is going to tell you to eat a cinnamon roll and give

[00:02:46] you a cup of coffee and quite literally they’re going to say something along the lines of what’s

[00:02:50] the rush we’ve already filled out the paperwork and it’s time to essentially get to know each

[00:02:55] other right and this is indicative of the culture of the company and it’s going to tell you what’s

[00:02:59] at reactor now before you think oh well then of course they’re not really getting anything done

[00:03:03] they’ve partnered with companies like hbo supercell and viacom even a big airline finn air

[00:03:11] of course that’s finnish of the finn air they designed and built the perfect digital

[00:03:17] customer journey complete with their own mobile applications and the in-flight entertainment

[00:03:23] system and they revolutionized their onboard connectivity so reactor is looking

[00:03:29] for software developers they’re looking for people like you now instead of going and finding a role

[00:03:34] they want you to come and explain to them your skills your experience your ambitions and

[00:03:40] ultimately your dream role head over to reactor.com remember that’s with a k reactor.com slash careers

[00:03:46] to get started today thank you again to reactor for sponsoring today’s episode of developer t

[00:03:51] so we’re talking about this strange phenomenon that has recently been studied and the name of

[00:03:58] this phenomenon by the way is reactor t and it’s a phenomenon that’s been studied for a long time

[00:03:59] is it’s a mouthful it’s called prevalence induced concept change this causes people

[00:04:06] to redefine problems as they are reduced in other words as the problem changes and specifically as

[00:04:12] the problem is solved as it becomes smaller people start to redefine the problem because

[00:04:18] we start to discover more about the problem we start having a more expanded definition of that

[00:04:23] problem right we we redefine the issue and so as we begin to solve it we start to redefine the issue

[00:04:29] and so as we begin to solve it we start to redefine the issue and so as we begin to solve it we start to

[00:04:30] as though we’re making no headway right that’s one feeling that you may get

[00:04:35] when you are falling to this kind of strange psychological phenomenon the research goes on

[00:04:40] to say that even when you’re aware that this is happening and even when you’re trying to prevent

[00:04:45] it from happening it still tends to happen so we’re going to talk more theoretically about

[00:04:50] ways that we may be able to prevent this or at least address it right and and the hope is that

[00:04:56] we wait things in the future to make it happen and we’re going to talk more about the future of

[00:04:59] in a particular direction so that even if we can’t necessarily fix the bias, we’re at least

[00:05:04] addressing it by biasing in a different direction. Now, at a more practical level, how does this

[00:05:10] actually play out for developers? Well, it may play out in your refactoring, right? If you start

[00:05:15] to refactor code, then as you refactor that code, you may refactor continuously, and it may never

[00:05:22] feel like you’ve refactored enough. And as you find more cracks in the code, as you discover more

[00:05:29] things that you’ve written that you prefer you had written it differently, perhaps new ways of

[00:05:35] thinking will emerge just by refactoring. And then you’ll refactor the code that you’ve already

[00:05:40] refactored, and eventually you get into this kind of endless loop seeking the perfect code, which

[00:05:46] unfortunately you’re never going to find. This could also be an issue that new developers

[00:05:52] face when they’re choosing a language to learn. You may have the concept in your mind that you

[00:05:59] need to find a language, and this is the problem that you’re solving. You need to find a language

[00:06:04] to learn. And so you do some research, and you realize that maybe JavaScript is a good language

[00:06:11] to learn, right? This is a safe bet. But as you do more research, you find that JavaScript has

[00:06:17] its problems. And so you decide, well, maybe I’m going to look somewhere else, and you choose Go

[00:06:22] or something like that. And so you do some research, and you find that JavaScript has its problems.

[00:06:22] Or Python. And then you do some more research, and you find out that Go has its problems, or that

[00:06:27] Python has its problems. So as you choose languages to learn, right, as your problem, your original

[00:06:34] problem, which is I need to learn a language, a programming language, as you choose the languages

[00:06:39] that you want to learn, that problem space becomes smaller, but now things are getting bigger. Your

[00:06:45] problem is getting larger. It’s kind of this strange paradox, right? So how do we address this?

[00:06:51] How can we bias ourselves?

[00:06:52] How can we bias ourselves in the opposite direction? Well, we’ve talked about this on the show many times

[00:06:56] before. Many of the ways that you can address bias is to connect with people who are not like you.

[00:07:03] This is one of the reasons, at a fundamental kind of scientific level, why diversity is so important.

[00:07:09] People with different backgrounds, different life experiences, different ages, certainly different

[00:07:14] genders, and even things like preferences, simple preferences, their musical preferences. These

[00:07:21] things, these pieces of what we call diversity, they’re not just useful because we want to be

[00:07:27] representative of our culture, which is true. It’s also useful because with those differing

[00:07:33] perspectives, we can actually address some of these blind spots that we otherwise wouldn’t be

[00:07:38] able to address. So one of the first steps in avoiding the prevalence-induced concept change,

[00:07:45] right, avoiding this expanding problem issue,

[00:07:51] is to have other people who think differently from you, and have them looking at the same

[00:07:56] problem that you’re looking at. When you have a consensus with multiple people, and perhaps

[00:08:01] everyone’s version of the problem is changing, but it’s changing in different directions,

[00:08:06] now you may have a better picture of how this problem is evolving. It may not be that the

[00:08:13] problem is perfectly solved yet, but rather, you can identify that progress has been made

[00:08:18] when those definitions begin to change.

[00:08:22] A second way of approaching this issue is to identify a rubric, right? So what you want to do

[00:08:30] is, and we’ve talked about this in recent episodes, ways of making better choices. What you want to do

[00:08:35] is identify your rubric, and this is essentially like when you identify acceptance criteria. If

[00:08:40] you’re familiar with acceptance criteria, the concept is, once these things are true,

[00:08:45] then this particular task is complete. This helps you prevent

[00:08:51] way too much energy, or too little energy, to a problem, right? So if you have your acceptance

[00:08:57] criteria met, it’s imperative that you move on to the next thing. So this is important. When we’re

[00:09:04] identifying problems, if we set up for ourselves the definition of solved, what exactly are the

[00:09:11] markers that we’re trying to hit? Of course, the risk here is that you’re going to set up vanity

[00:09:16] metrics if you’re not careful, and there are multiple ways to affect those vanity metrics.

[00:09:20] Let’s prove this with a simple example. Let’s say that you’re trying to increase the opinion

[00:09:27] about company A. You’re trying to improve and increase the positive opinions about company A.

[00:09:35] And one of the metrics that you set up is online reviews. You want the average online reviews to be

[00:09:41] above a 4.5, right? Out of five stars. This is a very common scenario. Then it may be tempting

[00:09:47] to solve this problem with a positive opinion. So if you’re trying to improve and increase the

[00:09:50] by deploying a bunch of fake reviews. Now, this isn’t actually solving the problem,

[00:09:56] but if you’re only measuring the problem solution based on a particular metric,

[00:10:01] you may be able to affect that metric in a way that isn’t actually solving the original problem

[00:10:07] at all. So it’s important to remember, once again, that this strange phenomena, I don’t know that

[00:10:14] it’s necessarily a bias, but it is certainly a psychological phenomena, that this happens even

[00:10:20] if you’re not aware of it. So it’s important to stay vigilant and to try as many strategies as you

[00:10:26] can to bias in the opposite direction. Lean on other people, provide yourself with much more

[00:10:32] explicit information about how you are going to consider a problem solved or not solved,

[00:10:38] and ultimately continuously remind yourself of the most important thing that you can be doing.

[00:10:44] This is the key question for advancement in any career path. Ask yourself,

[00:10:50] on a regular basis, more than once a day, am I doing the most important thing that I can be doing

[00:10:56] right now? Thank you so much for listening to today’s episode of Developer Tea. I hope you’ve

[00:11:01] enjoyed this discussion. Of course, credit for this study, the original study, goes to Harvard

[00:11:07] University. I found this through Science Daily and Reddit is how I found this content and the

[00:11:13] study itself. Thank you so much for listening. Thank you again to today’s sponsor, Reactor.

[00:11:17] Without our sponsors, we couldn’t continue making this show,

[00:11:20] I encourage you, if you are looking for a job and you’re a developer, go and check out Reactor.

[00:11:24] It’s reactorwithak.com slash careers. Thank you again to Reactor. Thanks so much for listening.

[00:11:30] If you’re enjoying these episodes of Developer Tea, go and subscribe in whatever podcasting

[00:11:35] app you’re using right now. We release three episodes a week, so it’s very easy to get behind.

[00:11:41] Make sure you go and subscribe. Thanks so much for listening, and until next time, enjoy your tea.

[00:11:50] Bye.

Visão de gráfico