Hammurabi

“If a decision is easily reversible, ship within 24 hours. Only spend weeks on irreversible 'one-way doors'.”

“Do not say 'it worked before' to skip investigation. Fix hacks or document them as high-priority debt.”

“You are forbidden from removing a fence until you can explain exactly why it was put there.”

“Ask: 'If this were the start of a total collapse, what would the next 10 minutes look like?'”

“If a review spends 80% on style, approve immediately and move to automated linter configs.”

“A complex system that works evolved from a simple system that worked. Start with a working 'Hello World'.”

“To get a modular architecture, create independent teams first. Do not fight the org chart with code.”

“Assume every change is breaking once you have users. Use strict versioning and feature flags.”

“If a project is late, do not add people. Remove features or push the date.”

“When someone asks 'How do I do Y?', always reply 'What are you trying to achieve with Y?'”

“Be conservative in what you send and liberal in what you accept.”

“Never attribute to malice what is adequately explained by lack of context. Debug the system.”

“Double your most conservative estimate, then add 20%. Expect to be wrong.”

“Never use a single metric to judge performance. Observe outputs, not proxies.”

“If you need stability for 10 years, choose a technology that has already been around for 10 years.”

“Ask: 'If we started today with zero investment, would we choose this path?' If no, kill it.”

“Adopt a tool because you have the exact problem it solves, not because Google uses it.”

“Find the 1% of code that takes 90% of time. Only optimize that. Ignore the rest.”

“Use abstractions to move fast, but ensure someone understands the layer beneath it.”

“Identify the 'Critical 20%' and give it 100% of your quality focus.”

“Before adopting a strategy because 'Company X succeeded with it,' research how many failed using the same approach. The dead don't write blog posts.”

“Code cleverness is a liability, not an asset. Write code your future self, sleep-deprived at 3 AM, can still understand in 6 months.”

“For every incentive, ask: 'If someone wanted to game this, how would they?' If you find a way, the design is wrong.”

“When a team exceeds 7±2 people, split it. If 'information-sharing meetings' multiply, you've exceeded the cognitive limit.”

“A solution 80% correct that ships today will outperform a 100% correct one that ships next year. Optimize for adoption, not elegance.”

“When docs are missing, post your best guess of how something works. The expert will appear to correct you faster than if you'd asked directly.”

“Never say "Can someone look at this?" Say "@name, you are investigating this." Assign a single, named owner for every incident.”

“Treat every external dependency, retry, and timeout as something that will fail in production. Build the failure path before the success path.”

“Always leave the code cleaner than you found it. A one-line rename or a deleted dead branch is small enough for the same PR and bends the entropy curve over months.”

“When a 'simple API' feels too clean, ask: who absorbed the complexity I just removed? If you can't name them, you didn't simplify — you displaced.”

“When someone declares a hard problem "easy," check their domain history before trusting the estimate. Weight the quiet veteran over the confident newcomer.”

“Before shipping docs or an API, have someone unfamiliar attempt the task while you watch silently. Their confusion maps the assumptions you forgot to spell out.”

“In an incident review, do not stop at the one thing that failed. Enumerate every layer that should have caught it and ask why each hole was open at the same moment.”

“Write the obvious code first. Only optimize hot paths that a profiler proves are bottlenecks. Keep the other 97% simple for the next maintainer.”

“If a bug class keeps slipping through, do not assign the same reviewers more carefully — expose the code to differently-shaped eyes. Rotate, open up, bounty.”

“Decide before an outage whether each operation prefers consistency or availability. The partition will happen; the only question is what your system does when it does.”

“To cut latency without adding capacity, cut work-in-progress. Cap concurrent requests — a shorter queue is faster than a faster server.”

“Never assume "I sent it, so they got it." Make every cross-network action safely retryable and idempotent, and reconcile state instead of trusting one round-trip.”

“Do not promote your best engineer into management as a reward. Offer a technical ladder, and evaluate candidates for the role above, not the one they already mastered.”

“Set deliberately short timeboxes for open-ended work and review at the deadline. A tight box forces the scoping decisions an open one defers forever.”

“Treat the speed a faster machine buys you as a budget to protect, not a license to spend. Set a performance budget and fail the build when a release regresses against it.”

“When something looks almost done, assume an entire second project remains: hardening, edge cases, integration. Schedule it, do not treat it as a rounding error.”

“Write code and commit messages for the stranger you will become in six months. If a decision is not obvious from the code, record the why — not in your head.”

“Cut the choices on any screen or API surface to the few that matter; push the rest behind sensible defaults. Fewer doors, faster decisions.”

“Make frequent actions big and easy to hit; make rare or destructive ones small and far. Screen edges and corners are infinite targets — put primary actions there.”

“Group related items into a handful of named chunks wherever a person must hold state in their head: arguments, form fields, menu groups, on-call steps.”