As we continue to deal with the global coronavirus pandemic, it's unlikely that you're going to hear anything on this podcast about the specifics of the virus or the response to that virus, the economic impacts that it's going to have, because I'm quite frankly not an expert on these subjects. There are other podcasts that are covering these things thoroughly and I don't want to add noise to the mix. So I encourage you if you want to hear more about those topics, to seek out authoritative and scientifically sound advice. With that said, in today's episode, we're going to discuss something called the overreaction paradox. This is a newly coined term for a long existing phenomenon. My name is Jonathan Ketral, you're listening to Developer Tea and my go on the show is to help driven developers like you find clarity, perspective and purpose in their careers. A spoiler alert for today's episode. Even though we're talking about something called the overreaction paradox, we are not suggesting that the people who are responding to this global pandemic are overreacting. In fact, in most ways, this paradox supports the other side of the argument that overreaction can often be completely rational. Here's how it works. We'll use an example from our work as developers. Let's imagine that you have a startup. You've come up with a great idea, at least you think it's a great idea, for an application. And you know that this app is going to be launched on Product Hunt tomorrow. But you do nothing to prepare for it. Maybe you leave the app on a small server that can easily be overloaded, or maybe it's a dyno that goes to sleep on Heroku or something. And so as the app is shared on Product Hunt or as it's shared on hacker news and because it's such a good idea that you've had, it gains enough popularity, but all of the traffic obviously overtakes your server. And you can't scale to meet the demand. Now not only does the traffic overtake the server, but you don't really do anything about it. You kind of sit back and say, things will work themselves out. Eventually, people stop visiting the site because it's unresponsive. And in a way, things did work themselves out, but just not to your advantage. People stop visiting the site because it was unresponsive. In this scenario, you didn't overreact. But you still experienced a significant failure. And it's obvious that you could have done more to prepare. Now let's take it to the other side of this argument. Let's rewind back to the night or the month before the launch. Your great startup idea is scheduled to release on Product Hunt. And perhaps you thought ahead and decided to release on hacker news a day earlier. Perhaps you're going to stagger your already kind of preparing for the onslaught of traffic and coordinating your marketing efforts to manage that traffic well. And so you prepare in advance in multiple ways. First, by coordinating those release times. And then maybe you scale up your server or you have redundant servers, multiple backup options in case the first line of defense or your first server falls down. Then you can easily reroute traffic to another server. And of course, the tactics to do this, there's a lot of them. And we don't need to dive into the details. But it's important to notice here that you haven't even released your product yet. In fact, if you're looking at the need, the immediate need for these extra measures of precaution, then the immediate need just isn't there. Now let's fast forward to the day of launch. And you start getting heavy traffic. In fact, even heavier than you had planned for. Now initially, your plans all kind of work. You have one of your servers get overloaded and traffic automatically flows to the second one. But then you have a few users that are reporting that they're seeing some kind of error. You react immediately adding even more servers to your pool of servers. And you can see how this kind of reactive response and proactive response, if you were looking at it in comparison to the previous the previous scenario, this kind of activity is much more desirable. But I want to kind of change the second scenario. Let's imagine that not only were you able to handle all of the traffic, but you were able to handle all of it easily with a lot of headroom. In this scenario, people might say that you overreacted, that you prepared too heavily or that you imagined a problem that never existed. These are all phrases that we like to throw around. And we have good reasons for throwing these phrases around. For example, it's not really a good idea to write code before you need it. And this is essentially the sum of the overreaction paradox. And I'm going to read the tweet directly from James Clear. James Clear is the person who kind of coined this, this term, the overreaction paradox. And here's the tweet. When the result of taking effective action is that nothing happens, which makes your effort seem unnecessary. And like an overreaction, even if it was the right thing to do. I want you to think about this overreaction paradox while we go and talk about today's sponsor. And then I want to come back and talk about how we can make our incentives align with the things that we care about so that we don't get stuck on the wrong side of the overreaction paradox. Today's episode is sponsored by Linode. Whether you're working on a personal project, or managing your enterprise's infrastructure, Linode has the pricing, the support, and the scale you need to take your project to the next level. Linode has 11 data centers worldwide, including the newest one in Sydney, Australia, with enterprise grade hardware, S3 compatible storage options, and the next generation network. Linode delivers the performance to expect at a price that you don't. You can get started on Linode today and you'll get $20 worth of credit. If you're a listener of the show, and you'll get access to native SSD storage, 40 gigabit internal network, and industry leading processors. On top of all of this great hardware, you'll also get access to your Linode box, this root access, even on the nanoed plans. These start as low as $5 a month, or if you want to scale up and go to the other end of the spectrum, you can get a dedicated CPU plan. You'll get physical cores that reserve just for you, or you can even get a GPU compute plan. This is suitable for AI, machine learning, or video processing, and you can even get one click installs of the most popular applications like WordPress. You can even set up a lamp stack with a single click, game servers for Minecraft. Pretty much anything you can imagine. Go and check it out. Head over to linode.com. Slash Developer Teato get started today. Use that promo code Developer Tea2020 and checkout to get that $20 worth of credit. That's linode.com slash Developer Tea. Thanks again to linode for sponsoring today's episode. What do you celebrate on your team? We're talking today about the overreaction paradox and the fact that if we prepare well, we often don't know. It's hard to know if you have prepared adequately or if you've overprepared. And the difference there is that there's often stigma attached to overpreparing or in this case overreacting, even when the outcomes are good. And so it's necessary to look at what you celebrate. Easier culture celebrating reactions to bad events. In other words, are you celebrating the developers who jump in whenever a bug occurs in production and fix the bug or are you celebrating the fact that there are entire parts of your code base that haven't experienced bugs in years as a result of the proactive efforts of an entire team of developers. Now let's be clear that we shouldn't ignore the fact that someone is pitching in in a critical moment when a bug appears in production. But it's necessary for us to think about our incentives differently. What kind of incentives would you create if your goal was to eliminate bad events from occurring? These kind of incentives are entirely different from the incentives that you would create in order to measure reactiveness or the ability to respond to those bad events. Focus on honing your incentives to be measurements of health rather than intervention. This simple heuristic can change the way that you think about preparing. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Leno for sponsoring today's episode. Head over to Leno.com slash Developer Tea and use the code Developer Tea2020 that's 2.020 at checkout. If you haven't subscribed to the show and you've found today's episode particularly useful, I might ask you to do two things. Number one, subscribe and whatever podcasting app you're most likely to listen to podcasts and the second thing, share this episode with someone else that you think will find it valuable. Whether you share it directly with another developer or if you share it on Twitter, if you found this episode valuable, the best way that you can help other people find this show and start listening is for you to share it rather than me. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.