Originally published on Developer.com, October 23, 2002.
When I first started deciding what I wanted to do with my life and started training in the field of software development, I felt the most difficult task would be to learn all the different languages. I took courses in FORTRAN, Pascal, COBOL, C, and a few other languages that I don’t even remember the names of today. In today’s environment, it may not be learning languages. It might be learning APIs and frameworks.
It wasn’t until I’d had two or three years’ experience that I realized that software development wasn’t about the syntax of the languages. I realized it was about learning new ways to solve problems in the languages and tools. If you’re a developer with a few years’ experience, you might think that the preceding is obvious, but it’s a trap that is all too easy to fall into.
In this article, you’ll learn how to teach yourself—and your peers—how to become better at what you do by changing what you and they learn and how to change your approach to learning.
Recall, Not Problem Solving
Our educational system has been developed over the years to encourage the recall (or memorization, if you prefer) of facts. We’ve learned all the tricks. We all know that in 1492 Columbus sailed the ocean blue. Hardly anyone who grew up in America can forget that the constitution starts with “We the people” or that the Gettysburg address starts with “Four score and seven years ago.”
However, there are some classic areas where students have problems. The problems occur when we’re not asked to memorize facts but instead are asked to determine which solution that we already know should be used to solve the problem.
One example of this is math story problems. Most students are very challenged by story problems. Generally, this isn’t because they can’t read or they don’t know the basic math facts involved with the problem. The problem is in deciding which math facts to use. The fact that you’re reading about a train leaving LA and one leaving New York doesn’t help you to understand whether you’re doing a division problem, a subtraction problem, or some other sort of problem. Math story problems are so difficult for some people that comedians have started making jokes out of them.
Another area that students generally have trouble with is their first chemistry class. In high schools all over the US, students who’ve managed straight As have been cut down by a class that asks them to apply what they’ve learned to solve problems rather than just memorizing a set of formulas.
The challenge in business is that most problems are story problems. Most problems require that you identify the pieces that you’ll need to put together to come up with a solution. These are not recall problems and they can’t be solved by better recall of the pieces that you know. They can only be solved by taking on a problem-solving mentality.
Problem Solving for Dummies
Problem solving is not particularly difficult, but it does take a different approach. It’s not about learning facts. It assumes that you’ve learned the basic facts and that you’re now moving on to the cognitive processes of applying that information to the problems that you confront.
The best way to learn about problem solving is to take problems and try to solve them. By using the scientific method (Observe, Hypothesis, Test, Repeat), you can dissect the problem into manageable pieces and start the process of developing problem-solving skills.
For instance, take a problem printing a document on a network where there is no output. The first step is to understand the process that takes place after you tell the program to print to when the file is printed. This is the key process in the scientific method of problem solving. You must observe or learn how the process works. Figure 1 shows what might be a basic understanding of how a file is printed across the network. Note that it doesn’t include every step, only the major components. That is sufficient to start the process of problem solving.
[image no longer available]
The next step in the process is trying to form a hypothesis about which of these pieces is broken. The hypothesis is likely to be based on your experience with the environment and what breaks most often. For instance, if you’re developing a new program and it doesn’t want to print, it may be most likely that the program is at fault and you may want to begin by testing that piece. Alternatively, there may be some environments where the server that hosts the printer may typically have problems. In those environments, it may be more appropriate to focus on testing the server first.
The next step is to test the piece that you’ve identified. In the case of the program that you’re developing, you might take another program on the same computer and see if it can print. If it can print, you know that the program is probably at fault. If you had chosen to focus on the server, you might test this by trying to print from another workstation. If you couldn’t print, you would not know for sure that it’s the server, but you could safely rule out a problem with one program or workstation.
The next step in the scientific process is to repeat the process. Because you would know, from the last example, that it’s either the server or the printer, you would still have to perform another test to see if it was the printer or the server with the problem. An easy way to test this might be to pause the printer queue on the server so it doesn’t try to send the print job on to the printer. If the print job doesn’t stay in the server print queue, you’ll know that something’s wrong on the server.
After you’ve narrowed down the problem, you can try to learn more about the area that is broken. If it’s the server, it might mean learning what service in Windows 2000 is responsible for printing (Spooler). Once you know the pieces inside the component, you can hypothesize which of those pieces failed. At some point, you’ll be left with the piece that failed, which is small enough that you can swap it out or you’ll be left with a component that you can not break down.
This process may seem trivial, but it’s a process of investigation that most people are not accustomed to. Because of that, it may be a process that you need to force yourself through: the process of looking for ways to isolate—and eventually solve—the problem.
Hunger for Learning
One of the pieces to learning of any kind is developing a desire—a hunger. While all people are capable of learning, it isn’t something that all people yearn for. It’s this quest for learning, this desire to learn, that will drive all kinds of learning. These kinds of learning that will develop both recall and problem solving.
By developing a hunger for learning in yourself and your coworkers, you can facilitate the problem-solving philosophy because the problem-solving process is, necessarily, one of learning. By developing a hunger for learning, you’ll develop a desire to do problem solving because it drives learning.
Developing the Hunger
Developing the hunger for learning is the true challenge in every organization. It’s like a spark that must be cultivated to turn into a raging fire. The spark will be found in the most unusual places and in the most unusual ways. It’s the reward for learning something new. It’s the confidence of understanding how things work instead of just that they work. If you’re cultivating learning in your organization, it’s important to seek out and reward these sparks to encourage them to reveal themselves as a fire. Rewards can be as simple as a “job well done” comment in the hall, a free lunch, or something more substantial.
If you’re cultivating the hunger in yourself, you should first learn to recognize when you’ve gone above and beyond the call of duty by learning more about something than you have to. Seek out those who will praise you for your extra effort.
Finding More Help
If your interest has been sparked, you may want to read Peter Senge’s The Fifth Discipline (ISBN 0-38526-0954). It was published for the first time in 1994. It will help you learn more about encouraging learning in your organization. Although it’s a business book, it shouldn’t be scary to even the most diehard technology person.