Programmers must have knowledge in a variety of subjects:
- Formal logic
- Specialized algorithms
- Application domains
A good programmer should
- 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 and request help, but don't be annoying. Many answers can be found in documentation and through online searches. When those aren't sufficient, don't struggle and produce bad or incomplete results, but instead ask for help.
- Be honest with time estimates. More often than not you'll be incorrectly underestimating your time. It's far better to give a large time estimate and complete the work early than to offer an unrealistic time estimate and not meet it. Every developer is pressured to give short time estimates and get work done quicker. Be persistent in only giving realistic time requirements.
The environment a programmer works in is important on a personal level as well as affecting the quality of code produced. A programmer should
- Find a comfortable physical 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.
- Work within an organization that promotes teamwork, listens to constructive criticisms and feedback, and allows for individual growth. Programming is a highly skilled endeavor and should be treated as such. Within the right organization a programmer will be set up for success and skills will naturally improve over time.
To write good code, a programmer must
- 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.
Every programmer produces bugs. Programmers should
- 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.
 "Real" Programmers
The term real programmer is a sometimes used to denote what many would consider a "hardcore" programmer. "Real" programmers don't use graphical tools such as IDEs or anything other than low-level programming languages. One famous piece of hacker folklore is the "Story of Mel," a "real" programmer who wrote directly in machine code.
 Recommended Reading List & References
A recommended reading list of non-programming books for programmers includes
- Hofstadter, Douglas. Gödel, Escher, Bach: An Eternal Golden Braid. ISBN 978-0465026562.
- Levy. Hackers: Heroes of the Computer Revolution. ISBN 978-1449388393.
- Kidder, Tracy. Soul of a New Machine. ISBN 0713914823.
- Dyson, George. Turing's Cathedral: The Origins of the Digital Universe. ISBN 978-1400075997.
- Stoll. The Cuckoo's Egg. ISBN 0743411463.
- Ensmenger. The Computer Boys Take Over. ISBN 978-0262050937.
- Norman, Donald. The Design of Everyday Things. ISBN 978-0465067107.
- Brooks. The Mythical Man-Month. ISBN 978-0201835953.
- Hafner, Katie. Where The Wizards Stay Up Late: The Origins Of The Internet. ISBN 978-0684832678.