1. More is often less
    Adding features/flexibility doesn't necessarily improve a product. Increasing the # of engineers can actually slow down a project. An engineer who produces more lines of code or changesets/diff can still be less productive.
  2. A bad abstraction can be dramatically more harmful than no abstraction
    (even though, especially in larger codebases, a bad abstraction may still appear to save time)
  3. Cleverness is dangerous
    Perhaps a corollary to the prior item. What seems clever to one engineer is often incomprehensible to another. When the original author eventually leaves her code behind, the next person to come across it will be stuck with an indecipherable mess.
  4. Outliers matter—don't ignore the 1%
    Despite what you might've learned in a high-school statistics class, you definitely shouldn't disregard outliers when looking at software performance. Targeting 95th or 99th percentile improvements is a great way to find hot spots (for example, places where latency degrades quadratic ally w.r.t. A user's number of friends). In addition, users that are affected by these kinds of issues often have truly abysmal experiences with your software.