Tips for new programmers

Communication [edit]

Listen to end users. They're the reason for writing the software. Even when they ask for something questionable, be sure to listen to their needs. They often won't express their requirements clearly, so be patient and ask questions that will lead to concrete explanations.
Listen to other smart developers. Find the smartest experienced person in your new team, or other similar teams, and pick up tips and feedback. Much can easily be learned from other smart people's experiences. Ask questions, but don't be annoying.
Be honest with time estimates. More often than not you'll be incorrectly underestimating your time.

Find a comfortable working environment. Quality programming requires focus and attention to detail.
Take regular breaks. Sitting and typing in one position for long periods can lead to health issues. Breaks also clear the mind and help bring back focus. A free software solution that may help in this area is known as Workrave.

Study general best practices and coding standards. Consider your code's readability by indenting code consistently, writing comments, naming variables and functions well, etc.
Think about code long term. Code is rarely used just once and never looked at again. Write it so it should last and be relatively easy to pick up years later or for someone else to take over.
Use a text editor or IDE that you're comfortable with. A good editor will help a programmer adhere to coding standards.
Don't get boxed into one line of thinking. Becoming religiously attached to one particular language or paradigm, for example, will eventually bring stagnation. Learn the best traits of a variety of programming languages and systems. It'll make you a better all-around programmer. Object oriented programming isn't the solution to every problem.
Don't become too personally attached to code you've written. A good programmer knows when it's time to refactor or completely rewrite something they've already written, with the intent of making something function much better.
Don't over-engineer a problem. If it becomes more complicated than necessary it's also harder to maintain.
Don't under-engineer a problem. Short-term thinking leads to quickly written code, often hard to extend or fix later.

Fix the true source of bugs when possible, rather than working around a problem. This can help other applications that will share that problem code and prevent others from stumbling across the same bug. For example, if you use your own framework and find a bug, fix the bug within the framework when possible, rather than coding around the problem in each application that relies on that framework. As another example, if a bug is found in an open source software package you're using, try to fix the bug and send a patch to the project's developers if time permits. Not only will you fix a problem for yourself, you'll help others and contribute back to the community which provided you with useful software.
Take ownership of the bugs you create and work to fix them. Blaming others creates useless conflict. Taking care of your own bugs fosters trust of your work within a team.