The first and most important thing to learn is ethics. Most textbooks leave this until a late section, which often makes tempting situations before revealing the seriousness of having decent ethics. As a programmer, you will take on both the fames and burdens of other programmers. Just like joining a religion, if you do bad things, you make everyone else look bad. However, unlike a religion, there are only a few simple guidelines to follow (though, many would love to make more). These are mostly rules accepted by programmers to insure that only good things happen (much like the ethics followed in a scientific community), but unfortunately, not everyone follows the rules (like people in the scientific community with an agenda).

First and foremost, you can indeed impress someone by making a supervirus that can make the computer act strangely, but releasing it on the world and annoying those less informed will win you no attention (unless you get arrested) and will surely ruin the view people have of programmers. I, for one, have lots of bad experiences where people end up with a computer problem, then they blame me because I'm the only person they know personally who knows how to make computer programs. They simply assume that I must be the cause.

This leads me to the second rule, you can't be lazy. Lazy people make buggy programs which tend to fall apart. I'm sure you would never use microsoft word if it were to receive a fatal error every 2 or 3 pages of typing and you couldn't recover your documents. You need to make things that are reasonably "robust." "Robust" is often a keyword used by many programmers and employers who wish to describe the quality of someone's code ("code" is what programmers write which turns into a usable computer program). If it's robust, it's never bad unless you're trying to show an example of a bad program or security system. Conversely, as part of this rule, sometimes robustness needs (or can reasonably be) sacrificed for speed, which is often important, because you don't want to wait 10 minutes for the computer to add two numbers together simply because you felt that the program should continually check to make sure the user typed a number. If robustness is sacrificed (usually only best when coding for another programmer), it's expected that you tell the person using your code what all could go wrong and what would cause that to go wrong.

Now, like before, the third rule was led into by the last statement. You must communicate with people about using your code, and let them know of the dangers of your code. This is called "documentation." This term is used alot, and not just inside programmer circles. Nothing except a slow and buggy program angers people more than a program that they paid for but don't know how to use. It's bad to underdocument, but don't overdocument either because then people will be too bored with it to figure out how to use it. Ever had to figure out how to use a fancy coffee pot or your first cellphone? Surely you thought it was easy, you ended up making a mess of things, then you looked in the trash for the instruction booklet. Sometimes, if the code is small enough, and it's only for programmers, keeping it "readable" is sufficient documentation. In the next lesson, you'll be introduced to some code, and something called a "comment" will prove useful for documenting code that is difficult to read. This rule is also very useful to you, because you may easily forget what something in you code was intended to do.

These rules essentially fall under only section 1.2 of the ACM's "Code of Ethics." I recommend everyone get to understand the responsibility that comes with programming, looking up many codes of ethics and so forth to get a real feel for what's expected of you. My most recommended reading is the following url, which is often copied into many, many textbooks for programmers:

http://www.acm.org/about/code-of-ethics
