Take a minute to think about the last big bug you worked on and how you felt....today we're talking about a way to track down bugs and solving long, drawn out debugging sessions.
Take a minute to think about the last big bug you worked on and how you felt....today we're talking about a way to track down bugs and solving long, drawn out debugging sessions.
Today's episode is sponsored by Linode.
In 2018, Linode is joining forces with Developer Tea listeners by offering you $20 of credit - that's 4 months of FREE service on the 1GB tier - for free! Head over to https://spec.fm/linode and use the code DEVELOPERTEA2018 at checkout.
I want you to take a minute and think to the last bug, really the last big bug, the one that took a long time to fix. I want you to think back to how you felt in that moment. And really connect to the frustration and maybe the seemingly wasted hours that you spent just to figure out that it felt like a relatively obvious thing that you could have avoided and you just didn't. It wasn't a hard thing. It wasn't an algorithmic problem. It was something else, something seemingly simple. We're going to talk about a way, a practice that you can employ. In today's episode that can help you track down these things a little bit faster, a little bit easier. There's so many ways of dealing with code. And we're going to talk about one specific practice today that I believe is one of the most effective ways of dealing and ultimately kind of avoiding these long, drawn out bug tracing sessions. My name is Jonathan Cutrella. You're listening to Developer Tea. My goal in the show is to help driven developers. Connect to their career purpose and ultimately do better work to have a positive influence on the people around them. And we talk about multiple different kind of classifications of information on this show, right? Specifically, we mentioned at the beginning of this year that we want to focus on practices, principles and purpose. These are the pillars of Developer Tea. Sorry for the overuse of alliteration. But this is true. Ultimately. Your practices and your principles will follow from your purpose. And so, you know, we need to talk about what those practices look like. What is the practice of a well-intentioned developer look like? And how can we do better things by changing our practices? You know, we don't just change at the top. We don't just change the purpose and hope that everything else falls in place. We can identify spots all the way down that chain. And kind of improve in each of those areas. So we talk about principles probably most of the time on the show. Because principles really drive everything else. There's an endless amount of conversations that we can have on principles. When it comes to practices, this is a little bit more limited in terms of how evergreen that content is going to be for people who find the show in one or two or three years. We don't really like to hyper focus on one specific thing. We don't like to hyper focus on one specific practice in one specific language. Because, you know, really the insights that you can gain from the show, I think the highest leverage is when we can generalize this information to, you know, any language. When we can generalize these practices to any language or any paradigm, any environment that you're operating in. An interesting side effect of this kind of focus that we have on practices and principles that scale. To multiple environments, multiple languages, whatever your job title is. And the interesting kind of side effect is that a lot of the time these practices and principles can be taken out of the coding world. Right? Out of the software development, software engineering, DevOps. Out of that world. And it can be applied in almost every other area of your life. Right? So it's not just about code. It's not just about engineering. It's also about patterns and ways of thinking and models of thinking. That can change the way you do everything in your life. So that's why we believe this show really could be for anyone. You can gain a lot from this show. Not only if you're a developer. Not only if you're a designer. And today's episode is no exception. I'm really excited to talk about this idea. Because I think it really can change the way you see the way you write code. But it can also change the way that you see performing your everyday. Activities. So I want to revisit this idea of encountering a bug that takes you a long time to trace down. Most of the time when we encounter these bugs. It's because when we look at the code. There's either something that we aren't seeing. At all. It's absent. Or we're seeing something differently than it is in reality. Let me say that again. Either there's something missing. And we don't realize it. Or the code we're looking at doesn't do what we think it's doing. And these two frustrating positions to be in. They really leave you kind of scratching your head in either scenario. Because in both scenarios. You believe by looking at the code. You believe that it should do what you're trying to do. Recently I've been practicing kind of brushing up on my computer science skills. I never had a formal training. In computer science. I had training in things related to it. But I never had formal algorithms class for example. And so I've been brushing up on some of those things myself. Just for my own interest. And so many times I've written an algorithm. Maybe a sorting algorithm for example. And I'm staring at the code. And I don't understand why these test cases are not passing. It's a very frustrating position to be in. And there's always that moment. There's always a light bulb moment. After I experiment a little bit further. You know in a previous episode. Recent. I guess last week. We talked about how experimentation is so important. And prototyping is so important for progress. But there's always this moment. This light bulb moment. Where either I realize. Oh that's not doing what I thought it was doing. Or I realize. Oh I have to accommodate for this other thing. This other case that I wasn't thinking about. This weird fringe example. This weird fringe case. But I want to talk about a way of potentially avoiding some of these positions. Of not really knowing what's going on. And we're going to talk about that right after we talk about today's sponsor Linode. If you've been listening to Developer Tea pretty much at all. You've probably heard us talk about Linode many times. And that's because Linode has invested in this community. They've been our longest running sponsor on this show. And they really invest in us. They really invest in the development community. Not just by buying sponsorships on Developer Tea. But also by creating services. And documentation of those services. That really make your jobs easier as developers. With Linode you can deploy your own node. Your own Linode node. For $5 a month. This is their entry level plan. And pretty much everybody has $5 a month. So if you're serious about development. You can deploy your own node. And you want to launch a web service for example. You can do that for $5 a month. And it's not a crippled server either. It's a gigabyte of RAM. Which is more than enough. For almost every experiment project that you have. So $5 a month is their first plan. And they go all the way up. To astronomical high memory plans. That you can find out more about these at Linode.com by the way. So if you're interested in switching to Linode. You can do that. And you can do that. And you can do that. And you can do that. And you can do that. And you can do that. And you're kind of reticent. You don't really want to go through that work. Well luckily Linode has a migration guide. It's available right on their website. You can find it in their primary navigation. They know that a pain point for you. If you're going to come to Linode. Is for you to migrate from your old place. To your new place. Right? This is kind of making things easier for you as a developer. But it doesn't stop there. They have tons of other services. Tons of features. On their servers. That make your life easier. If you lock yourself out of a system for example. Well they have a way of getting out of that conundrum. So Linode really does go the extra mile. And on top of that. You're going to get $20 worth of credit. Just for being a developer T listener. Go and check it out. Spec.fm. Slash Linode. Spec.fm. Slash Linode. Use the code developer T. 2018 at checkout. And you'll get $20 worth of credit. And you can use that on any of their services. Go and check it out. Spec.fm. Slash Linode. Thank you again to Linode for sponsoring today's episode of Developer T. So we're talking about ways of avoiding this weird scenario. This situation where you end up either not seeing something in your code. Or thinking that your code is doing something that it's not. And there's no silver bullet for this problem. There's no silver bullet for debugging. Right? There are hard bugs that will ultimately take. A lot of your time and energy to trace down. But there is a practice that I have found. That really helps. Especially when I'm dealing with object oriented code. Again. We try not to focus on one paradigm. But with object oriented code. This particular practice has been extremely effective for me. And that is to view everything that I do. As an object. Let me explain that a little bit more. More thoroughly. Every action that occurs in your application. Whether that's some kind of transaction of data. A change that a user makes. Any kind of procedure at all. If we create some kind of record of this. It's not just saving it to the database. But creating some kind of object. That explains what this action is. Right? Don't just create the action itself. But create an object. That represents. That action. So if you're sending mail. If you're sending an email. For example. Create an object. That represents the sending action itself. Not just the email. Right? Not just email.send. Not just creating the send action. But instead. Creating an object that represents that action. What is the nuance difference here? Well ultimately. What this allows you to do. And this is kind of. The magic. Aha moment. For this. Thinking of actions as objects. Or thinking of them in terms of transactions. If you start thinking this way. And you start building your code this way. Especially if you go. You know. Kind of all the way with this. If you take every action into consideration. And you record every single action. Even if you're recording it in memory. You have the opportunity now. To go back in history. Now if you're a. React and read. Ducks developer. Then you probably have already seen this. Maybe in a demo. Every single change. Is created. And kind of stored. In the Redux store. What this means is. You have every single change to the data. Which ultimately. Results in a rerender ring. If you're using react in this particular example. It results in a rerender ring. Every single render that you. Have seen. You can go back. And rewind. And see. What the render would have looked like. At any previous state. And this wouldn't be possible. If you weren't recording the changes themselves. It's not just simply changing the data. It's recording what the change was. This allows you to replay. All of those changes. It also allows you to debug. In a much more effective way. Because you can kind of insert. Your debugger. At any point. In that. In that line of changes. And you can inspect the information. That's happening at any given point as well. Right so. This allows you to have a lot more insight. Than simple procedural code would allow. And the first response. That I usually get. In this kind of conversation. Is that this is going to be a lot of work. Right this is going to take a lot of time. To abstract these things. And put them in their own classes. Or you know create these. These kind of models. For. Managing this stuff. But the reality is. This isn't a new idea. So a lot of the time. You're going to find. Whether you know for example. A Ruby gem. You're going to find a. Some kind of software package. That will help you do this. In a more robust. And automatic kind of plug and play way. But I also want you to recognize. That you know. You don't actually have to. As we said already. You don't actually have to save this stuff. To the database. For this to be an effective concept. If you create. Highly detailed. Log messages for example. Give yourself. A lot of information in the log. And trace. Every action that you're taking. Trace every change. To the data that you're making. Log more often. Throughout those processes. What you'll find is. You know a lot of the time. We don't actually take advantage. Of those logging features. We don't know what the state is. At a given point in time. We don't actually watch the changes. As they occur. We can't really look back at that history. At that trail that we leave behind. And we're making guesses. And there's really so much that we can do. To stop guessing. And there's so much that we can do. To avoid being in that situation. Where you think your code should be doing one thing. But it's actually doing another. Thank you so much for listening. To today's episode of Developer Tea. Of course this is not. Once again. It's not a silver bullet solution. It is one way. That you can start. To get more control over your code. And there's a lot of ways. Of implementing this. Again this is not a novel concept. This is not something I made up. This is essentially the same thing. As having versions. Or having a kind of log. Of changes. A history. There are a lot of different paradigms. That will accomplish this. In the same goal. So again start thinking of your actions. In terms of objects. There's a lot of other implications to this. If you go really far down this road. Then you can connect every action. For example. If you're building a web application. You can connect every version. And every change that you've made. To a URL. You can make each of those versions. Available if you wanted to. So that's one example. Of a benefit. That you can make. Even an extra benefit. On top of the debugging benefits. That you'll get. You also have more flexibility. Of what you can do now. With that information. If you gather it. Thank you so much for listening. And thank you again to Linode. For sponsoring today's episode. Of Developer T. Head over to spec.fm. Slash Linode. Use the code DeveloperT2018. At checkout. And you'll get $20 worth of credit. Thank you again to Linode. Thanks so much for listening. If you're enjoying this episode. And if you've enjoyed recent episodes. Of the show. And you haven't yet subscribed. You can subscribe. Go to whatever podcasting app. This is playing in right now. Before you forget. And go ahead and subscribe. This is going to allow you to be notified. Whenever a new episode comes out. And we have three of them a week. So it's very important. That if you want to stay up to date. That you subscribe. Thanks so much for listening. And until next time. Enjoy your tea.