I thought it would be good to write down a list of things you can do to improve your programming and job prospects when you have learned what you need to. To get the ball rolling:

a. learn the syntax of the language(and a Framework if there is one. E.g. .NET)
b. improve your coding by practising lots- the more you do the more you will reduce the number of errors you make. Having written lots of code you will remember what works and what does not
c. improve your problem solving-you will often have to work on this before writing your program
d. create a portfolio of programs which you can present to potential employers-perhaps upload them to a website
e. Put yourself in the shoes of the person using your program-what would you like to see, how would you like to use the program? This will help you (as a programmer) make the program easier to use.
f. Take some exams :-)

Suggestions, additions and comments are most welcome.

Be willing to share what you have learned when asked by others. Some people think that by hoarding knowledge they make themselves more valuable. An employee who is willing to raise the skills of his fellow employees is the valuable one.

Comment your code meaningfully - the "why" not the "what"

Not:
/* Initilize variables */
int a = 10;

But:
/* Business requirement: Sum the outstanding balances for each customer */
some type of looping, querying, etc. to perform that function

Pretend YOU are going to have to support this program in 12 months - after you've totally forgotten you ever wrote it - and put what you'd like to see in the code when that time comes. Because it will!

Be open and receptive to other's ideas and approaches. If they have been around the block before, "use their map". Smart people learn from their mistakes - smarter people learn from other people's mistakes. (Of course be sure the person you're listening to is actually good!)

And furthermore...

Don't overbuild.

Build in test points (log files) so you can see what is happening in your program (I wrote many dozens of real-time scripts that had to run continuously. You want to be able to find out what the processes are doing without stopping them, or see what they were doing before they failed.

If you are writing programs such as those above, decouple the processes so that a failure of one does not cascade.

Occam's razor applies. The simplest solution (not the sexiest one) that satisfies the specs is the desirable one.

1. Learn Ruby or Python. Learn Perl 5.
2. Learn Scheme.
3. Learn Haskell.
4. Presumably you already know C++ or Java. Learn the other one. Then learn Scala.
5. To practice writing networking code, read the HTTP spec and make an HTTP proxy.
6. Never write cryptography code.
7. NEVER write cryptography code.
8. Write a toy scheme interpreter.

This article has been dead for over six months. Start a new discussion instead.