There’s a problem-solving method that I taught my students when I was teaching – a method I strongly believe in. I stole it from my 11^th grade programming teacher and it’s been useful for me ever since. It’s called it “Algorithm-based Problem Solving.”

Programmers are familiar with algorithms, but for the rest of us: algorithms are the steps that a computer programmer must take solve a programming problem. Since computer programs must be laid out in exact steps so the computer knows what to do, writing algorithms is essential to planning a program.

It’s easiest to design algorithms in a tree structure, breaking down a major problem into smaller problems and those smaller problems into even smaller problems, and so on, down to the very last turtle holding up the program (even though it might be turtles all the way down).

For instance, if I were a programmer designing a Word Processor, I’d start with a big problem – Design a Word Processor. Boom. That’s the whole problem. Next, I’d list the sub problems underneath that problem.

For instance, my Word Processor needs a way to handle text input from the keyboard, it needs have a user interface with a menu system, and it needs a way to save documents. From there I can break down each of those problems into smaller problems. To save documents, my Word Processer needs to access the hard drive and know multiple saving formats. To save in multiple formats my Word Processor needs to know how to save in each format and each format needs access to specific API’s, etc, all the way down. You get the idea.

If done properly, before a programmer sits down to start actually writing anything, she already knows the thousands of smaller problems she needs to solve to build the program into the whole thing. Although it might seem counter-intuitive, solving a thousand smaller problems is much easier than solving one big one, because each of those smaller problems is just a tiny step – the tiniest possible if she’s done her work correctly.

So that’s how computer programmers use algorithms, but this method can be used to solve almost any task. When I talked my students through a research paper I we would always start by listing all the problems we could think of on the board as they yelled them out. These problems included:

How to stay awake to write the paper

How to come up with a research topic

How to research in the library and online

How to make the paper convey the information it needed to convey

How to write a “Works Cited” page

How to use transitions between paragraphs

Etc.

Once we’d listed all the major things they needed to know, we’d consider ways to solve those problems. They needed to know how to write a “Works Cited” page, so we’d spend 20 minutes covering that. They needed to stay up late writing their papers, so we talked about where on campus sold coffee late at night (bear in mind, I tried to stress that not writing it the night before on a caffeine high was better, but we tried to be as realistic as possible about what problems they would encounter), and so on. Once we were done, the students had an algorithm for writing the research paper. All they had to do was solve little problems one by one and the paper would be the output.

For the most part, my students enjoyed the method – they had fun coming up with problems to solve, brainstorming solutions to those problems, and found it easier to tackle overwhelming tasks. But this problem solving method isn’t just for computer programmers and freshman composition students – it’s useful for almost every problem. For instance, since I’m writing some tutorials for Adobe software right now, I want to talk about how I used this method to learn software.

The most important thing that this method needs is a learning goal, or a problem – you can use those things as synonyms for each other. I believe that learning things without a goal in mind is useless – you won’t be personally invested in the information you’re learning and there’s no goal to keep doing it. So let’s start with something the self-publishing community has to do all the time – designing a book cover for your self-published e- book.

First we have think about what a good book cover does. Don’t just parrot back what other people say about this – the most important part of this problem solving method is clearly identifying the sub problems. So what does a good book cover do? What’s the overarching, most important problem your book cover must solve?

Problem:  a book cover entices the reader into buying the book

I thought about it for awhile, and in the most general sense, this is why a book cover exists. If I’m wrong, please drop a comment after this post to call me out. But assuming that enticing a reader into buying the book is the cover’s job, what sub problems does that idea contain?

Sub Problem: The book cover must convey what the “spirit” of the book is about

Sub Problem: The book cover must be easy to read in all sizes, including full size and thumbnail

Sub Problem: The book cover must be visually interesting

Those are our sub problems, as far as I can tell. We’re still operating at a pretty high, vague, level here, but we’re getting closer to problems we know how to tackle. So let’s keep breaking this down.

Problem: The book cover must be easy to read in all sizes, including full size and thumbnail

Sub Problem: Need to use software that makes it easy to test multiple fonts quickly

Sub Problem: Need to select a font that you have legal rights to use

Sub Problem: Need to know how to pick ascetically pleasing fonts

So now we’ve broken down further and are rapidly approaching problems we know how to solve. These problems are all, for the most part, research questions. And we have resources to research these things– google searches and asking people on twitter. To be fair, you can also break these problems down further – into how to research, etc. The trick is to break down the problems into the smallest size you feel comfortable tackling in just a few minutes.

The same thing applies to learning the software that you’re going to need to make your book cover. As long as you have goals, learning the information you need isn’t difficult. If you know you want a drop shadow under your text, you can easily research how to make a drop shadow using the program you’re picked. If you know you want your cover to have a blood-red see-through rectangle over half your cover, you can learn how to do that by researching transparencies and rectangles. Good googling habits can solve these problems – you can search for transparencies or opacities, or even “see though” – there’s a good chance that with some effort you’ll find out what you want to know.

You might not know the language and menu items your program uses at first – most of the time a program’s users will know what they want to do, they just don’t know how to do it. Every program labels things differently – what one program might call “text flow” another might call “story editor” or “stringed text.” Finding out what the designers of the program labeled the feature you want to use is the first step to learning how to use it.

But more than anything, you have to know what you need to know. And that means having a goal in mind before you start and the willingness to break down the problem into sub problems until you have it busted into smaller pieces you can lick.