Tips for new programmers

From DocForge

[edit] Communication

• 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.
• 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.

[edit] Environment

• 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.

[edit] Code

• Study general best practices and coding standards. Indent code consistently, write comments, name variables and functions well, etc.
• Use a text editor or IDE that you're comfortable with. A good editor will help a programmer adhere to coding standards.
• 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.
• Don't get boxed into one line of thinking. Becoming religiously attached to one particular language, 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.
• 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.

[edit] Bugs

• 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.

[edit] See Also

• Coding standards