In the past I believe I have stated something like this:
There is nothing I love more than when someone says "You do it this way" then gets up and walks away.
This statement rides right along side of the nefarious RTFM This is somewhat true of learning how to program. Many people will simply say do this, that and the other
The goal of this series of articles will be quite simple: To provide information about the most popularly accepted method(s) of learning how to program, links to primers, general information and other suggestions.
What this series will not do is instantly turn you into a programmer in "21 Days" - or whatever. Learning how to program takes a lifetime because programmers never stop learning. Whether it be new languages, styles or techniques - the process goes on forever.
By no means do I intend on writing a set of primers, tutorials (there are plenty of these already) or cast my own distorted views, instead the Road Map will approach programming from a high level perspective. It will introduce what many believe are the best ways to get started and where to go from there. The series will also look at attending classes, purchasing books and other ways to become a proficient programmer.
The beginning of the series will be a forecast of what is to come and some general philosophy ideas, after that we will look at editors and ways to "Prime up to Programming". Next will come some suggested starter languages, middle languages and finally a sort of "pick you own way" after that. Each article will come with links to online primers and supporting text. The end of the series will be a "where to go from here" sort of thing.
It is important to note here that it takes all kinds, which is why this Road Map will be somewhat vague or even appear to be indecisive, it is a guide, not a rule book. Many people want to program in different ways for different reasons. For instance, take the differences between people who may spend a lot of time working on GUIs versus Network Programmers. Many programmers have a particular area they like (this seems especially true in Free and Open Source Software Arenas) to work in, the Road Map will attempt to illustrate these differences instead of saying "Learn this and you will forever be employed."
This series will not be designed so easily to where you could go learn every primer, read every paper and perhaps do everything mentioned in one article and go to the next. Instead it is a series of articles on progression. The best way to use the series would be to do as much as you can, move at your leisure and refer back to areas you may wish to reread.
I am not one for duplication, however, I will restate some very popular beliefs about UNIX Programming that have been around since before UNIX was around. I would give due credit to Dennis, Ritchie and Kernigan (in addition to the scores of scientists before them) plus Eric Raymond for bringing their ideas together in many of his texts and of course RMS with his brilliant coding contributions. Following is a short list (not all of them) of some of these ideals:
These ideals (and more) are expressed much better in ESR's The Art of UNIX Programming; Chapter 1; Philsophy Matters (a work in progress). I highly recommend reading it.
Just about every really good programmer will tell you (and I was told the same thing) you should learn a variety of different types of languages. There is a reason for this beyond the obvious job security (although it helps). Different programming languages, literally, require different ways of thinking. I have assembled a short list of language categories, by no means is it authoritative as much as it is descriptive of the types:
An important note here is that different problems do in fact require different languages. What may seem like a practical solution in one language may be extremely difficult or even prohibitive in another. For instance, let's say we are using an interpreted language which cannot produce binaries you can keep on your local system. You have solved a simple problem with this language, however, the code is only a couple of lines. Additionally, your interpreter is 12MB in size. So when these couple of lines are sent, all 12MB of the interpreter are loaded into memory. Perhaps it would be better to write the program in a language that produces a small binary, hence saving some overhead. or even using a different interpreter that is smaller. This is the essence of the right tool for the right job. Many large projects use a variety of languages to piece together one large functional product.
Another important ideal is that one does not have to become proficient in every type of language out there, I do believe that would be quite difficult. Instead, learn a variety of types to the degree where you can do something with them (even if it is trivial) so you gain an appreciation for the design, and even perhaps see a way to attack a problem with a language that you already are proficient in, again, brain exercising and perspective.
Many of these ideals and more are expressed better in How To Become A Hacker.
For the very brave I recommend taking a spin by Dennis Ritchies The Development of the C Language about how and why C evolved the way it did; another text by ESR titled A Brief History of Hackerdom. This text may seem somewhat off topic but does a great job of relating some of the ideals discussed in this article.