I’ll put the TL;DR first: “Fast is slow, and slow is fast.” – Dr. Douglas Hall
It’s not exciting. Once you get into the swing of things it can be, but talking about it isn’t exciting. Problem solving is a skill you’re actively learning from the time you walk until you burn out (or, you know, retire or something). Grade school introduces it, high school prepares us for using it for the “real world,” and college is where it’s examined and discussed if there is some kind of philosophical discussion around what “problem solving” means. I know this is also something that’s been talked about a million times. Taking a quick gander at Amazon, they are listing 23,064 books just in their “Decision-Making & Problem Solving” category alone. There are a couple of courses on Coursera based around problem solving in general. There are probably countless Ted talks as well. I guess it can’t hurt to add one more blog post about it, but I’m going to speak from a software developer’s perspective.
Everyone deals with problem solving every day in their life. There’s decision making all over the place. Every time a little something comes up that requires even just a modicum of thought to get through, you’re still problem solving. As a software developer, it’s literally my job to use my brain and figure out (hopefully) simple ways of solving problems, however simple or complex they themselves might be. That’s not to say other jobs don’t, but software is an interesting thing. It’s very essence is made up of the idea of having some kind of thinking problem, determining how to solve that problem, and using software to be able to do the actual solving.
But even then, there are problems that creep up during software development itself that need solving. Is a tool not acting in a manner that you expect it to? Is some function from a library not returning what you expect it to? Read the documentation; do a little digging, tinkering, and most importantly, thinking. Examine each piece, starting from wherever it makes the most sense to start, and take a good look at everything you come across. Make a list and check things off. Be like Santa, check it twice. When you start stepping back to see the forest for the trees, you’ll notice a pattern. You have to be able to slow down enough to be able to get far enough away to see them as a whole, though.
Patience. Patience is the most important tool, and sometimes the most difficult one to utilize when trying to figure something out. It’s so easy to just rush headlong into something, thinking you know what you’re doing until you’re neck deep in dry, sticky spaghetti with no sauce. One of my favorite professors, Dr. Hall from Portland State University, said “fast is slow and slow is fast,” which says all of this succinctly. Attack whatever you’re trying to solve by first writing down what the problem is. It might be huge. It could be something like “create a fun 2D platforming adventure game using [insert game engine here]” or something small such as “write an algorithm that picks a color based on an input.” Instead of just jumping in and writing some code immediately after defining it, break it up into smaller and smaller pieces. Break it up until you can’t break it up anymore. Then run through things. Look it over once or twice. Once you’re certain that it’s the right direction then start writing some code.
Almost everything after that initial phase goes into the realm of project management. There are a million and one ways to track progress of a project (of which I’m not going to get into), the priority of the pieces of the problem that you’re working, and so on. Mostly it’s just a matter of really understanding what it is you’re trying to accomplish. Things change a lot, however. That’s what the point of all of this agile software development is: quickly adjusting to change in problem and scope. That doesn’t mean that really examining the problem is thrown out the window. It just means that there are smaller, bite-sized chunks of problem that need to be examined.
That isn’t to say that there aren’t situations where there is no time to plan much, if at all. If it’s a small problem, you absolutely need to get it out of your way, and if any solution is good enough, then by all means shoot from the hip. Sometimes that’s the appropriate thing to do. I’m not trying to say that you need to fill an entire planner about how to sharpen a pencil. Sometimes you don’t even know how to solve a problem, and the only way to get an idea is to try to take on a simple case of whatever the problem is. That’s what the point of things like prototypes are: asking yourself “is this even possible?” But there are times when the task gets a little larger in scope and the lines are blurred between “hammerable” and “not-hammerable.”
When problems occur while writing software it’s tempting to opt for the hammerable approach since it seems easier from the get-go. It’s the first thing that comes to mind. Just grab that hammer and get on swinging. It worked for John Henry, sort of. The metaphor stands, though, because just as swinging that hammer killed John Henry, swinging your fingers against the keyboard can cause burnout and panic. I’ve been there. I’ve done that to myself. I think pretty much everyone has at one point or another.
When you recognize that panic, realize that that’s the key moment. That’s where you stop. Just stop. Take a look at things as they are and ask yourself a bunch of questions. What is being worked on? Why are you working on it? What does it solve? Can it be broken up? What’s the priority? Instead of trying to create a path through a forest by swinging your axe willy-nilly at every tree you see, set it down for a moment. Go for a hike. Go walk to the top of that hill and look down at all the beautiful greenery. Take it in. Where did the path start, where are you at, and where did you want to go? Even if you know, sometimes it’s good to take a break and look things over. Even if it does seem like common sense, most of us might need a reminder every now and again. I know I do.