Here's some pointers transferred/adapted from my driving teacher, my programming teachers and... recommendations on taking <ugh!> Microsoft tests:

1. Know what you're doing. You should know quite clearly what you want this program for and what it should do. Otherwise, you shouldn't be writing this program...

2. Write the program logic down (use plain <your language here>, pseudocode, block diagrams etc., but on paper. Not everyone can do it nowadays, but if you can, it will help you...

3. If you can, write the code down (again, on paper). You can always scan and OCR it later... Often, you will see a design flaw or something that needs redoing, and often it is very hard to find it in code when it's on computer (or maybe, it's just me coming from that old generation of people who actually read paper-based books)

4. Code (on a computer). Include enough comments so that you won't get lost looking at this program three years later. If you feel like a technical writer and don't care about your job security, make extensive documentation...

5. Test. If everything goes well on the first try, re-check the program - something is definitely wrong ;) (remember Murfy's laws?)

6. Put into production. Don't forget to keep the source in case the company will want to fire you later and you will have to use threats and blackmail to get your severance package out of them...