Make it work, make it beautiful, make it fast.

We tend to skip the last two even if we somehow achieve the first.

Corollary: Code first, optimize later. (a.k.a Premature optimization).

What's built in here is this: please write code you can observe, measure and test as it works.

We are all sure of the things that are slow, optimal, and want to try the stuff that is new and cool. But in real life, which is to say in real software, and as time passes these "rules" change. Don't take some dictum, some claim, or some rule of thumb to be the truth. Instead, code in the simplest, most obvious, most readable way first: get it to work, first and foremost. Simplicity is king.

But make sure you can know (or learn) the difference between simple and simplistic.

Simplicity is bad when it is simplistic -- simplicity is a virtue, being overly simple (simplistic) is bad, and evidence of intellectual laziness. You need to write code that measures itself. Good code is inherently introspective. Rails exemplifies this, with built-in timings of major phases. You're not a bad person if your first few passes at coding turn out to be over-simplifications of a problem (on the contrary: try to simplify!). But when you find your model of the requirement is less than needed, keep looking for a way to make it simple. Simple is not slow, bad, or dumb: simple is artful.

You'll find that a joy of software development in the modern age is that things that are known to be slow (databases, interpreted languages, IO, etc.) are often not the bottleneck. In real code, it's usually just code that does what it needs in a silly way that makes for badness. If you can measure timings, and profile your code, you can find and fix what needs fixing, and leave the perfectly simple and elegant code alone.

It's funny, for all of the beautiful code and optimized code I have seen, it's usually the beautiful code that performs best. There's something about truly understanding the problem that is necessary to make code beautiful -- it's surprising and wonderful that this depth of understanding tends to coincide with, hence obviate the need for optimization.

But sometimes, beautiful code doesn't perform. And then, you may need to optimize. Look for the simplest and most obvious optimizations first -- a missing index, a repeated query or method, a thing that is expensive to do that is requested often is a candidate for caching.

Don't cache unless you see you need it. Don't thread unless you need it. Don't denormalize data unless you must. Don't build fancy subsystems because it seems evident that they will be needed to scale. And above all: don't be lazy (even if that's the fastest way to get it to work).

Complexity is the enemy. Simplicity is the art of making something complex look easy.

Software engineering is art.

Make it work, make it beautiful, make it fast.