Learning How to Program: A Guide. Part VI

Problem Solving

(Be sure to check out part 1, part 2, part 3, part 4, and part 5 of this series if you haven't already).

The next step in learning to be a programmer is learning to solve problems with programs. This step is absolutely critical, and is really the foundation of what a good programmer does, but it's sadly under-taught. Before you tackle this step, though, make sure you are finished with the first step, which is learning the basic syntax of whatever language you have chosen.

In the previous step, you are really learning how to read a program. To test your abilities in this area, examine programs that use just those parts of the language that you learned about, and make sure you can follow them without reading any accompanying descriptions. In other words, try to execute the programs manually, using pencil and scratch paper if necessary. It's okay if you sometimes have to check your reference on a particular point of syntax or semantics -- maybe you haven't memorized everything yet, but the point is that you should be able to read through a program and comprehend it without too much difficulty. Once you have reached this stage, when you can declare with confidence that you know how to read basic programs in your chosen language, you are ready to learn how to actually write them.

But wait, I hear some of you saying, wasn't I writing programs in the previous step? That's what you told me to do, and that's what I did! In the previous stage, though, you're really just modifying existing programs, expanding or altering them slightly. The goal is to be able to write programs from scratch. I like to compare this to cooking. I am not a good cook, but that's not to say that I haven't sometimes put tasty food on the table. I can do this because I can follow a recipe -- if it's not too tricky -- and I can make small modifications to the recipe if the grocery store was missing a particular ingredient, or I need to make food less spicy for my daughter, or something like that. In contrast to my meager abilities, I had an uncle who was a great cook. Uncle Jim was the sort of guy who could just poke around in your refrigerator and pantry and whip something up that would meet your tastes.

Ultimately, that's what you need to be able to do as a programmer. Someone tells you what the program should do -- the specifications or requirements -- and then it's up to you to figure out how to write a program to do that. That's problem solving.

I just wrote a whole book on the subject. It uses C++ for the example code, so if you know basic C++, or are willing to learn (if you are already learning a similar language like Java, it won't be hard at all), that's where I would recommend you head next. The book's not expensive, but if you want to go ahead and get started, let me give you some ideas.

Do you remember previously how I talked about learning a language step-by-step, so that with each program you write during this learning phase, you are only wrestling with one new idea? One of the best techniques for solving a complicated problem is to divide or reduce the problem in some way so that you are only dealing with one issue at a time. If you aren't sure how to write a program that meets all the given specifications, just change the specifications. This is only temporary, of course, and eventually you'll have to solve the problem as written, in the meantime you can make progress, build a foundation for solving the entire problem, and possibly discover more about the problem and its ultimate solution.

The most important thing about this phase, the problem-solving phase of your development as a programmer, is that it cannot be skipped. Students can gain a lot of confidence with program modification, messing-around, experimentation, whatever you want to call it, and while it's an important first step, no amount of that can make you a programmer. I see a lot of fledgling programmers who are in such a hurry to get to the "good stuff," more advanced programming with impressive output, that they press forward without realizing that they've passed over trying to master the crucial skill that determines whether or not they're really going to enjoy programming. They learn a lot about programming without ever really doing any. Don't be this person!

Share this