Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode, I'm going to talk to you about two mindsets that will help you in your debugging. This is something that is a part of every developer's life and a part of each and every moment of our day, whether or not we know it. So we're going to dive into that content in just a second. Today's episode is sponsored by Linode. If you are looking for an SSD server that has Linodex pretty much pre-packaged for you ready to go out of the box and you want to get up and running quickly with low cost monthly plans, check out Linode. You can find a special offer for Developer Tealisteners, which we will discuss a little bit more later in the show by going to Linode.com slash Developer Tea. Again, we'll talk more about Linode later on in the episode, but I want to start with a story. My dad recently told me a story about him and his father when he was younger, when my dad was probably in his teenage years. He was telling me about how his dad was a really great mechanic. He could come into the house and be working on a car in the garage. He'd come in and sit down with his dad and have a cup of coffee. He would detail what he was doing on the car to my grandfather. We called him Papa. My dad would talk to Papa and he would tell him what was happening with the car. What he was experiencing, the trouble he was having, and the issues that he was facing. Papa would tell him, go and do this one thing real quick and then come back and tell me what happens. Just by listening to what my dad had to say, he could help him fix the car. In fact, very often, he would know exactly what was wrong with the car just by listening to a few descriptors from what my dad said and also listening to what my dad said after he changed the things that Papa asked him to change. A good developer and a good mechanic share quite a few qualities. We do some very similar work at a fundamental level. We're looking at a system. We're looking at something that is supposed to work in a particular way. We're trying to find the things that are wrong, the things that are preventing it from working in that particular way. I'm going to give you two mindsets in just a moment after we talk about our sponsor. Two mindsets that will help you forever in the process of debugging. These are things that are never going to expire. They aren't about a particular language. They aren't about a particular platform. It's actually just ways of thinking that will make you a better debugger. We're going to talk about that in just a second. First, I want to talk about today's sponsor, Linode. With Linode, you can instantly deploy and manage an SSD server in the Linode cloud. You can get a server running in just seconds with your choice of Linux distribution, resources, and node location. Now you get to pick from eight different data centers and their plans start at just $10 a month. That's like two coffees. You can get a server running in just under a minute. They have hourly billing with a monthly cap on all of their plans and on their add-on services. That includes backups, node balancers, and long view. You have virtual machines for full control. You can run a Docker container. You can do an encrypted disk. They have VPNs. You can set up a private get server even. Linode is not keeping out on the speed. They have native SSD storage, a 40 gigabit network, and Intel E5 processors on all of their machines. Check it out. Linode.com slash Developer Tea. They have a seven day money back guarantee. If you go to that link that I just said, Linode.com slash Developer Tea, or you use the code Developer Tea 20 at checkout, Linode is providing you with a $20 credit just for being a Developer Tealistener. Go and check it out. Linode.com slash Developer Tea. Thank you so much to Linode for sponsoring today's episode of Developer Tea. I promised you two ways of thinking, two mindsets that you can have that will make you a better debugger. I don't mean just slightly better. I mean, but leaps and bounds better. You will be a much better debugger and ultimately a much better developer if you adopt these two mindsets. Okay. So the first mindset and I would say that these are worth writing down actually. So grab a piece of paper and a pen or open your notes app or whatever it is that you take notes in. The first mindset is that you are paying very close attention to how things look when they're running right. You're paying very close attention to how your system looks when it is running right when it is relatively bug free. You know what working software looks like when it is bug free. Now, let me expound a little bit on this. Most of the time if you're writing sufficiently good code, your code is working properly. Most of the time, things are going right. Now, if you encounter a bug, then knowing what caused that bug is ultimately the path towards understanding how to fix that bug. And if you know when that bug starts occurring, in other words, if you know exactly what the system looked like just before the bug, if you know what the system is supposed to look like regularly, then you have a unique ability to recognize when it doesn't look regular. When it doesn't show all of the signs of a normal working system. This is a universal concept throughout many different fields. We talked about mechanics before, but also think about a doctor, for example. One of the first things that they will ask you at a yearly checkup is, have you had any changes in your health? Not how do you feel, but rather have you had any changes because changes are the things that ultimately show us when something has shifted from a working state to a non-working state. And it's a logical, right? We can understand that bugs are introduced and then the system changes. And if we're highly tuned, if we pay attention very closely to how things work when they are working properly, how things look, how they feel when they're working properly, then we will be able to more quickly recognize when a bug is introduced. For example, if you are creating a website and you notice all of a sudden that the load time just increased by two or three times, but you're not paying attention to that. Maybe you are not. Maybe you hadn't heard this episode of Developer Tea and you weren't paying attention before. You weren't paying attention to how long it took to load when the code was correct before. Then you may not even recognize that there's something that's loading two or three times more than it needs to be loading. You may not recognize that you're loading a image that is far too large or maybe as I saw on a tweet earlier this week, you may not realize that your server is having to reboot for every single request that's coming into that server. So this is something to keep in mind is these little nuances, right? The details of how things look, how things feel, what types of log messages are you getting when things are correct, and then what types of log messages do you get when an error is introduced? Most of the time bugs are introduced by code. Most of the time, a bug is caused by either a third-party package being pulled in or updated in your code and then breaking something, making it incompatible, or you yourself, you're writing some code and then you introduce a bug. That leads us directly into our second mindset for becoming a master debugger, a fantastic developer when it comes to debugging. That is to shorten and hyper-focus your feedback loop. Shorten and hyper-focus your feedback loop. In this concept of a feedback loop, maybe a little bit foreign to some of you, but the idea here is that you have a working system, so let's say a code base, maybe you're building an app, and you're adding inputs. This is the initial signal. You're adding inputs. You're changing code. You're doing something to modify that system. A lot of times, we have the tendency to modify the system in three or four or ten or twenty ways, and then check and see what happens once we've done those modifications. We write a bunch of code and then we go and test that code after the fact. The problem with this is that if something goes wrong, well, which line of code caused it? Of course, with some sufficient log messages, you may be able to follow the back trace, you may be able to figure it out. But a much more effective way to work is to make fewer changes, much fewer changes. In fact, one change at a time and then go and test that change. This is a continuous testing process. You may be running your tests automatically or you could just be testing how something looks in the browser. The idea here of a short feedback loop is to make as small of a change as possible and then see what that change did to the system. Take a look at what that change caused in the system. Why is this so important? Well, like I said before, every single bug, pretty much every single bug that you're going to encounter is likely going to be caused by your code. You're going to write the bug and if you ship something that is broken, then you may not know that it's broken right away. You could ship three or four features before you know that it's broken. Now, when you shorten that feedback loop, then you know what the effect is of every single line of code that you write. So what we want to do is shorten the feedback loop so that we have a direct connection between when an error occurs and what line of code is causing that error to occur. Now, the first bit of pushback that you may have when you hear this, this concept of shortening the feedback loop, you may think, well, I don't have time to test after every single change. The reality is that that feels true on the front end, right? It feels like we're having to go through this very laborious process of constant feedback loop where we're testing after every single change. But there's a few things that play here. Number one, you're going to save time in the long run because the errors that you find, you're going to find them more often, you're going to find them in the development process rather than them getting shipped. And beyond that, you're going to save you and or your clients a lot of money because the server is not going to go down, right? You're not going to lose business for that client. You're not going to lose business for yourself if you're creating a product. By doing this testing process, you reduce the total number of errors in your code and ultimately your stress is going to go way down and your your dependability on your development process is going to go way up. This short feedback loop style of coding also greatly increases the quality of your code on a regular basis. You're going to have much better output. The first time that you write code, once you get into this rhythm. Now with that said, there are quite a few tools that can help you with this kind of constant testing process. For example, if you're doing a lot of front end work, you probably want to invest in something like live reload, bringing that into your process so that whenever you save and maybe you're compiling your JavaScript or you're compiling your SAS or LAS or something like that, whenever you save it will live reload in the browser. Of course, I will include a link in the show notes to live reload. But there are a lot of these kinds of things. For example, you can automatically run your tests whenever you save a new test. If you're working on a Rails project or another project that has a software test suite. There's a lot of tooling around this concept of a very short feedback loop. I highly recommend that you invest in a short feedback loop. I can't tell you how many times Developer That I work with. They come to me and they tell me that they have an error, but they don't know where it came from. And notoriously, almost every single time, it's because they had a very long amount of work that they were testing. They weren't testing one thing at a time. They were doing a bunch of changes on their local computer, for example, and then pushing up everything all at once, rather than pushing it up in increments and testing each of those individual features. And so they had to go back and reconfigure and roll back everything to 20 features before rather than saying, oh, it's that one feature and rolling back just that one. So again, let's do a quick recap. There are two mindsets that I want you to adopt to become a better debugger. And the first one is to focus very, very intently. Learn how a system feels and how it looks when it is working normally. So number one, learn how a system looks and feels when it is working normally. When there's nothing wrong with it, when you don't see bugs present. And number two, shorten your feedback loop. Make it very, very focused. One change at most, maybe two or three changes at a time. And then check what that did to the system. See your test reports or reload it in the browser. See what is happening for each of those changes. Thank you so much for listening to Developer Tea. I hope you've enjoyed this episode. And hopefully your debugging will continue to get better as you gain more experience, as you practice these ideas of learning how a system feels when it's in its normal state, when it's working well, and also shortening your feedback loops. Thank you so much to Lenoid for sponsoring today's episode. If you're looking for a cloud hosting provider specifically for Linux and you want a $20 credit for free just for being a Developer Tealistener, go to linode.com slash Developer Teaor you can use the code Developer Tea 20 at checkout at linode.com. Thanks so much to linode. Thank you for listening to the show. Of course, you can always leave a rating and review for Developer Teain iTunes. This is the best way to help other developers just like you find Developer Tea. Thanks so much for listening and until next time, enjoy your tea.