The code must be properly formatted, nice to read. You must have testcases.
- Always start with simple even dumb code. (e.g. as is written in the spec you write it down no matter how stupid or inefficient)
- Trade simplicity/clarity for speed, if the gain is big. (e.g. move from the letter-of-the-spec-matching code to something actually faster, sometimes also clarity and simplicity gain from it)
- Trade space for speed, if the gain is big enough. (e.g. a lookup table usually is a nice solution, sometimes for a different problem)
- Trade precision for speed if you must, always leave a codepath that isn’t imprecise.
- Never trade portability, but you might trade slower generic code for faster specialized code for all the platform implementing it. (e.g. implement in asm a function that was inlined before, the plain C code would be slower since you have a call overhead while the asm-optimized version would be 16-fold faster than C)
As Kostya pointed, sometimes you start with a binary specification so point 1 is moot.