Join Justin Putney for an in-depth discussion in this video A framework for problem solving, part of Problem Solving for Web Professionals.
- In this video, we'll explore a process that can be used to effectively solve problems of any type. First I want to walk you through a step by step process to solve a problem. And then we'll talk about some strategies that you can use when you get stuck on challenging problems. So here's an overview of the steps. And we're going to go into detail on each one of these. First you want to gather info. Gathering info is the stage where you're trying to understand the problem. And not just the problem, but the causal chain of the process that you're looking at.
So if you're having a problem with your car but you don't understand how the engine works there's not much you can do about the problem. This gathering info stage is where Sherlock Holmes walks into a room and starts looking around. He's just trying to get information. We want to go for a stage where we have basically this blacked-out box. We just know that stuff happens. and we want to get to a point where we understand some of the pieces. Well first, A happens, and then B happens, and then C, and I think A causes B and so on.
When you start to understand that, you need to try and get to a point of repeatability. Where you can cause the problem to happen over and over. And you understand the set of conditions that cause the problem. Does it happen in a particular operating system or a particular browser. Does it happen after you click a button? So you get to a point where you have a know input, you plug it into the process, and you get a known output. In this case is going to be that the thing doesn't work. And if you change your know input, you can get it to work.
That's if the problem is specific to this particular case. So that is the process of getting to repeatability. Next you're going to start developing hypotheses. These are guesses as to what might be going on. Of course you're not going to necessarily know it at this stage. You just need to have some guesses so that you can start testing something. And you want to narrow your focus so that you're doing small tests with tight feedback loops. And we're going to talk about feedback loops in the next video, so I won't go into a lot of detail right now. But, basically, to get to your small test, you want to take the part of the problem or the part of the process that you don't understand or you don't know what's going on.
You break that into smaller pieces, so you can test those individual pieces. In programming, this is know as Unit testing. One very famous early example of what we described as a Unit test, or what should've been a Unit test was the 1986 Challenger's space shuttle disaster. After the space shuttle exploded, there was an investigation into the cause. It's a very distinguished panel, and there was also a kind of unique personality in Richard Feynman, who was a physicist.
And he actually descended from the main opinion in the report. Feynman had a huge endigment of NASA in the process of building the spaceship because it was all done top-down. And it was really hard to find an issue when everything is done top-down. Because you don't know what piece of the process is broken down if it's one big black box. It turned out, in this case, that there was a small rubber ring called an O-ring and it hadn't been tested in cold weather conditions.
It was a little bit cold when the space shuttle took off. The rubber couldn't be flexible at that temperature. And that small part caused a very big problem. So it's important when you're working on a problem to break it into smaller pieces and test those pieces so you can be certain under what conditions something breaks, and under what conditions it works. And as you're going along, you want to document not only the large pieces, but the small individual pieces. So that when you come back to this problem even if you, say, you haven't found a solution or maybe six months later, you run into something again, you don't have to rediscover the solution.
Now when you get really stuck here are three strategies to help you get unstuck. And I'll go through these in detail right now. First, assume there's a solution. I have two examples for this. The first one is from my personal experience. In college I was taking a Logic class. And at the back of the book there were answers to the problems. So if I got stuck, I could just look there. But I really wanted to solve the problems myself. And every once in a while I'd run into one and I was quite good at this so, I probably had some over confidence.
And I'd get to a problem that I couldn't figure out and based on my over confidence I thought "well, they just made a mistake in the book". And there isn't a solution to this problem because there's a typo or, they just didn't fact-check this. And some part of me thought, "well I really want to solve this problem", and "I'm just going to assume that they didn't "make a mistake here, and that it's me "who's making the mistake. "And I'll just stick with the problem "and see what I can figure out". And, actually on multiple occurrences I would get a solution worked out.
I would be sure it was a valid solution. I'd go to the back of the book and I'd look and they actually had a different solution. I would test that solution and that solution was also valid. So, I was completely wrong about there being no solution. In fact, there were multiple solutions to the problem. So, I found tremendous power in just assuming before hand that there was a solution. Now this process of assuming the solution and sticking to the problem-solving process is something that Carol Dweck describes in her book Mindset, which i highly recommend.
I wont go over the book too much, but she talks about a type of mindset called a Growth Mindset, and that's essentially what assuming there's a solution is. In one example she describes a graduate student coming into class late, seeing a math problem on the board. He assumed it was the homework. Copied it into his notes. Went home. Couple of weeks later, came back. Handed in his homework. Said to the professor, "I'm really sorry, "I know this took a long time, "but I've just been busy, "and I hope it's okay that it's late".
And it turns out that, this wasn't even homework, this was something the professor put on the board as an unsolved problem. It had remained unsolved by all kinds of famous mathematicians. And this kid just thinking was homework came in, spend more time on it, figured it out. So there's tremendous power in just assuming there's a solution. Next, this comes from Charlie Munger, where in Buffet's business partner he talks about inverting the problem. So, if you get stuck on a problem, maybe change your thinking.
Instead of thinking about how to avoid the problem, you can think about how to cause the problem. Maybe that allows you to understand the problem from a different angle. If you think about you being the browser and what if I wanted to make this video not show up how would I go about doing that. Often times inverting the problem that way leads you to novel solutions. And last and most importantly, take a break, take frequent, even small breaks. The most famous example of taking a break is the ancient Greek scientist Archimedes.
He'd been stuck on a problem for a very long time and hes wife said "why don't you take a bath?". Archimedes jumps into the bath. The water level rises. And he figures out buoyancy. And, if you're like me, you probably figure out a lot of your most important problems in the shower when you're no longer really thinking about them. There is something magical about taking a break. And specially if you get into a situation that I call Random Switch Flipping. So if you get to a place, and you're just twicking stuff. Maybe if this was four pixels instead of two pixels it'd line up and just doing little itty-bitty things.
That's usually a sign that you're stuck. Because the solution actually comes from looking at something a different way. Changing a category. It's usually not minor little inches. So, take a break, come back to the problem fresh. So here's everything at a glance that we talked about. Don't worry about memorizing it. We'll practice these steps and strategies as we go through the course. And eventually, as you use them in your real work, they'll become second nature. So now that we've covered the steps and the process, let's narrow our focus down, and we're going to take a look at narrowing our focus in the next video.
Learn to turn your web browser into a code inspector, cope with browser incompatibilities, perform cross-platform testing, and more. Justin Putney gives you the skills you need to address the unique problems in each new project—and ensure the quality of your design and your code.
- Using web inspection tools
- Finding and destroying HTML errors
- Locating missing assets
- Supporting Internet Explorer
- Becoming a Google search master
- Testing with online snippet editors, emulators, and more
- Testing responsive layouts
- Debugging code
- Adding new functionality