25 Things every Programmer should know

If it's not tested, it doesn't work.
Source control is your friend - make sure you use it.
Just because you wrote it doesn't mean you own it — don't be offended if someone else on your team has to change your code.
Don't reinvent the wheel, library code is there to help.
The fastest code is code that's never executed — look for early outs.
Just because you didn't write it doesn't mean it's crap.
Source code is just a hint to the compiler about what you want to do, it won't necessarily do it (e.g. You might declare a function as inline but the compiler doesn't have to obey).
Code that's hard to understand is hard to maintain.
Code that's hard to maintain is next to useless.
“Whilst I'm editing this file I’ll just…” is a great way to introduce feature creep and bugs.
The neater your code layout, the easier it is to read. The easier it is to read, the easier it is to understand and maintain.
Code is not self documenting. Help others by adding comments to guide them. You may understand it now but what about in 5 years time?
Bad Code can and will come back to haunt you.
There is no such thing as a 5 minute job. It'll always take at least half a day.
Magic numbers are bad.
Constants don't take up storage, they're compile time text substitutions.
Project management will always want you to do twice as much in half the time.
If there is a bug, the user will find it.
A code review is not a criticism.
It's not the quantity of code that matters, it's the quality. Any idiot can bang out 40kloc but that doesn't make it fit for purpose.
The true cost of poorly written code is in the maintenance.
Eat your own dog food — fixing bugs in your own code helps you code better and improves your understanding.
Code rots over time.
If the user didn't ask for a feature, don't add it.
If it's not tested, it doesn't work (yes, I know I've included that twice but it's really important).