how to be a better programmer (from whirlpool)

Looking back at the developers I have worked with over the years, and trying to work out what made them good (or bad) developers, my advice would be along the following lines (in no particular order):

Become proficient in using the debugger. Some people say that if you are a good coder you will never have to use a debugger... nonsense! You will inevitably be asked to track down problems in your own (or other people's) code. Learn how to set and use conditional breakpoints.

Be comfortable with threading, and learn how (and when) to synchronize access to data between threads.

Read other developers' code/join an open source project. Reading and maintaining someone else's code is an excellent way of seeing how different developers approach different problems.
Learn how to use version control (along with branching and merging). Understand why you should use version control.

Admitting you do not understand something is NOT a sin. Don't try to bluff and pretend that you know about Topic X to someone who actually does know... they will see through it for sure and, from that point on, most of what you say will be taken with a grain of salt.

Have a rudimentary knowledge of one layer of technology below the one you are working on (eg. java - know a bit about the JVM and bytecodes; C/C++ - know a bit of assembly, etc.)
Read slashdot/whirlpool/etc - and no, I am not joking! :-) You will invariably find articles/comments that are very interesting (both personally and professionally). They may be research papers on the latest JVM garbage collection techniques; it might just be a comment that explains how to uninstall a difficult device driver; or it might be an advisory about the latest security vulnerability in a product that you use. It is all just accumulated knowledge that you can store for a rainy day when you get bitten by the very same problem.

Feel free to specialise in a particular language/platform, but don't be a bigot. Every language/platform has its positives and negatives - read articles that describe the differences. It is extremely unlikely that you will be using the same language for your whole career... having an understanding of the strengths and weaknesses of each will only help you in your career development.

With regard to learning new languages, pick a (small-ish) project that you can build in your spare time and develop it using your new language. There is no substitute (in my opinion) for doing actual development in your new language. It doesn't really matter if you never finish it... it is the process of learning the new way of thinking that matters (I have dozens of half-finished projects where I tried a new language/library/framework/etc... ­ he he he!) Join the forums for that language and ask questions.

Don't take shortcuts when coding. Think about error handling. Before you write a comment saying "This should never happen", ask yourself if maybe, just maybe, could it happen?
If you find yourself spending hours/days trying to solve a tough problem, talk with another developer about it. The very act of having to distill it down so you can describe the problem to someone else will often result in you finding the solution. Even if it doesn't, they will probably have some suggestions of their own.
Don't write like a l33t h4X0R. Well, maybe t

hat is just a pet peeve of mine :-), however I still think it is worth mentioning. Good grammar and spelling are not something to be embarrassed about.