Important programming truths

quoted from http://liw.fi/programming-truths/

Originally written in 1995.
This page contains a number of important programming truths that every budding programmer should know about. These truths are self-evident, and need no explanations.

If it compiles, it works.
If it compiles, it’s correct.
If it runs, it doesn’t have any bugs.
If it doesn’t have any immediately obvious bugs, it’s perfect.
If a bug doesn’t show, it doesn’t exist.
If it seems to work, it works.
Doing something right is easy. Avoiding errors only takes a bit of concentration.
The shorter the source code, the faster the program.
It’s obvious how to optimize a program.
Prorammers don’t make mistakes.

Run-time errors don’t occur.
Users don’t make mistakes.
I don’t make mistakes.
Errors of any kind are rare.
Error handling can be done in version 2.
It’s OK to crash on bad input.
It’s OK to give incorrect output on bad input.
Portability isn’t useful.
All the world’s a VAX. Or, these days, an MS-DOS box
The length of the feature list is important.
Speed is good, features are better.
Slowness can be fixed in hardware.
The bigger a program is, the better it is.
Random changes to a program fix bugs.
Testing takes only a short while.
Finding bugs is easy. Fixing bugs is trivial.
Bug-fixes don’t need to be tested.
Trivial changes of any kind don’t need to be tested.
The first approach, idea, or version is always the best.
A 1% crash rate is actually pretty darn good.
Code is self-evident. Comments aren’t needed.
Comments are meant for people other than the original author of the code.
Undocumented features are fun and useful.
It can always be fixed in the next version.
Surprised users are happy users.
Demonstrating for clients is the best debugging method.