Romero's Rules
John Romero is regarded as one of the best programmers and game designers to ever walk on planet Earth. His 10 rules for game development apply to all forms of programming as far as I can tell. I choose to keep them here as a reminder.
No Prototypes
No prototypes. Just make the game. Polish as you go. Don't depend on polish happening later. Always maintain constantly shippable code.
Fallbacks on load failure
It's incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.
Simplify
Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.
Focus on tools
Great tools help make great games. Spend as much time on tools as possible.
Don't rely on testers
We are our own best testing team and should never allow anyone else to experience bugs or see the game crash. Don't waste other's time. Test thoroughly before checking in your code.
Fix bugs immediately
As soon as you see a bug, you fix it. Do not continue on. If you don't fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.
Target less powerful systems
Use a superior development system than your target, but plan for users to have less capable hardware.
Don't write code for future projects
Write your code for this game only - not for a future game. You're going to be writing new code later because you'll be smarter.
Write modular code
Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.
Transparent coding
Try to code transparently. Tell your lead and peers exactly how you are going to solve your current task and get feedback and advice. Do not treat game programming like each coder is a black box.
Embrace differences in programmers
Programming is a creative art form based in logic. Every programmer is different and will code differently. It's the output that matters.