Tweeker gives some excellent insight and advice here. Some other things I like to emphasize to those first starting out is.
1) Don't just start out writing code first. Write out your sequence. Draw charts and diagrams of how it should work.
2) Whatever "style" you choose, try to keep it consistent throughout the entire program.
3) The part of the program for correct operation of the machine is the easy part. The hard part is what happens when things don't happen correctly. Faults/Alarms, recoveries, diagnostics, etc. These are what sets apart a good program from a bad one. At every step (and I mean every step) in your program you need to evaluate what should happen if something doesn't happen "as expected".
4) Try to break everything up into well defined subroutines that have a clear objective. Try and keep these subroutines as isolated as possible.
5) You didn't mention what software you will likely use. Try to develop a consistent naming convention whether it be tags or symbols. Get in the habit of commenting your code. I will often write the comments in prior to even writing the code based on my sequence lists or flow charts.
6) Have "modes" in mind prior to coding. Give thought to how you will switch things over from Auto to Manual. This can get tricky and messy if you don't work it out well. I always keep one single subroutine for all my physcial (and fieldbus)
outputs. This is a good place to put break up your modes. Consider using a whole separate set of bits for Manual than you have for Auto operation.
Like Tweeker mentions, as you progress you will get a better feel for what techniques work better in what situations. You will develope a "toolbox" so to speak of methods. This is all a result of experience, keeping an open mind, developing a deep understanding of what is happening inside the controller, and studying other peoples code to pick new tricks.
You will find traing on how to use the IDE, and the basics of very rudimentary applications, but the reset will have to come from you.
