Skip to content

Instantly share code, notes, and snippets.

@darkuncle
Last active February 26, 2026 15:29
Show Gist options
  • Select an option

  • Save darkuncle/d366a6c4323db64a7b761704d6f1ab95 to your computer and use it in GitHub Desktop.

Select an option

Save darkuncle/d366a6c4323db64a7b761704d6f1ab95 to your computer and use it in GitHub Desktop.
The Rules - guidelines learned through hard experience in operations

(taken from Hard Sayings of the Bible)

The Rate for the Job? (Mt 20:14-15)

One of the complaints that right-living and religious people made about Jesus arose from his treatment of the more disreputable members of society. They might have agreed that such persons should not be entirely excluded from the mercy of the all-loving God. Even for them there was hope, if they showed by practical repentance and unquestionable amendment of life that they were not beyond redemption. But not until such evidence had been given could they begin to be accepted as friends and neighbors. Jesus, however, accepted them immediately; he did not wait to see the outcome before he committed himself to them. This was disturbing; it was even more disturbing that he seemed to think more highly of them than of those who had never blotted their public copybook. He gave the impression that he actually preferred the company of the rejects of society; he not only made them feel at home in his company, so that they felt free to take liberties with him that they would never have thought of taking with an ordinary rabbi, but even accepted invitations to share a meal with them and appeared genuinely to enjoy such an occasion. When he was challenged for this unconventional behavior, his reply was that this was how God treated sinners; and he told several parables to reinforce this lesson.

One of these parables tells of the man who hired a number of casual laborers to gather the grapes in his vineyard when the appropriate time of year came round. It is a disconcerting parable on more levels than one because it seems to defend the unacceptable principle of equal pay for unequal work. There are certain seasons when a farmer or a vinegrower requires a large supply of labor for a short period. In the economic depression from which most of Palestine suffered in the time of Jesus, anyone who wanted such a short-term supply of labor was sure of finding it. The vinegrower in the parable had only to go to the village marketplace and there he would find a number of unemployed men hanging around in hope that someone would come and offer them a job.

At daybreak, then, this vinegrower went to the marketplace and hired several men to do a day’s work for him gathering grapes. The agreed rate for such a day’s work was a denarius, which was evidently sufficient to keep a laborer and family at subsistence level for a day. Apparently the vinegrower wanted the job completed within one day. As he considered the amount of work to be done and the speed at which the men were working, he decided that he would need more hands, so at three-hour intervals he went and hired more. He did not bargain with them for a denarius or part of a denarius: he promised to give them what was proper. Then, just an hour before sunset, in order to ensure that the work would not be left unfinished, he went back and found a few men still unemployed, so he sent them to join the others working in the vineyard.

An hour later the work was finished, and the workers lined up to receive their pay, the last-hired being at the front of the line. They had no idea what they would get for an hour’s work; in fact, each of them received a denarius. So did the men who had worked three hours, six hours and nine hours. At last came those who had been hired at daybreak and had done twelve hours’ work. What would they get? Each of them similarly got a denarius. They complained, “Why should these others get as much as we have done? Why should not we get more after a hard day’s work?” But the vinegrower told them that they had no cause for complaint. They had agreed to do a day’s work for a denarius, and he had kept his promise to give them that. It was no business of theirs what he gave to others who had entered into no agreement with him for a fixed sum. He might have said, “They and their families have to live.” But he did not; he simply said, “Can’t I do what I like with my own money?”

The law-abiding people whom Jesus knew tended to feel that they had made a bargain with God: if they kept his commandments, he would give them the blessings promised to those who did so. They would have no reason to complain if God treated them fairly and kept his promises. But what about those others who had broken his commandments, who had started to do his will late in the day after their encounter with Jesus and the way of the kingdom? They were in no position to strike a bargain with God; they could do nothing but cast themselves on his grace, like the tax collector in another parable who could only say, “God, have mercy on me, a sinner” (Lk 18:13). What could they expect? The lesson of the parable seems to be this: when people make a bargain with God, he will honor his promise and give them no cause for complaint; but there is no limit to what his grace will do for those who have no claim at all on him but trust entirely to his goodness. If it be said that this gives them an unfair advantage, let it be considered that they were terribly disadvantaged to begin with. If it be urged that their rehabilitation should involve some payment for their past misdeeds, the truth may be that they have paid enough already. Should those who have turned to God at the eleventh hour and given him only the last twelfth of life get as much of heaven as those who have given him a whole lifetime? If God is pleased to give them as much, who will tell him that he should not? If God did not delight in mercy, it would go hard with the best of us. Though justice by thy plea, consider this, That, in the course of justice, none of us Should see salvation.[Shakespeare, The Merchant of Venice, IV, i.] The first arrivals might not have complained if the last comers had been paid only a small fraction of what they themselves received. There was in fact, as T. W. Manson points out in his treatment of this parable, a coin worth one-twelfth of a denarius: “It was called a pondion. But there is no such thing as a twelfth part of the love of God.” [T. W. Manson, The Sayings of Jesus (reprint; Grand Rapids, Mich.: Eerdmans, 1979), p. 220.]

(subject to additions, but rarely changes)

rule 0: It has to work.

rule 1: As simple as possible.

rule 2: Use the right tool for the job.

rule 3: Everything is a tradeoff. (see Rule 41)

rule 4: A tool you know beats one you don't (but previous rules trump).

rule 5: Learn to use the defaults.

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

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

rule 8: No one-offs. (see rule 21)

rule 9: If you don't have time to do it right, you will never have time to do it over (but see also rule 10).

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

rule 11: 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.

rule 12: (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.)

rule 13: 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 rules 8 and 9)

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

rule 15: (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. Desired and required are not synonymous.

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

rule 17: 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.

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

rule 19: 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)

rule 20: Uptime is job one. It doesn't matter how compelling that new feature is if nobody can actually see it. (see rule 0)

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

rule 22: 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)

rule 23: (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.

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

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

rule 26: 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.

rule 27: 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.

rule 28: 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.

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

rule 30: Service delivery is everyone's job, without exception (rules 0 and 20).

rule 31: 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.

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

rule 33: Sometimes the best solution to a problem is to change the requirements (see rule one). However, beware the XY Problem.

rule 34: 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

rule 35: DNS is always production.

rule 36: The problem is probably DNS.

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

rule 38: 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).

rule 39: There are ways to misuse any tool.

rule 40: When you don't know what the problem is, every discrepancy is suspect.

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

rule 42: Don't panic.

rule 43: Learn from the mistakes of others; life's too short to make them all yourself.

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

rule 45: 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).

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment