It has to work.

As simple as possible.

Use the right tool for the job.

Everything is a tradeoff. (see Rule 41)

A tool you know beats one you don’t.

Learn to use the defaults.

Learn to use the classics. (cf. taco bell programming)

Assume good intent, if not competence; the common case is benign neglect - and everyone makes mistakes.

No one-offs. (see Rule 21)

If you don’t have time to do it right, you will never have time to do it over (but see also Rule 10).

Good and complete beats perfect and unfinished (related: worse is better). (but see also Rule 23)

If at all possible, do it while you’re thinking of it - but in any case, always write it down. If it isn’t written down, it doesn’t exist.

(corollary to previous rule) Telepathy should never be an implicit part of your project planning. Communicate, in writing, early and often, especially with those outside of your immediate team. (If it’s written down but nobody else can see it, it doesn’t exist for them.)

Listen to your gut - if something feels sketchy or vaguely-defined, double-check it before you proceed. Hand-waving is a sure sign of danger ahead. (see also Rule 8 and Rule 9)

Drive to success, not to a deadline. The timeline should be an output of good project planning, not an input. (see also Rule 9 and Rule 12)

(corollary to previous rule) Before you begin, be clear on what constitutes success; be clear if that definition changes; be very clear on this point with colleagues and customers.

Automate, automate, automate. If you have to do it more than twice, make the computer do it for you. (with obvious caveats)

Consider your audience and adjust the level of detail accordingly, lest you lose the interest of upper management or the respect of your technical peers.

Understand the difference between a symptom and a cause, and strive to treat the latter. Communicate this distinction (and its importance) clearly.

Generally speaking, shallow but broad experience will serve you better than narrow and deep - be an expert on a few things, but be conversant with as many things as possible. (see Steve Simmons’ classic description of a systems administrator)

Uptime is job one. It doesn’t matter how compelling that new feature is if nobody can actually see it. (see Rule 0)

Consistency is a virtue, but beware monoculture: variations among platforms and software should be few and intentional, especially at scale. (see Rule 8)

The perfect is the enemy of the good: don’t let an inability to do everything become an excuse to do nothing. (see Rule 10)

(exception to previous rule) When it comes to security, do it right or not at all. Something that has the appearance of security, but is severely flawed (e.g. HTTPS using SSLv3), can be worse than something that is explicitly not secure (HTTP). Enable and encourage decisions (for users, mgmt and colleagues) based on reality, not appearances.

Be the kind of leader you yourself would like to follow.

(special travel rule) Pay in advance. Always carry cash. Only use the cash if you can’t use your cards.

Never promise what someone else will have to deliver without checking with them first. It’s easy to say something will be done when you’re not the one doing it.

Just because an option is the cheapest doesn’t make it the least expensive. The biggest costs are often not present in your monthly bill.

Automation begins (and oftentimes, ends) with documentation and the elimination of edge cases (see Rule 8). If it’s not reproducible, you can’t automate it.

It’s a very short step from outage to outrage. Manage those expectations early and often; communication is critical (see Rule 12).

Service delivery is everyone’s job, without exception (see Rule 0 and Rule 20).

The available work will always grow to equal at least 150% of your available time; an aggressive defense of work/life balance is key to career satisfaction and longevity.

Requirements (whether functional or non-functional) specify an outcome, not an implementation. Don’t become overly attached to the current way of doing things.

Sometimes the best solution to a problem is to change the requirements (see Rule 1). However, beware the XY Problem.

Make it hard to do the wrong thing: the default thing, the easy thing, and the right thing should all be the same thing.

“Build your opponent a golden bridge to retreat across.” – Sun Tzu

DNS is always production.

The problem is probably DNS.

You can’t fix a people problem with a technical solution.

Everything fails, all the time - expect it, architect for it, plan accordingly. Retries, failovers, and graceful degradation are critically important architectural principles (but see also Rule 1).

There are ways to misuse any tool.

When you don’t know what the problem is, every discrepancy is suspect.

Nothing is free. If you think it’s free, you don’t understand the tradeoffs yet. Not all costs are financial (see Rule 27).

Don’t panic.

Learn from the mistakes of others; life’s too short to make them all yourself.

(Corollary to previous rule) No matter how many mistakes you avoid, there remain an infinite number that you will not.

Every piece of data you store is a liability first and an asset second; don’t keep data you don’t need. Breaches will happen (see Rule 38).

Every new capability carries with it a corresponding risk; the newer the technology involved, the harder it is to assess downstream risks.

“When you invent the ship, you invent the shipwreck.” – Paul Virilio

What you do will change periodically; how you do it, frequently; why you do it, rarely. Make your decisions accordingly.

Every rule has exceptions, and this list is no exception. Knowing when those apply is the real wisdom.