Vox

Leitura de 18 min

Problem Solving Series #4: Inductive and Deductive Reasoning

Summary

This episode delves into the critical distinction between inductive and deductive reasoning within the context of software development and problem-solving. The host, Jonathan Cottrell, frames the discussion around the classic developer frustration of a feature working on one machine but failing on another, highlighting how our natural reasoning processes can lead us astray.

Inductive reasoning is described as observing specific events and drawing a generalized rule or assumption from them. The host illustrates this with a personal example of assuming a website bug is the user’s fault because it loads correctly on his own machine. Deductive reasoning, in contrast, involves applying established knowledge or generalized models to a new, specific situation. An example given is diagnosing a caching issue based on past, common experiences with similar cross-machine failures.

The discussion emphasizes that both reasoning types are essential human learning mechanisms. We start life with inductive reasoning (trial and error) and build a bank of knowledge for deductive use. However, a key pitfall is incorrectly applying reasoning, such as using a single, anecdotal experience (inductive) to form a broad rule for future deductive application. The host uses the analogy of winning a slot machine three times in a row and then assuming it will always pay out to warn against building heuristics on statistically anomalous events.

The episode concludes with practical advice for disciplined problem-solving. When facing a problem with limited information, one should consult a larger sample size beyond personal experience, consider base rates (the most common causes), and avoid chasing hunches based on flawed inductive generalizations. This approach helps developers avoid costly mistakes and solve problems more effectively.

Recommendations

Tools

  • Linode — A cloud hosting provider sponsored the episode. It offers services like Longview for server performance monitoring, NodeBalancer for traffic distribution, and professional DevOps support. Listeners can get started for 20 credit.

Topic Timeline

  • 00:00:00 — Introduction to the ‘It Works on My Machine’ Problem — Jonathan Cottrell introduces the episode’s theme by describing a common frustration for developers: when something works perfectly on their own system but a client or colleague reports it as broken. He admits to a natural, harmful disposition of assuming the other person is at fault. This sets the stage for a discussion on reasoning and hidden assumptions in problem-solving.
  • 00:01:29 — Defining Inductive and Deductive Reasoning — The host formally introduces the core concepts. Inductive reasoning is defined as observing specific events and drawing out a generalized rule or assumption. Deductive reasoning is the inverse: taking a known rule or model and applying it to a new, specific situation. The episode’s goal is clarified: to help listeners recognize which type of reasoning they are using and avoid the pitfalls of each.
  • 00:07:03 — The Importance and Pitfalls of Both Reasoning Types — Cottrell explains that both inductive and deductive reasoning are essential human learning tools, using the example of an infant learning cause and effect. The danger arises when we use the wrong type for a scenario or build deductive models from flawed inductive observations. The ‘works on my machine’ problem is re-examined: using only personal observation (inductive) leads to the wrong conclusion, while applying common troubleshooting knowledge (deductive) is more effective.
  • 00:11:53 — The Danger of Anecdotal Evidence and Base Rates — The host warns against building deductive reasoning tools from rare, anecdotal events, likening it to winning a slot machine three times and assuming it’s always a winner. He stresses the importance of a larger sample size and considering ‘base rates’—the most statistically common causes of a problem. Effective deductive reasoning should draw on broad, validated experience, not just personal hunches, to avoid expensive problem-solving errors.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-05-16T09:00:00Z
  • Duration: 00:16:28

References

Podcast Info

Transcript

[00:00:00] Perhaps you’ve faced the same problem that I’ve faced so many times as a front-end web developer

[00:00:09] where something works perfectly fine on my machine or it works fine on my cell phone,

[00:00:15] it works fine inside of my network, but the client or a co-worker or someone else in the

[00:00:24] industry randomly tweeting at me will let me know that something is broken that is not working for

[00:00:29] them. Now everything tells me that it should be working. I see everything working on my end

[00:00:36] and everything that I can try is affirming that. I believe that it’s working and

[00:00:44] I just assume that the other person, I naturally have the bad kind of disposition of assuming that

[00:00:51] the other person has done something wrong and so I’ll tell them to clear their cash,

[00:00:55] clear their cookies or whatever, right? And this can be a hard,

[00:00:59] harmful situation to be in. And in today’s episode, we’re going to talk about ways to

[00:01:04] kind of signal yourself when you’re in that situation. My name is Jonathan Cottrell and

[00:01:10] you’re listening to Developer Tea. My goal on this show is to help driven developers connect

