It's 3X3 Week! All week we'll be covering three tips to make you a stronger developer. Today's episode we cover three biases that you need to protect yourself from as a developer.
It's 3X3 Week! All week we'll be covering three tips to make you a stronger developer. Today's episode we cover three biases that you need to protect yourself from as a developer.
What if there were things that you act on and things that you believe, whether explicitly or implicitly, that just simply weren't true? This is actually a reality for pretty much everyone, and that's a topic we like to discuss on the show, the idea of fallacies or biases. These are things that change the way that we think or mold the way that we think, so that we have our own particular viewpoints, and sometimes those viewpoints are flawed in some way. In today's episode, we're going to talk about three of those biases or fallacies that you need to kind of protect yourself from as a developer. Our goal on this show is not to create fear, but instead to equip you as a developer to be able to face this kind of stuff. My name is Jonathan Cutrell. You're listening to Developer Tea. My goal on this show, my big goal on this show, is to help driven developers connect to their career purpose so they can do better work and have a positive influence on the people around them. Of course, for you to connect to what you want, or for you to connect to a purpose, an underlying kind of methodology of thinking and believing in values that you have about the world and beliefs that you hold that drive your actions, for you to be able to do that, you have to understand the way that your mind works. You have to know what you believe. You have to actually be able to articulate it. If you can't articulate every single thing that you believe because that would be incredibly difficult, you do need to be able to understand some of the areas that may be detrimental for you to not have control over or at least have awareness about. This isn't the first time we've talked about biases or fallacies on this show. This is actually a very common topic that comes up pretty much in every other major topic. This is embedded in it because we aren't really talking about some specific thing that is quarantined to one area of your job. This is really talking about a high level perception, how you see the world, how you can actually decode the things that are happening around you. We are going to talk about specific things today, three specific fallacies that I don't want you to fall prey to that are very common for Developer To fall prey to. We're going to get into that in just a minute. Today's episode is a three by three episode. This week we're doing the three by three episodes, these are three practical takeaways in each episode for a week. The reason that we're doing this is because quite simply found that these episodes are particularly popular and impactful to this audience. I want you to have these practical takeaways and want you to be able to apply this stuff on a day-to-day basis. The goal of the show is not to be heady, it's not to disconnect from reality. It certainly isn't to only discuss philosophy. We will discuss things like philosophy on the show. That's totally on the table, but we're only going to discuss it if we can then turn around and act on it. That's what we're doing today, the three by three episode, three fallacies that I want you to avoid as a developer. The first one, this is a very strong fallacy. Everyone goes through this. We believe that in the fallacies you will remember everything you did today. You will remember everything you did today in the future. Perhaps another version of this fallacy is, I will remember better as I go along. I'm going to remember today better than I remembered yesterday that my power of memory is somehow getting better over time. Even though I can't remember my childhood and I can't remember five years ago very well, it's not very clear to me that actually today is pretty clear. I'm not going to forget what's happening today. This is totally incorrect. This has been studied many times, more specifically with relation to learning, but the same insights can apply in many other areas as well. The studies show that the forgetfulness curve looks something like this. When you get new information, let's say when you're reading a book or maybe you're listening to this podcast, even when you are intentionally engaging that information in about two days, the course of 48 hours, you will have forgotten over half of it. The number is about 40% that you're going to retain after two days. Furthermore, your brain is selective about what it remembers, even in the short term. For example, even though this podcast has only been playing for a few short minutes, could you recite every word of what I've said without re-listening and writing it down? In fact, even if you did this 20 or 30 times, if you re-read or re-listen to everything that I've said to recite it word for word would be a huge difficult task for your brain to accomplish. And the point of what I'm saying here is not to lead you down the road of trying to increase your memory ability, but instead to recognize that memory is not nearly as simple as we may intuitively believe that it is. The salience and presentness of the information that we have in front of us makes it feel like we will never forget it. It's very easy to believe that the feelings and the emotions and all of the present nature of things, you know, you're looking around you, you can see, you can feel, you know exactly what's happening, it's all happening in real time. So it's hard to believe that you're probably going to forget it. And it may even feel a little bit alarming or negative that you would somehow lose sight of these moments to moment interactions that you have with the world. But I want to encourage you, don't let this cause you anxiety. This is actually how our brains are, they're engineered this way. They work this way. Our brains are prioritizing other things, the prioritizing other things. They're not using their energy and their space to remember things that are basically useless, right? And it's very difficult to signal to your brain what is and what isn't useful. Our brains are prioritizing other things like survival and food and tons of other things that we can't really explicitly nail down exactly how it's working. There's not an algorithm that we can go and read that explains how the brain makes these decisions. But the information our brains is collecting and then associating with other information. This is one of the major mysteries of the way that we think, the way that we see the world. So we can't look up what happens, you know, on a random Tuesday afternoon, four years ago, without the assistance of some recording mechanism, maybe a computer, right? Or a diary, for example. And keeping history is a difficult process for this very reason. And because our brains tend to forget most of what happens to us, not just some of it, most of what happens to us, our brains tend to forget. And instead, adapt to the impressions of what happens to us, recalling information based on association and context when it is most relevant. So why does this matter? Why does our forgetfulness matter? First of all, it's important to remember this just in general because a lot of the experiences you're going to have, you know, a lot of the social experiences, a lot of their relational experiences, they are going to rely on memory of some sort or you're going to have some kind of intuition based on your memory that may not be shared with another person. So it's important to have that understanding that your memory is really kind of a complicated machine that you don't really see the source code of, right? But the other piece of this is, you know, if this is true, if we forget most of what we've done, if we forget most of our experiences, then we shouldn't write our code as if we will understand it implicitly in the future. You know, you should write your code for other people to read it, but sometimes that other person isn't actually another person, per se, but it's simply you in the future, right? And as if you are going to hand it off to a stranger who knows nothing about the code at all, and this will lead to better documentation, better naming, more thoughtful design all around, but it will also allow you in the future as your memory, unfortunately, is not going to hold all this code in mind. And it's not really unfortunate, is it? Because our brains are prioritizing other things. Instead of forcing your brain to try to remember something that it is categorized as unimportant, instead, what you can do is create better documentation, right? You can create the code as if you're writing it for another person to work on with you. Now, how often have you returned the code? And you've asked this very simple question, and it's five words long. Why did I write this? Why did I write this? I've asked this so many times. I can come back to a project and I can understand the general structure, but then suddenly, I run into code that doesn't have an explanation. And it creates some anxiety around changing that code, right? Especially if I didn't write tests. And tests, for example, are another way to future proof. If you keep a test suite and you keep it up to date, then your future self will thank you because now you have kind of a way of saying, here is why that piece of code exists. If I remove that piece of code, then this test starts failing, right? So documentation testing, naming the overall design, the intentionality of what you do, the quality of your work as a developer is going to go up if you internalize the concept that you're probably going to forget. You're not going to be able to hold a memory, all of the reasons why you designed it that way. You're not going to be able to recall the entire application structure, even as soon as just a few days for now. So make sure that you're building as if you're building for a stranger, someone who is not watching over your shoulder, who isn't in your head, someone else is going to be collaborating with you on that code. Of course, the side benefit is if someone else does come along, right? If another developer comes along to actually collaborate with you, or if someone else picks up the project and you move on to something else, well, you're already prepared for that. You don't have much of a crossover in training. You don't have to rely on person to person communication in order to make that transition a little bit smoother. Of course, everything is in moderation. You're probably going to still have to do some person to person. You're probably still going to have some issues with remembering, even with good documentation, good design. There's no silver bullet answer, unfortunately. And this stuff is hard, being a software developer's hard. That's why we can have so many episodes of developer to you about subjects like this, and it still isn't answering every single question. There's always going to be more questions and more problems to solve, but taking steps towards solving those problems. That's the key. That's kind of the key takeaway. Let's move on to the second fallacy. The second fallacy that I hope you can prevent from falling victim to. You may have already fallen victim to these to these fallacies. It's very easy to believe these things. So number two, if we try hard enough, we can estimate large projects or tasks. If we try hard enough, if we try long enough, we can estimate. We can accurately estimate large projects and tasks. Unfortunately, the information that we have available, the studies that have been done on project completion, project success, estimation pretty much unilaterally agree that estimation is something that humans are very bad at doing. And this gets worse as the thing that you are trying to estimate gets larger. More specifically, if you are trying to estimate how much energy is going to be needed to accomplish a task and in particular, a complex task that hasn't been accomplished before. If you're in that scenario and you're trying to estimate a large task, a large complex task that's never been done before, you're probably going to be wrong. And you're probably going to underestimate. According to most data, in fact, there is a chaos manifesto. This is found on the version one site. If you're looking for it, probably search chaos manifesto 2012. But less than a third of projects finished on time and on budget in 2012, according to the chaos manifesto. A study published in the Harvard Business Review, which analyzed over 1400 IT projects, found that all but one in six projects, all but one in six projects, that's 83%. Actually, more than 83%. 83% of projects have cost overrun of 200% on average and a schedule overrun of almost 70%. And this concept is known as the planning fallacy. This is a fallacy that was discovered by Daniel Coneman and Amos Tversky. On the Wikipedia page, you can find a really good study that was done by Roger Bueler, Dale Griffin and Michael Ross back in 1994. And what this study found in 1994, 37 psychology students were asked to estimate how long it would take to finish their senior thesis. The average estimate was 33.9 days. Put this in your mind, 33.9 days, about a month. They also estimated how long it would take if everything went as well as it possibly could. And that average was about 27.4 days, and then if everything went as poorly as it possibly could, averaging about 48.6 days. So we're looking at a range of about 27 to 48. We'll say that's almost a 100% increase from the best to the worst case scenario. The average actual completion time for these senior thesis, again, the average estimate was 33.9. In the worst case scenario, the average was 48.6. The average actual completion was 55.5, which is greater than the average estimate for the worst case scenario. In other words, things went beyond the worst case scenario. On average, this isn't for a few of the students, but on average, and only about 30% of the students completed their thesis in the amount of time they predicted. But perhaps most alarmingly here is the jump from their predicted best case scenario to the average outcome. The predicted best case scenario was around 27.4 days. And the average completion time is over twice that. This is a huge, huge fallacy that we very often become victims of in good intentions. And this is such a problem in development, especially because so much of what we do is still in the unknown category. There are many theories as to why this occurs. Why humans are bad at estimating, more specifically, we're bad in the worst direction, where we underestimate what it's going to take, which means that we end up in a costly scenario. Very often, overestimation is actually a better idea. It's a better call to overestimate. It would be a better outcome if we overestimated and then had the extra time or the extra resources available to reallocate to other places. But unfortunately, this isn't the case. So theories as to why this occurs. The first theory is blind optimism. This is just simply not thinking about everything that could go wrong. We aren't thinking about the variety of factors that we can't predict. We can't predict sickness, for example. We can't predict accurately how good we're going to feel on a given day, how energetic we're going to feel. We can't predict accurately how often we're going to be interrupted. There's so many other things that we can't predict. And this is not even getting into the fact that we can't predict what kind of technological hurdles we're going to face in compatibility issues, even changes in the business market that we have absolutely no control over. So blind optimism, this is a huge issue. Number two, the next theory is wishful thinking. We are eternally optimistic as developers, especially when we see a relatively clear path when we feel that we have certainty about how we would go about attacking a particular problem. We have a sense of positive kind of optimism, wishful thinking, that encourages us that we're going to be able to do this particular task in a shorter amount of time that we actually will. Because we can see the finish line, we have a hard time judging how far away it is. The next theory as to why we are bad estimators is the self-serving bias. So if we're thinking in terms of learning, we can look back into our past and we can kind of predict what's going to happen in the future based on our past. You would think that this would help us become better estimators, but for some people it actually makes it worse because things that went well in the past, we tend to apply that credit to ourselves. And things that went poorly, we tend to blame other people. So what this means is we kind of cherry pick from our past experiences to build the picture of our own ability. We feel good about our future abilities because we've cherry picked the good things from the past. So there's plenty of other theories as to why we are bad estimators. We can't get to all of them obviously in one episode because this, again, this study has been going on for a long time. But I do want to give you a takeaway from this fact that we're kind of bad estimators as general rule. So when possible, we should reduce every estimate to the smallest possible item to be estimated. In other words, break up your estimates into the smallest things that you can estimate where much better at estimating how long it's going to take to walk across the room than we are at estimating how long it would take to walk across the city or even across the neighborhood. The same is true in most things. If it's smaller, it's going to be easier to size up. So break it down into the smallest thing. Ask yourself in the worst case scenario how long could this take and then add more to that. Recognize that you cannot reasonably evaluate the things that you don't yet know are going to happen. Evaluate the real problem with estimating more realistically. The driver here is often fear of losing a client or a promotion or the approval of peers. Now I have a personal theory on this. This is kind of a bonus theory here. People want the gratifying effect of an on-time estimate today. We want to feel the sense of accomplishment today by estimating that we could finish something in a certain amount of time that satisfies the requirements of a given project or satisfies the desires of a client or a boss or even a coworker. We get that gratifying effect by making them happy with our estimate. We fail to measure the future negative effects of an overtime or over budget reality down the road. That future pain is not a strong enough threat to avoid the gratification today. This concept is supported by some psychological theory, but certainly there haven't been any studies done on it. It's just a personal theory. We're going to move on to a third fallacy that I want you to avoid as a developer. That is, there's a definite way, a definite best way to do something. Given an infinitely small moment in time, there may be a single way to optimize for particular variables. If you could stop time from moving on, if you could stop all change, all dynamic events from happening, and if you could control for every variable, then perhaps you could determine one best way. But the reality is far different from this. Everything around us is always changing, and it's always evolving and transforming, even we as humans are doing this. We're growing, we're being born and we're dying. This is at a fundamental level. Change is kind of the only constant, right? We've heard this quote before. The reality is there's so many variables that the best decision in a given scenario may be changing instantaneously from one decision to another. Our job as developers is not to try to track this change. It's not to find the absolute best way. It's also not to find the best language or the best tool, the best framework. It's not to find the best person to hire. Instead, it is to make the best of a situation with all of the things brought into consideration. This balance is difficult to achieve, but it is the most important reality for Developer To understand. It is extremely difficult to get this perspective without having other people who will help you to understand the different competing motivations. It's easy as a developer, for example, to think that the technicalities of a platform are kind of the linchpin, the utmost importance. We also adopt various beliefs of parallel industries. For example, if we work heavily with visual designers, we may have a high level of importance that we place and a bias towards visual organization. Likewise, if we work with a marketing guru, then we might place a lot of emphasis on AB testing or validation from day one, gathering data. If we work in a culture of agile practitioners, then we may lean towards the idea of MVP and constant iteration over grand design. In order to become better as a developer, you must be able to consolidate these competing motivations, not destroy the ones that you don't personally find valuable, but consolidate the competing ones and find the most effective balance between them. Sometimes this means prioritizing those motivations so that when you're faced with the decision that compromises between one or the other, you have a rubric for making that decision. Sometimes it means finding creative ways to satisfy a whole handful of host of motivations. Sometimes it means re-evaluating your own motivations and recognizing how they affect the project as a whole. These are three fallacies that I think are super important for you to pay attention to as a developer. I hope that this episode has been enlightening, inspiring, and maybe it's going to protect you a little bit from a misstep that you would have made otherwise. I hope that's the case. I hope you've been challenged by this episode, and I hope you'll listen to the other three by three episodes from this week. If you're enjoying this podcast, make sure you subscribe and whatever podcasting app you use. That's not for everyone. Not everybody needs to subscribe to this podcast. Only people who are willing to think and be challenged while you're listening to a podcast is not really a light listening kind of experience. It's that we're dealing with the things that we really need to deal with as developers. Thanks so much for listening, and until next time, enjoy your tea.