Learning How to Program: A Guide. Part V

Let's Do It, Already.

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

You've definitely decided to give programming a try, and you've picked out your introductory language. So now what?

You need to install whatever development tools you're going to use. You can get started with just a text editor and a command-line compiler, and you might even know someone who tells you that "real" programmers don't need all that fancy syntax highlighting and debugging and what else. Don't listen to that person. A nice editor with syntax highlighting (text is different colors depending on its meaning within the programming language) and completion (sort of like the suggestions in a Google search box, it lets you choose from options based on what you've already typed) is very helpful even in the early stages of programming to keep the syntax straight. And a debugger is useful for much more than simply finding and removing bugs in code. It's a great tool for understanding what's going on in the code line-by-line. If there is a section of code that you copied into your editor but don't fully understand how it works, there's nothing better than stepping through the code with the debugger, checking the values of the variables as they change. Get to know your debugger early and use it often.

The first program you want to write, though, is going to be the "hello world" program or something equivalent. You just want to make sure that you know how to use the compiler (or interpreter) to actually build and execute a program.

From there, follow along in whatever book or online guide you have. By "follow along" I mean never simply read -- always do. Write programs every step of the way to confirm your understanding of what you have read. Always take it one simple step at a time. By that I mean never introduce more than one "new" thing at a time in your programs. Also, experiment is much as possible at each step before moving on to the next.

Let me give you an example. Suppose you started with a "hello world" program. In C++ the line of code that did all the work would look something like this:

cout << "Hello World!\n";

In Java:

System.out.println("Hello World!");

Python:

print "Hello World!"

Regardless, once that first program works, try playing around with it to do other things. Give yourself specific goals and see if you can achieve them. Can you display "Hello" and "World" on separate lines, for example? What about displaying unusual characters? What if, for example, you wanted a double quotation mark to be displayed?

Then see what comes next in your resource and incorporate that into your tiny program. For example, what often comes next is an explanation of numerical expressions. So try modifying your program to compute and display the number of seconds in one year.

Let's say the next topic after that is variables. Try storing the number of years in a variable called years and then computing (and displaying) the number of seconds in that many years. Think of some other simple computation tasks like that and write simple programs to perform them.

If the next topic is user input, modify your previous programs to accept user input. Read years from the user instead of making it a fixed value, and so on.

One of the suggestions I make repeatedly in my book is that when you're stuck on a problem, you should break it down so that you are only working on one issue at a time. But you can use this concept in the other direction as well. By learning each part of the programming language separately, it's much easier than trying to put lots of new ideas together in one go.

Furthermore, by asking yourself questions, "how can I do X?", and then trying to answer them, you'll learn about the features of the language in a systematic way. You'll make mistakes, but they will be easier to correct because you'll know where to look for them, and you'll learn from them.

Remember, the goal at this stage is to determine whether programming is right for you, and that means whether or not you are enjoying it. When you sit down at your computer to push forward in your learning, how are you feeling? Excited? Curious? If it already feels like punching a clock, that's a bad sign. You should get a nice jolt of satisfaction when one of your programs work. It shouldn't just feel like relief.

Share this