[00:01:14] to their career purpose so they can do great work and have positive influence on the people around

[00:01:20] them. And we’re not just talking about when a client reports a bug and we’re not just talking

[00:01:24] about it works on my machine and it doesn’t work on someone else’s machine.

[00:01:29] Today we’re talking about reasoning. We’re talking about reasoning through problems and this is

[00:01:34] the fourth episode in our problem solving series. We’re talking about reasoning because there’s so

[00:01:41] many different ways that we reason about an issue, that we reason about a problem.

[00:01:47] And seeing a problem clearly, as you’ve hopefully heard in the previous episodes in this little

[00:01:52] mini-series that we’re doing, seeing a problem clearly is really a big portion of the battle,

[00:01:59] right?

[00:01:59] Once you understand the shape of the problem, then the rest becomes figuring out the best

[00:02:06] solution. And really you can kind of see the pathway and you’re just trying to figure out

[00:02:13] which vehicle to take on that pathway. But sometimes we believe we see something clearly.

[00:02:21] We believe that we’re actually viewing the problem holistically, that we understand the problem

[00:02:27] or that we understand some problem.

[00:02:29] Part of the problem. And in reality, our view is distorted. We’ve talked about bias

[00:02:35] on almost every episode of Developer Tea. And in today’s episode, we’re not talking

[00:02:41] specifically about bias, but instead we’re talking about types of reasoning.

[00:02:46] Of course, bias plays into this. For example, if I believe I’m correct, then I’m probably likely to

[00:02:53] seek out information that affirms that I am correct. And so I’m going to go and reload the

[00:02:59] page and I’m going to go and reload the page and I’m going to go and reload the page and I’m going

[00:02:59] to go and reload the page on my end. And it’s going to tell me the same thing that I already

[00:03:03] know, that the thing in question is still working on my end as I expect, right? And this is the

[00:03:09] confirmation bias at play. But we’re talking about reasoning and really seeing the problem

[00:03:13] clearly in today’s episode. And really we’re talking about assumption. We’re talking about

[00:03:20] these hidden assumptions, these things that we accidentally bring into the problem solving

[00:03:25] process that we don’t realize we’re introducing.

[00:03:28] And so what we often do is we introduce our own inductive reasoning. Our inductive reasoning.

[00:03:38] Well, what does this mean? Well, essentially it means that we’re watching or we’re

[00:03:42] observing something, we’re kind of inspecting something, and then we bring out of that

[00:03:49] a generalized label, a generalized assumption, a rule, a way of thinking. And so we take that

[00:03:58] and we take something that we’ve observed and we use that to inform the way that we see things.

[00:04:06] Now, of course, if you have heard the term inductive reasoning, then you’ve probably heard

[00:04:10] the term deductive reasoning. This is a more popular term. Really, deductive reasoning takes

[00:04:16] something that we know to be true or that we know to be commonly accurate and it applies it to a

[00:04:26] situation. Rather than drawing a line, we take something that we’ve observed and we use that to

[00:04:28] draw a line. So if we’re drawing a new insight out of a given situation, we’re applying some kind

[00:04:34] of theorem or some kind of thought pattern. We’re taking that information and we’re applying it to

[00:04:40] a situation. So what does this matter with our problem solving? We’re going to talk about that

[00:04:45] right after we talk about today’s sponsor, Linode. Linode has sponsored Developer Tea for quite a

[00:04:51] long time now, and hopefully you have tried out Linode. But my guess is that you don’t know all

[00:04:57] that Linode has to offer.

[00:04:58] That’s because Linode has so many various add-ons and extra services that you may not have had a

[00:05:06] chance to use yet. For example, Longview. Longview allows you to see how your server is performing

[00:05:13] over time. Another example, NodeBalancer. Linode automatically kind of balances the incoming

[00:05:21] traffic to multiple Linode instances. So you can spin up a couple of the $5 one gigabyte RAM

[00:05:28] instances and then use NodeBalancer to balance your traffic between those. There’s tons of other

[00:05:36] awesome services. For example, if you don’t want to get involved with DevOps, Linode has professional

[00:05:43] DevOps services that they provide so that you can stay focused on the application you’re building,

[00:05:51] on your business. Remember, you can get started with any of their plans and services for as little

[00:05:56] as $5 a month.

[00:05:58] And Linode is going to give you $20 worth of credit just for being a Developer T listener.

