Perhaps you faced the same problem that I've faced so many times as a front end web developer, where something works perfectly fine on my machine or it works fine on my cell phone, it works fine inside of my network, but the client or a coworker or someone else in the industry randomly tweeting at me will let me know that something is broken that is not working for them. Now everything tells me that it should be working. I see everything working on my end and everything that I can try is affirming that. I believe that it's working and I just assume that the other person, I naturally have the bad disposition of assuming that the other person has done something wrong and so I'll tell them to clear their cash, clear their cookies or whatever, right? This can be a harmful situation to be in. In today's episode, we're going to talk about ways to kind of signal yourself when you're in that situation. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on this show is to help driven developers connect to their career purpose. They can do great work and have positive influence on the people around them. Now we're not just talking about when a client reports a bug and we're not just talking about it works on my machine and it doesn't work on someone else's machine. Today we're talking about reasoning. We're talking about reasoning through problems and this is the fourth episode in our problem solving series. We're talking about reasoning because there's so many different ways that we reason about an issue that we reason about a problem and seeing a problem clearly as you've hopefully heard in the previous episodes in this little mini series that we're doing, seeing a problem clearly is really a big portion of the battle. Once you understand the shape of the problem, then the rest becomes figuring out the best solution and really you can kind of see the pathway and you're just trying to figure out which vehicle to take on that pathway. But sometimes we believe we see something clearly. We believe that we're actually viewing the problem holistically that we understand the problem or that we understand some part of the problem and in reality our view is distorted. We've talked about bias on almost every episode of Developer Tea and in today's episode we're not talking specifically about bias but instead we're talking about types of reasoning. Of course bias plays into this. For example, if I believe I'm correct then I'm probably likely to seek out information that affirms that I am correct and so I'm going to go and reload the page on my end and it's going to tell me the same thing that I already know that the thing in question is still working on my end as I expect, right? And this is the confirmation bias at play. But we're talking about reasoning and really seeing the problem clearly in today's episode and really we're talking about assumption. We're talking about these hidden assumptions, these things that we accidentally bring into the problem solving process that we don't realize we're introducing. And so what we often do is we introduce our own inductive reasoning, our inductive reasoning. Well what does this mean? Well essentially it means that we're watching or we're observing something, we're kind of inspecting something and then we bring out of that a generalized label, a generalized assumption, a rule, a way of thinking. And so we take something that we've observed and we use that to inform the way that we see things. Now of course if you have heard the term inductive reasoning then you've probably heard the term deductive reasoning. This is a more popular term and really deductive reasoning takes something that we know to be true or that we know to be commonly accurate and it applies it to a situation rather than drawing a new insight out of a given situation. We're applying some kind of theorem or some kind of thought pattern. We're taking that information and we're applying it to a situation. So what is this matter with our problem solving? We're going to talk about that right after we talk about today's sponsor, Linode. Linode has sponsored Developer Tea for quite a long time now and hopefully you have tried out Linode but my guess is that you don't know all that Linode has to offer yet. That's because Linode has so many various add-ons and extra services that you may not have had a chance to use yet. For example, LongView. LongView allows you to see how your server is performing over time. Another example, Note Balancer. Linode automatically kind of balances the incoming traffic to multiple Linode instances so you can spend up a couple of the five dollar one gigabyte RAM instances and then use Note Balancer to balance your traffic between those. There's tons of other awesome services. For example, if you don't want to get involved with DevOps, Linode has professional DevOps services that they provide so that you can stay focused on the application you're building on your business. Remember, you can get started with any of their plans and services for as little as five dollars a month and Linode is going to give you $20 worth of credit just for being a Developer Tealistener. Go and check it out. Spact out of them. Slash Linode. You can use the code Developer Tea2018 at checkout to get that $20 worth of credit. Thank you again, Linode, for sponsoring today's episode of Developer Tea and for helping developers do their jobs better. So we're talking about deductive and inductive reasoning. We've already outlined the difference, but real quick, a recap. Deductive reasoning is taking something that you already know to be true from previous experiments or examples or maybe even science, right? Taking that information and applying it to a new situation, to something that you're experiencing. An inductive reasoning is observing a given experience, observing a given event, and then trying to draw out some information from that event. Now, why is this important? Both inductive and deductive reasoning are important to use. You should be able to perform both of these types of reasoning. And you do. Every human has this learning mechanism. And what we do is we first start with inductive reasoning. We learn even the most simple things that we learn as infants, we learn through inductive reasoning, trial and error, we observe and we learn. And then we take what we've learned and we use it in the future. My son, who recently turned 11 months old, has learned that if he can throw his pacifier out of the crib, that mom or dad will come and visit him. And so he's using this inductive reasoning and this learning loop to kind of create a cause and effect. So if he wants to see mom and dad in the middle of the night, then perhaps he'll throw his pacifier out of the crib. So we can't survive without both of these types of reasoning, inductive and deductive. The interesting thing is that humans are able to pass down information and share information so that we can kind of expand on our deductive reason. I can use the information that I've learned from someone else. I don't have to have first-hand experience. I can rely on first-hand experience from other people. So all of this becomes very important when we're trying to solve a problem because very often we use the wrong piece of reasoning, the wrong type of reasoning in a given scenario. So take our previous example where it's working on my machine but it's not working on your machine. Well in one way, I'm using inductive reasoning and I'm saying that my experience of loading this on my machine should be enough to generalize to everyone else. This is unfortunately flawed logic but that's what's informing my problem solving process in that moment. I'm saying that it's working here and therefore it is working. That's my inductive reasoning kind of a line chain of logic. However, if I use deductive reasoning, then I can observe the fact that it's not working on my machine and it is working on another. But then I can go back into my catalog of reasoning of other situations where this has occurred, of situations where other developers have experienced the same thing. And I can try to fit those other problems as a generalized model for this problem. So deductive reasoning may say that usually when it works on one machine and it doesn't work on another, given all things being equal like browser type and machine type, given all those things being equal that when it doesn't work on the second machine that it may be a caching problem, that's deductive reasoning. So we're using something that we've already learned in the past, we're using some kind of information to build up a model so we can apply that information to our particular problem. Now this particular problem is not all that complicated, right? This is something that developers face all the time. But when you do have a more complicated problem, sometimes it's a little bit harder to recognize when you're in one type of reasoning mode versus the other. It may feel like inductive reasoning or it may feel like deductive reasoning, but actually it's the opposite. Here's the interesting piece of the puzzle that I don't want you to miss out on because it's kind of a nuanced thing, the differences between the deductive and the inductive reasoning. It is important that you have a solid foundation for good deductive reasoning. A better way of putting it is if you are the only person who has used inductive reasoning in the past and now you've come up with a conclusion and you kind of swapped that information over into your deductive tool bank. Right? It's very possible, if not likely, that that information needs to be tested and tried more times before you can really rely on it. In other words, let's say that that previous example where it wasn't working on the other person's machine was because for some reason the CDN provider saw this IP address and thought it was malicious. Well, this is an uncommon event. This is not going to happen very often. This would be kind of an anecdotal one-off statistical anomaly of an event. If you build a mental model, if you kind of build your heuristics, if you are creating something to put into your tool bank on the deductive reasoning side based on that one experience, then you're very likely to kind of come to very specific and very unlikely conclusions in the future when you experience the same problem again. Let me explain that a little bit more simply with visualization. Let's say you go to the casino and you pop a coin into the slot machine and you win. And not only do you win the first time, but you win the second time and you win the third time. Now, unfortunately, I know standing off to the side that this slot machine is not rigged to win more often than any other slot machine just so happens that you were in a statistical anomaly that this happened to occur for you. Call it luck, call it entropy, call it randomness, for some reason these three wins occurred right in a row. Now, if you were to build up your deductive reasoning and try to decide should I put another coin into the slot machine, your deductive reasoning at that point based on your only experience with that slot machine, your deductive reasoning may tell you, of course, you should. You're going to win 100% of the time on this machine. And this is what happens when we use our own anecdotes, our own individual experiences, we try to create broad generalized information from them. We must have a much more balanced view that takes into account a larger sample size. Not only a larger sample size, but we need to configure the way that we solve problems to things like base rates. In other words, what is the most common reason that this problem occurs? Let's try solving it from that angle first. Now, what is the second most common reason that this particular problem occurs? Of course, this is only valid if you have no extra information that is pointing you to a specific cause, right, to a specific outcome, to a specific solution. But if you have no extra information, if you only have kind of the nominal description of the problem, then it's important that if you're going to try to use deductive reasoning as you solve this problem, then you don't draw only on your own experience if possible, right? Try to draw on as many experiences as you can and as many other instances of this problem as you can and don't chase something based on a hunch. This is kind of a disciplined approach to problem solving. And it's very important that you learn this young in your career early in your career so that you don't end up in that situation where you've walked into into the casino and you've played the slot machine three times in a row and you won three times in a row. This can be a very difficult place to be when you're solving a problem and it can be very expensive. I encourage you to understand and practice both inductive and deductive reasoning. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Linode for sponsoring today's episode. You can get started on Linode for as little as $5 a month and Linode is going to give you $20 worth of credit, which is essentially for free months on their service. Go and check it out, spec.fm slash Linode to get started today. Thank you so much for listening to today's episode. If you don't want to miss out on future episodes about things like inductive and deductive reasoning, go and subscribe and whatever podcasting app you use. Thank you so much for listening to this episode. This will be the last episode in our problem solving series, but we certainly will continue talking about problem solving in future episodes. Thank you so much for listening once again and until next time, enjoy your tea.