In today's episode, we're talking about the paradox that happens when we get caught up seeking the perfect code. How do we address this and get past our own assumptions?
In today's episode, we're talking about the paradox that happens when we get caught up seeking the perfect code. How do we address this and get past our own assumptions?
##Thanks to today's Sponsor: Reaktor
They're looking for great software engineers for a number of product roles, with different emphases within the wide context of product development. Instead of predefining them as positions, they’d like to invite you to come to talk to them about your skills, experience, ambitions, and dream role.
Check them out and tell them about what work motivates you at https://www.reaktor.com/careers/
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
You're probably familiar with the philosophy that things change over time. The idea that an experience is different if you have it one day followed by the next day, and that when you revisit your memories, even your memories change. Even at a neurological level, this has been kind of shown to be the case. In today's episode, we're talking about how problems change over time. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal in this show is to help driven developers connect to their career purpose so they can do better work and ultimately have a positive influence on the people around them. In today's episode, we're talking about this idea that problems change over time. More specifically, this is coming from some research that came out recently. The idea is that problems gain new definitions. We expand our definitions of problems as we revisit that problem over and over. In this study, for example, they had some of the participants of the study. They looked at a screen and they were told to identify the blue dots on the screen. As the blue dots diminished, in other words, as the problems prevalence was lowered, the dots that they previously had classified as purple, they started classifying as blue. This even occurred when they added an incentive to not have any false positives. In other words, if they were to not get any of them wrong, even if they didn't get all of the right ones, then the incentive was a little bit of cash. Of course, the study is much larger scale than this as we solve larger problems, our definition of those problems change. What does this ultimately mean for developers? What are some ways that we might be able to combat this problem? We're going to talk about that right after we talk about today's awesome sponsor, Reactor. Reactor is a digital product studio based in New York City and it's spelled with a K. I've said this on every episode that Reactor is sponsored, but I want to explain a little bit more. Reactor is spelled with a K rather than a C because it started as a Finnish company, a company based in Finland. They of course have moved to a product studio based out of New York City, as we've already mentioned, but this Finnish heritage is actually really important to this company. For example, if you decide to go and work at Reactor, on your first day, Reactor is going to tell you to eat a cinnamon roll and give you a cup of coffee. Quite literally, they're going to say something along the lines of what's the rush. We've already filled out the paperwork and it's time to essentially get to know each other. This is indicative of the culture at Reactor. Now, before you think, oh well, then of course they're not really getting anything done. They've partnered with companies like HBO, Supercell and Viacom, even a big airline, in Air. Of course, that's Finnish. The Fin Air, they designed and built the perfect digital customer journey complete with their own mobile applications and the Inflite Entertainment System and they revolutionized their onboard connectivity. Reactor is looking for software developers. They're looking for people like you. Instead of going and finding a role, they want you to come and explain to them your skills, your experience, your ambitions and ultimately your dream role. Head over to Reactor.com. Remember, that's with the K. Reactor.com slash careers to get started today. Thank you again to Reactor for sponsoring today's episode of Developer Tea. So we're talking about this strange phenomenon that has recently been studied and the name of this phenomenon, by the way, is a mouthful. It's called Prevalence-Induced Concept Change. This causes people to redefine problems as they are reduced. In other words, as the problem changes and specifically, as the problem is solved, as it becomes smaller, people start to redefine the problem. Because we start to discover more about the problem, we start having a more expanded definition of that problem. We redefine the issue. And so as we begin to solve it, it seems as though we're making no headway. It's one feeling that you may get when you are falling to this kind of strange psychological phenomenon. The research goes on to say that even when you're aware that this is happening and even when you're trying to prevent it from happening, it still tends to happen. So we're going to talk more theoretically about ways that we may be able to prevent this or at least address it. And the hope is that we weight things in a particular direction so that even if we can't necessarily fix the bias, we're at least addressing it by biasing it in a different direction. Now at a more practical level, how does this actually play out for developers? Well, it may play out in your refactoring. If you start to refactor code, then as you refactor that code, you may refactor continuously. And it may never feel like you've refactored enough. And as you find more cracks in the code, as you discover more things that you've written in that you prefer, you had written it differently, perhaps new ways of thinking will emerge just by refactoring. And then you'll refactor the code that you've already refactored. And eventually you get into this kind of endless loop seeking the perfect code, which unfortunately you're never going to find. This could also be an issue that new developers face when they're choosing a language to learn. You may have the concept in your mind that you need to find a language. This is the problem that you're solving. You need to find a language to learn. So you do some research and you realize that maybe JavaScript is a good language to learn. This is a safe bet. But as you do more research, you find that JavaScript has its problems. So you decide, well, maybe I'm going to look somewhere else and choose Go or Python. When you do some more research and you find out that Go has its problems or that Python has its problems. So as you choose languages to learn, as your problem, your original problem, which is I need to learn a language programming language, as you choose the languages that you want to learn, that problem space becomes smaller. But now things are getting bigger. Your problem is getting larger. It's kind of this strange paradox, right? So how do we address this? How can we bias ourselves in the opposite direction? Well, we've talked about this on the show many times before. Many of the ways that you can address bias is to connect with people who are not like you. This is one of the reasons at a fundamental kind of scientific level. My diversity is so important. People with different backgrounds, different life experiences, different ages, certainly different genders, and even things like preferences, simple preferences, their musical preferences. These things, these pieces of what we call diversity, they're not just useful because we want to be representative of our culture, which is true. It's also useful because with those different perspectives, we can actually address some of these blind spots that we otherwise wouldn't be able to address. So one of the first steps in avoiding the prevalence-induced concept change, right, avoiding this expanding problem issue is to have other people who think differently from you and have them looking at the same problem that you're looking at. When you have a consensus with multiple people and perhaps everyone's version of the problem is changing, but it's changing in different directions, now you may have a better picture of how this problem is evolving. It may not be that the problem is perfectly solved yet, but rather, you can identify that progress has been made when those definitions begin to change. The second way of approaching this issue is to identify a rubric. So what you want to do is, and we talked about this in recent episodes, ways of making better choices, what you want to do is identify your rubric. This is essentially like when you identify acceptance criteria. If you're familiar with acceptance criteria, the concept is, once these things are true, then this particular task is complete. This helps you prevent adding way too much energy or too little energy to a problem, right? So if you have your acceptance criteria met, it's imperative that you move on to the next thing. So this is important when we're identifying problems. If we set up for ourselves the definition of solved, what exactly are the markers that we're trying to hit? Of course, the risk here is that you're going to set up vanity metrics if you're not careful, and there are multiple ways to affect those vanity metrics. Let's prove this with a simple example. Let's say that you're trying to increase the opinion about company A. You're trying to improve and increase the positive opinions about company A. And one of the metrics that you set up is online reviews. You want the average online reviews to be above a 4.5 out of five stars. This is a very common scenario. Then it may be tempting to solve this problem by deploying a bunch of fake reviews. This isn't actually solving the problem, but if you're only measuring the problem solution based on a particular metric, you may be able to affect that metric in a way that isn't actually solving the original problem at all. So it's important to remember, once again, that this strange phenomenon, I don't know that it's necessarily a bias, but it is certainly a psychological phenomenon, that this happens even when we are aware of it. So it's important to stay vigilant and to try as many strategies as you can to bias in the opposite direction. Lean on other people, provide yourself with much more explicit information about how you are going to consider a problem solved or not solved, and ultimately continuously remind yourself of the most important thing that you can be doing. This is the key question for advancement in any career path. Ask yourself every day on a regular basis, more than once a day. Am I doing the most important thing that I can be doing right now? Thank you so much for listening to today's episode of Developer Tea. I hope you've enjoyed this discussion. Of course, credit for this study, the original study, goes to Harvard University. I found this through Science Daily and Reddit is how I found this content and the study itself. Thank you so much for listening. Thank you again to today's sponsor Reactor. Without our sponsors, we couldn't continue making this show. I encourage you, if you are looking for a job in your developer, go and check out Reactor. It's Reactor with a K dot com slash careers. Thank you again to Reactor. Thanks so much for listening. If you're enjoying these episodes of Developer Tea, go and subscribe in whatever podcasting app you're using right now. We released three episodes a week, so it's very easy to get behind. Make sure you go and subscribe. Thanks so much for listening and until next time, enjoy your tea.