[00:06:04] Go and check it out. Speck.fm slash Linode. You can use the code DeveloperT2018 at checkout

[00:06:10] to get that $20 worth of credit. Thank you again to Linode for sponsoring today’s episode of

[00:06:15] Developer T and for helping developers do their jobs better. So we’re talking about deductive

[00:06:22] and inductive reasoning. We’ve already outlined the difference, but real quick, a recap.

[00:06:27] Deductive reasoning is taking something that you already know to be true from previous

[00:06:33] experiments or examples or maybe even science, right? Taking that information and applying it

[00:06:41] to a new situation, to something that you’re experiencing. And inductive reasoning is

[00:06:48] observing a given experience, observing a given event, and then trying to draw out

[00:06:57] some information from that event. Now, why is this important? Both inductive and deductive

[00:07:03] reasoning are important to use. You should be able to perform both of these types of reasonings.

[00:07:11] And you do. Every human has this learning mechanism. And what we do is we first start

[00:07:19] with inductive reasoning, right? We learn even the most simple things that we learn as infants,

[00:07:25] we learn through inductive reasoning.

[00:07:27] Trial and error, we observe and we learn, and then we take what we’ve learned and we use it in

[00:07:34] the future. My son, who recently turned 11 months old, has learned that if he can throw his pacifier

[00:07:41] out of the crib, that mom or dad will come and visit him. And so he’s using this inductive

[00:07:49] reasoning in this learning loop to kind of create a cause and effect. So if he wants to see mom and

[00:07:56] dad in the middle of the night, he can do that. And if he wants to see mom and dad in the middle of the night,

[00:07:57] then perhaps he’ll throw his pacifier out of the crib. So we can’t survive without both of these

[00:08:05] types of reasoning, inductive and deductive. The interesting thing is that humans are able to pass

[00:08:11] down information and share information so that we can kind of expand on our deductive reasoning.

[00:08:18] I can use the information that I’ve learned from someone else. I don’t have to have first-hand

[00:08:24] experience. I can rely on first-hand experience. I can rely on first-hand experience. I can rely on

[00:08:27] experience from other people. So all of this becomes very important when we’re trying to solve

[00:08:32] a problem because very often we use the wrong piece of reasoning, the wrong type of reasoning

[00:08:41] in a given scenario. So take our previous example where it’s working on my machine, but it’s not

[00:08:47] working on your machine. Well, in one way, I’m using inductive reasoning, and I’m saying that

[00:08:54] my experience of loading this on my machine,

[00:08:57] should be enough to generalize to everyone else. This is unfortunately flawed logic, but

[00:09:06] that’s what’s informing my problem-solving process in that moment. I’m saying that

[00:09:12] it’s working here, and therefore it is working. That’s my inductive reasoning kind of line

[00:09:18] chain of logic. However, if I use deductive reasoning, then I can observe the fact

[00:09:26] that it’s working on my machine, and therefore it is working on my machine.

[00:09:27] Not working on my machine, and it is working on another. But then I can go back into my catalog

[00:09:34] of reasoning of other situations where this has occurred, of situations where other developers

[00:09:42] have experienced the same thing, and I can try to fit those other problems as a generalized

[00:09:50] kind of model for this problem. So deductive reasoning may say that usually when

[00:09:57] it works on one machine and it doesn’t work on another, given all things being equal, like

[00:10:03] browser type and machine type, given all those things being equal, that when it doesn’t work on

[00:10:11] the second machine, that it may be a caching problem. That’s deductive reasoning. And so

[00:10:17] we’re using something that we’ve already learned in the past. We’re using some kind of information

[00:10:21] to build up a model so we can apply that information to our

[00:10:27] particular problem. Now this particular problem is not all that complicated, right? This is something

[00:10:31] that developers face all the time. But when you do have a more complicated problem, sometimes it’s a

[00:10:37] little bit harder to recognize when you’re in one type of reasoning mode versus the other. It may

[00:10:43] feel like inductive reasoning, or it may feel like deductive reasoning, but actually it’s the

[00:10:49] opposite. Now here’s the interesting piece of the puzzle that I don’t want you to miss out on,

[00:10:54] because it’s kind of a nuanced thing,

[00:10:57] the differences between the deductive and the inductive reasoning. It is important that you have

[00:11:03] a solid foundation for good deductive reasoning. A better way of putting it is,

[00:11:11] if you are the only person who has used inductive reasoning in the past, and now you’ve come up with

