The New(bie) Programmer's Road Map: Introduction and Overview

May 2000

The New Programmer's Road Map: Introduction and Overview

A Brief Introduction

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.

How the Road Map Will Be Structured

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."

How to Get the Most from this Series

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.

UNIX Programming Ideals

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:

Small: always try to keep it small
Clean: clean code makes for scalability
Connectivity: by this I do not mean networking, instead I refer to connecting pieces of software together.
Re-usability: One of the most important features of good UNIX programming - never do the same thing twice.
Proficient Efficiency: writing efficient code that is understandable. A difficult endeavor.

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.

General Programming Ideals

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:

Machine Level: Extremely low level code that interacts directly with or "one step above" the hardware.
Precompiled: A file (or set of files) is fed to a compiler and executable (object) code results.
Interpreted: A file with syntax is fed to an interpreter which reads the code and executes (in some cases the code is compiled into executable code and then executed).
Scripting: Scripting can often be done as the Interpreted type (stored in a file then sent to the interpreter) or the interpreter can be started interactively and code can be written on the fly.
Highly Objective: Yes I made that up. This might be languages that are built around being object oriented.
Other: Here languages such as Virtual Machine types, LISt Processing and perhaps low level database programming lie. In other words, anything I have yet to classify or was too lazy to think about.

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.

systhread.net