Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell 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 coworker of my mentioned today at work and it kind of lit a light bulb over my head. My coworker who has been on the show before, his name is Patrick. I will 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. Patrick used to work in a motorcycle shop and we were talking about debugging with another one of our coworkers and he mentioned the bike shop as a place where he learned about the process of troubleshooting. I wanted to share this metaphor with you today. We 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. We're talking about air, fuel and ignition. What is that referring to? Well, with a combustion engine, that's in most cars, lawn mowers and coincidentally motorcycles. There are really three primary forces that cause an engine to run or not run. We know that an engine uses fuel, but how do we convert that fuel into mechanical energy? These three areas are air, fuel and ignition. With these three things, you can ignite the fuel. You can burn the fuel and convert it into mechanical energy. We won't go into many of the details here, but the basic idea is that almost all problems that you face with combustion engine not starting can be traced back to an issue in one of these three areas. What's interesting is that at the intersection of these three areas, that's where the engine gets its power. 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. Here's the part I don't want you to miss. When troubleshooting 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 stimming from only one area. From here, you would then walk through each of the systems related to that particular area. Let's say the engine isn't getting fuel. 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. 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 originating in the external service. Maybe you have an application that has front-end JavaScript and a server backend. 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 backend server code when the front-end is the originator of the issue. You can continue this debugging process or this troubleshooting process by defining systems at each level. 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. For a discovery, this could be anything at all. 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. Here's what I want you to do. The next time you experience an error in whatever application you're working on, take a moment and think about what systems are surrounding that error. What is the context of that error? How could you go through the process of elimination for removing issues that are unrelated to the error? A good model for doing this is by starting with what you know. You can say, well, we know that the error is showing up in our console in the browser. For example, in our previous example, we were talking about a JavaScript error in the console. 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. We don't necessarily know the origin of the problem, but we know that JavaScript is detecting the problem at that point. What you're doing there is you're starting with the known truth and that will eliminate anything that that truth this proves. 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. That eliminates a lot of the problem areas that you may chase down. You're not going to look for a logic error first. You're going to look for a syntax error first. In a future episode, we might talk about different classifications of errors. For example, the syntax error versus the logic error. 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. Let me know how this goes. You can reach out to me on Twitter at at Developer Tea or you can email me at Developer Tea at gmail.com. Of course, you can join the spec Slack community by going to spec.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 trouble shooting if you approach it in a different way. Thank you so much for listening to Developer Tea. 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 errors. So go and subscribe. If you're enjoying Developer Tea, 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.