[00:11:19] a conclusion, and you’ve kind of swapped that information over into your deductive tool bank,

[00:11:25] right?

[00:11:27] It’s very possible, if not likely, that that information needs to be tested and tried

[00:11:33] more times before you can really rely on it. In other words, let’s say that that previous example

[00:11:40] where it wasn’t working on the other person’s machine was because for some reason the CDN

[00:11:47] provider saw this IP address and thought it was malicious. Well, this is an uncommon event. This

[00:11:53] is not going to happen very often. This would be kind of an uncommon event. It’s not going to happen

[00:11:55] very often. This would be kind of an uncommon event. This is not going to happen very often. This would

[00:11:55] be kind of an uncommon event. This is not going to happen very often. This would be kind of an

[00:11:57] anecdotal, one-off, statistical anomaly of an event. And so if you build a mental model,

[00:12:05] if you kind of build your heuristics, if you are creating something to put into your tool bank on

[00:12:11] the deductive reasoning side based on that one experience, then you’re very likely to kind of

[00:12:18] come to very specific and very unlikely conclusions in the future when you experience the same problem

[00:12:25] again.

[00:12:27] So let me explain that a little bit more simply with a visualization. Let’s say you go to the

[00:12:33] casino and you pop a coin into the slot machine and you win. And not only do you win the first time,

[00:12:42] but you win the second time and you win the third time. Now, unfortunately, I know, standing off to

[00:12:49] the side, that this slot machine is not rigged to win more often than any other slot machine. It just

[00:12:56] so happens that the slot machine is not rigged to win more often than any other slot machine. So

[00:12:57] that you were in a statistical anomaly that this happened to occur for you call it luck call it

[00:13:06] entropy call it randomness for some reason these three wins occurred right in a row now if you were

[00:13:13] to build up your deductive reasoning and try to decide should i put another coin into the slot

[00:13:20] machine your deductive reasoning at that point based on your only experience with that slot

[00:13:27] machine your deductive reasoning may tell you of course you should you’re going to win a hundred

[00:13:33] percent of the time on this machine and this is what happens when we use our own anecdotes

[00:13:39] our own individual experiences we try to create broad generalized information from them

[00:13:47] we we must have a much

[00:13:50] more balanced view that takes into account a larger sample size and not only a larger sample

[00:13:58] size but we need to configure the way that we solve problems to things like base rates

[00:14:06] in other words what is the most common reason that this problem occurs let’s try solving it

[00:14:12] from that angle first now what is the second most common reason that this particular problem occurs

[00:14:18] of course

[00:14:20] you

[00:14:20] this is only valid if you have no extra information that is pointing you to a specific

[00:14:28] cause right to a specific outcome to a specific solution but if you have no extra information if

[00:14:36] you only have kind of the nominal description of the problem then it’s important that if you’re

[00:14:43] going to try to use deductive reasoning as you solve this problem that you don’t draw only on

[00:14:49] your own experience with the problem you’re going to try to use deductive reasoning as you solve

[00:14:50] this problem if possible

[00:14:51] right try to draw on as many experiences as you can and as many other instances of this problem

[00:14:59] as you can and don’t chase something based on a hunch this is kind of a disciplined approach to

[00:15:06] problem solving and it’s very important that you learn this young in your career early in your

[00:15:11] career so that you don’t end up in that situation where you’ve walked into the into the casino

[00:15:17] and you’ve played the slot machine three times in a row and you want to solve this problem

[00:15:20] three times in a row this can be a very difficult place to be when you’re solving a problem and it

[00:15:26] can be very expensive i encourage you to understand and practice both inductive and deductive reasoning

[00:15:36] thank you so much for listening to today’s episode of developer t thank you again to

[00:15:40] linode for sponsoring today’s episode you can get started on linode for as little as five dollars a

[00:15:45] month and linda’s going to give you twenty dollars worth of credit which is essentially four free

[00:15:50] on their service go and check it out spec.fm slash linode to get started today thank you so much for

[00:15:56] listening to today’s episode if you don’t want to miss out on future episodes about things like

[00:16:01] inductive and deductive reasoning go and subscribe in whatever podcasting app you use thank you so

[00:16:07] much for listening to this episode this will be the last episode in our problem solving series

[00:16:12] but we certainly will continue talking about problem solving in future episodes thank you so

[00:16:18] much for listening once again and until next time

[00:16:20] enjoy your tea

Visão de gráfico