Hey, everyone, and welcome to Developer Team. My name is Jonathan Cottrell, and in today's episode, we are going to be talking about air, fuel, and ignition. Today's episode is about debugging. Specifically, I want to talk to you about something a co-worker of mine mentioned today at work, and it kind of lit a light bulb over my head. My co-worker, who has been on the show before, his name is Patrick, I'll link to that episode in the show notes. He and I were talking today, and he mentioned a concept that I knew kind of intuitively, but he really cleared it up for me when he made this connection, this metaphorical connection. You know, Patrick used to work in a motorcycle shop, and we were talking about debugging with another one of our co-workers, and he mentioned the bike shop as a place where he learned about the process of troubleshooting. And I wanted to share this metaphor with you today, hopefully help some of you learn a bit more about the process of troubleshooting. For your own projects. Of course, this isn't the only method of troubleshooting, but it is certainly a powerful one, and we can learn a lot from this particular method. So we're talking about air, fuel, and ignition. What is that referring to? Well, with a combustion engine, that's in most cars, lawnmowers, and coincidentally motorcycles, there are really three primary forces that cause an engine to run or not run, right? We know that a... An engine uses fuel. But how do we convert that fuel into mechanical energy? Well, these three areas are air, fuel, and ignition. With these three things, you can ignite the fuel, right? You can burn the fuel and convert it into mechanical energy. Now, we won't go into many of the details here, but the basic idea is that almost all problems that you face with the combustion engine not starting can be traced back to an issue in one of these three areas. Now, what's interesting is that at the intersection of these three areas, that's where the engine gets its power, right? But we have to have these three systems working separately from each other in order for them to come together properly. If you don't have air, or if you don't have fuel, or if you don't have ignition, then you won't have an engine. So here's the part I don't want you to miss. When troubleshooting... When you're dealing with an issue, Patrick said his shop would start by determining which of these three areas the problem was affecting. Perhaps it is a combination of two of the areas, or maybe all three, but most likely and most commonly, the issue is stemming from only one area. Now, from here, you would then walk through each of the systems related to that particular area. So let's say the engine isn't getting fuel. Well, then you might start by checking to make sure that there's actually gas in the car. Assuming you have gas, you may then check the most common item to fail in the fuel supply chain. Let's just say, for example, that it's the fuel pump. Next, you might look for an issue with the fuel lines, and so on, until you've checked all of the system, the entire fuel supply system, right? Now, I'm not a skilled mechanic, but hopefully you get the picture here. I'd like to help you apply the same metaphor to your work when you are troubleshooting. When you start to understand a problem in a system, a software system, you should create a framework that will help you diagnose the issue. You need to identify your larger systems at play. You may be relying, for example, on external services, and if you don't diagnose the issue with the idea that the external service may be, for example, intermittent, you might be trying to track down an error in your code. That is actually a problem. That is actually a problem. That is actually a problem. That is actually originating in the external service. Or maybe you have an application that has front-end JavaScript and a server back-end. If you have an error on the front-end that is preventing the page from showing up or behaving in a particular way, and you don't identify the originating system that the error is stemming from, you may spend unnecessary time trying to debug the back-end server code when the front-end is the originator of the issue. Now, you can continue. You can continue this debugging process or this troubleshooting process by defining systems at each level, and instead of looking at the error directly, determine the positioning of that error, the context of that error. Where is it coming from in the system? What are the parallel systems that this error could originate from? Here's why this is so powerful. If you don't hear anything else in this discussion, listen to this part. The reason this type of troubleshooting is so powerful, is because you are eliminating large amounts of possible problem areas rather than diagnosing the error from the entire possibility pool. Let me say that again. You are eliminating large amounts of possible problem areas rather than diagnosing the error from the entire possibility pool. This means that you're simply using a process of elimination rather than a process of discovery. Where discovery says, this could be anything at all, so let's start here and see where it takes us, elimination says, this can only be one of these things. This helps narrow down hugely complex problems into their smaller component parts and allows you to solve the problem intelligently and intentionally rather than accidentally. So here's what I want you to do. The next time you experience an error in whatever application you're working on, you may want to consider bringing yourijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij In our previous example, we were talking about a JavaScript error in the console. So we can start there. We know that the error is showing up in our console. In other words, we know that there's something that JavaScript is detecting as a problem. Now, we don't necessarily know the origin of the problem, but we know that JavaScript is detecting the problem at that point, right? That is what you're doing there is you're starting with the known truth, and that will eliminate anything that that truth disproves. So in this particular case, it eliminates the idea that either there is no error coming from the server or there is no error in our JavaScript. What this means is you could be logically processing things correctly, but you may have a syntax error or maybe you have an encoding error in your code. And that eliminates a lot of the problem areas that you may that you may chase down. So you're not going to look for a logic error first. You're going to look for a syntax error first. And in a future episode, we might talk about different classifications of errors. For example, the syntax error versus the logic error. But I'd love for you to try this. Go ahead and identify some of these surrounding systems and the parallel systems that are at work in whatever application. You are working on. And then let me know how this goes. You can reach out to me on Twitter at at developer T or you can email me at developer T at gmail.com. Of course, you can join the spec slack community by going to spec dot FM slash slack. I would love to hear your stories about how diagnosing errors and this with this particular format, this troubleshooting format, how this helps you and how you approach troubleshooting if you approach it in a different way. Thank you so much for listening to developer T. If you'd like to not miss out on future episodes, make sure you subscribe in whatever podcasting app you use. Pretty much every podcasting app allows you to subscribe. That ensures that the episodes get delivered directly to your device three times per week. That's how often this show airs. So go and subscribe. And if you're enjoying developer T, make sure you leave a review on iTunes. This is the best way to help developers just like you. Find the show. Thank you so much for listening. And until next time, enjoy your tea.