» Don't do your own timestamp calculations

If you have ever done something like time() + (60 * 60 * 24 * 7) to get the time at this minute next week then you are guilty of doing your own timestamp calculations. There hundreds of thousands of lines of code that are written line this and they will all produce improper results when the next week involves a timezone change. Such is the case with daylight savings time. There are plenty of well written date and time libraries out there that know how to properly handle timezone changes and other quirks. In PHP 5.2 they have enabled the DateTime class by default which allows you to do something like:

modify('+1 week');
echo $time->format('r');
?>

If you are running on an older version of PHP then running mktime(date('H'), date('i'), date('s'), date('n'), date('j') + 7, date('Y')) produces the same results but isn't as readable. When you write your own calculations without regard for obstacles such as DST and leap year then ultimately your code is going to end up an hour or a day off somewhere and producing irrational results. This is why languages such as PHP and Java offer time manipulation classes that can hide all the mind numbing exceptions that apply to time.

» EXPLAIN your queries

EXPLAIN is a command offered in the MySQL and PostgreSQL database servers that will outline how the server plans to go about executing the query. This includes listing what indexes it will use and an estimation of how many rows will be returned or affected by each part of the query. Often times if you notice a query that takes longer then you believe it should, or it shows up in the slow queries log, running it through EXPLAIN will show it pulling a lot more rows then you expected. The rows returned by EXPLAIN may not be the final number of rows returned by the query but are rows that will have to be touched in the process.

Recently I saw a query that was execute on every page load of a website taking 10 seconds to run. This query was JOINing two tables that each had tens of thousands of rows. Normally this wouldn't be a huge problem except the JOIN was done without specifying an intersection. Each time it was ran it had to SELECT all the rows in second table because it was not narrowed by a WHERE clause. Sure enough when I ran the query through EXPLAIN it listed over 10,000 rows returned from the second table. Now this was simple enough to fix I just provided it an intersection in the WHERE clause and it dropped down to under 40 rows searched in the second table.