I want to take a moment and commiserate with those of you who are working on a particularly insidious bug. This is perhaps one of the hardest things that we do as developers we chase down. These very difficult to solve problems. In today's episode, I'm going to take a moment to hopefully help you feel a little bit better about how far you have or haven't come on this trip. I'm trying to find and solve whatever this bug is. And then I want to help you with a few tips for keeping your mental resolve until you actually get to the other side of that trip. My name is Jonathan Cutrell. I'm your listening to Developer Tea. My goal on the show is to help driven developers like you connect to your career purpose and do better work. So you can have a positive influence on the people around you. Before we get started today, I want to give a quick shout out. A huge congratulations to Brynn and Brian as well as Max Stoyber. These are the folks behind Spectrum. If you haven't seen Spectrum, go to Spectrum.chat. Brynn and Brian also were the two guys who used to host design details together. Brian continues to host design details. And we all found it's back.fm together. But that's not the big story today. The big story today is that Spectrum has joined GitHub. This is a huge announcement for Spectrum and I'm very proud for their team and there is no better team that deserves that kind of recognition or that kind of event. Company event that has occurred for Spectrum. Go and check it out. You probably have already heard of it though. In any case, a huge congratulations. If you haven't signed up, I encourage you to go and go and sign up right now at Spectrum.chat. Let's jump into this episode. You are hunting down bugs or maybe even one bug. And sometimes it may not feel like a bug. It may feel like a dinosaur of a problem in your code. Or it may not even be in your code. It could be in the environment. Someone else's code. Third party service. This is already pretty difficult. It's already difficult if we stop here. But I want to take a moment to think about what brought you to this point in your career. If you think about where you came from, you're a background. You may not even have a formal education, for example, in computer science. And even if you do have a formal education in computer science, it's almost certain, depending on what kind of projects you're working on, it's almost certain that you never faced a bug like the one you're facing right now when you were being trained. So if you find this bug, then it's the first time you've probably ever done anything quite like that. But let's back up even more. Just 10 years or 20 years ago, the bug that you're experiencing didn't even have a hope of existing because you're probably working on software that wouldn't even run on computers from 10 or 20 years ago. And in fact, depending on your particular flavor of human history and the history of the world and the universe, you are of a very, very small group of humans to work on computers to work on anything even remotely as complex as what you work on. For the vast majority of human history, the types of problems that humans solved were very different. And so though they weren't necessarily easier problems to solve, you don't really have the long history of humans behind you to draw on that kind of ancient wisdom when you're solving a bug. Despite the fact that it's amazing that you're even doing this job, we still feel defeated by these software bugs. And we can't figure something out, we feel like we don't really belong in this job. Sometimes we feel like what isn't obvious should be. Even when the bug is very elusive, we'll chase down the wrong trails for days sometimes. And end up feeling like it was all a waste of time. But in this episode, I want to take a moment, and first of all, as we've already been doing, I've recognized just how amazing it is that, especially if you're working in a paid job, working in software development, that it's amazing that you're even there, right? That take a moment and appreciate the miracle that, or I guess the list of miracles, the things that you could have never guessed would happen. All of them had to happen for you to end up where you are solving that problem today. Now in the moment, you may still feel very defeated. So in today's episode, I also want to give you some practical advice for staying strong while you solve those problems in your code. But first, I want to take a moment to talk about today's sponsor, Linode. And if you've been listening to Developer Tea for any amount of time almost, you've probably heard an episode where Linode was the sponsor. Linode cares about developers and they invest in developers, not only by sponsoring podcasts like this, but also by going above and beyond as a company. You can go and look at Linode's code, for example, the code that they use to run their beta manager, which you can find at cloud.linode.com. It's also open source. You can go to get hub.com slash.linode to see all of their projects. But Linode is built by developers for developers. This is a company of Developer That manage the service. And they're not only investing in you by sponsoring this podcast, by creating incredible products at linode.com, but also they're going to give you $20 worth of credit, which is equivalent to about four months of service on their introductory plan. That plan has a gigabyte of RAM on an SSD server, it starts at $5 a month. And they have high memory plans if the one gigabyte is not nearly enough for whatever it is that you're doing. The high memory plans start at 16 gigabytes a month. There's tons of other features that you've probably heard on the show before. You can go learn more about Linode by heading over to linode.com slash Developer Tea. Use the code Developer Tea. 2018 at checkout for that $20 worth of credit. Thank you again to Linode for continuing to be a sponsor of Developer Tea. I have two basic tips for you today to hopefully increase your stamina, your resolution while you are fixing whatever insidious, difficult, you know, head and bug that you are fixing. And this isn't going to tell you how to fix it. Let me be very clear. But this is to help you maintain your motivation and your mental energy as you're going through the process of fixing the bug. We've done other episodes on ways of thinking while you're fixing bugs. But I want to also address the reality that sometimes we burn out on bug fixes as with a lot of things that you will face as a developer. If you change your perspective, if you change the angle that you're looking at this bug solving process, if you change the angle that you're looking at it from, the new types of value, new types of good things, positive value will emerge. For example, the motivation to fix a bug may be initially working software. It may be less frustrated customers and more money. But I want to pivot a little bit and hopefully bring out a new type of value that will help you stay engaged. Because when you continue to fail, when you keep on trying a fix and it doesn't work and everything that you try seems to be wrong, then it feels very much like you're standing in one place. Because the software that you're trying to affect the movement on that software is basically no. You have no improvement. You have no sense that any progress is being made. That you're really doing anything at all. But I want you to shift the value, shift your perspective and view it as an opportunity for you to learn. Now, this sounds very cliche, doesn't it? View it as an opportunity to learn. But what this does at a kind of a practical level is instead of feeling like no motion is actually happening. Instead of feeling like you're stagnating, everything you try is a new brick in that wall of learning. And there's no amount of learning that is useless. Right? Everything that you try, every step that you take, every article you read, every hypothesis that you test, all of this is going to improve you as a developer. What this does is it adds to your experience list. You're going to draw on this experience in the future. And so you can view this opportunity to fix this bug through the lens of, hey, I'm actually getting better. There's something that developers really crave to do all the time. We want to be learning. It seems like this endless treadmill of opportunities that are in front of us. And very often when we are building out features and not fixing bugs, that treadmill seems to slip past us. We don't feel like we're learning when we're just building out features. A bug which feels like it isn't a learning opportunity. Very often is exactly the types of learning opportunities that make you a more valuable, more experienced, much more capable developer. So let me rephrase this once again. Now hopefully this is a little bit less of a cliche way to phrase it. Instead of focusing on the software as the product of this bug fixing experience, focus on your learning as the product. If you focus on your learning as the product, then you will not stagnate. You can continue to learn. You can continue to test hypotheses. You can have 100 wrong hypotheses and still be learning. So that's the first helping recommendation to encourage you to retain your stamina as you are fixing a particularly difficult bug. The second tip that I have for you as you are fixing a particularly difficult bug is to stop being so serious. Bugs often come with a load of frustration, of guilt, of urgency, sometimes cost, sometimes a whole history of attempts by other people. Sometimes there's drama associated with bugs. And all of these things can make a bug fix feel very weighty. Very often, especially critical bugs can be stressful for developers. And under that stress, you're very likely to make bad decisions. You're likely to treat others poorly. You're likely to become defensive and blame other people. In a stressful scenario, you're likely to rush. You're likely to try to push code that you haven't tested. And ultimately, the first tip that we gave in this episode, you're going to do away with entirely. You don't care about learning when you're stressed. You just want to relieve that stress. You want to solve the bug. Unfortunately, the opposite is necessary for a lot of the most difficult to solve bugs. You have to be playful to have a low sense of stress, a low sense of urgency, to be able to explore in weird directions sometimes and to remain curious about what could be the fix, to try out these bizarre and sometimes totally antithetical hypotheses for the sake of learning what direction you should go. And we shouldn't try to live in a utopian society where we eliminate all types of stress and we eliminate all types of urgency. And of course, there are consequences to the bugs that we're fixing. But I encourage you win possible and especially for managers who are unleashing developers on bugs. I can almost guarantee you that the fix for those bugs will be found in essentially the same amount of time, with perhaps a higher quality and a much happier developer in the end. This isn't tested truth by any means, but I encourage you to view these things less seriously. Imagine in 10 years how important that bug will be. Trying to take on the mindset of viewing this bug as an outsider, of viewing this problem, this difficult to solve issue as an outsider that is intrigued rather than tasked, burdened with whatever this problem is. Thank you so much for listening to today's episode of Developer Tea. I hope you will go and treat your bugs solving opportunities as a learning experience and with a sense of excitement and playfulness rather than a sense of duty or burden. Thank you again to Leno for sponsoring today's episode. You can get your $20 worth of credit by using the code Developer Tea 2018 at checkout. Head over to linod.com slash Developer Tea. Thank you so much for listening. And until next time, enjoy your tea.