HACKER
HEURISTICS
27 Essential Mental Models for Navigating the Unknown. Decipher the hidden mechanics of systems and organizations.
Type 1 vs Type 2 Decisions
LOG_01:The brain instinctively treats all failures as threats, demanding excessive caution for reversible decisions (two-way doors).
GUIDELINE_
"If a decision is easily reversible, ship within 24 hours. Only spend weeks on irreversible 'one-way doors'."
Normalization of Deviance
LOG_01:When a minor rule is broken and no disaster occurs, the brain re-classifies deviance as 'normal'.
GUIDELINE_
"Do not say 'it worked before' to skip investigation. Fix hacks or document them as high-priority debt."
Chesterton's Fence
LOG_01:The ego jumps to 'simplify' by deleting legacy code/rules it doesn't immediately understand.
GUIDELINE_
"You are forbidden from removing a fence until you can explain exactly why it was put there."
Normalcy Bias
LOG_01:In a crisis, the brain defaults to the most frequent explanation. 'It's just a transient error' as systems fail.
GUIDELINE_
"Ask: 'If this were the start of a total collapse, what would the next 10 minutes look like?'"
Law of Triviality
LOG_01:People provide more feedback on simple things (naming) than complex ones because everyone understands them.
GUIDELINE_
"If a review spends 80% on style, approve immediately and move to automated linter configs."
Gall's Law
LOG_01:The delusion that complex systems can be designed top-down from scratch. They are too chaotic.
GUIDELINE_
"A complex system that works evolved from a simple system that worked. Start with a working 'Hello World'."
Conway's Law
LOG_01:Software architecture is a map of the org chart. If teams don't talk, their services won't integrate.
GUIDELINE_
"To get a modular architecture, create independent teams first. Do not fight the org chart with code."
Hyrum's Law
LOG_01:With enough users, every observable behavior (even bugs) will be depended on by someone.
GUIDELINE_
"Assume every change is breaking once you have users. Use strict versioning and feature flags."
Brooks' Law
LOG_01:Adding people to a late project increases communication overhead exponentially. New people drain veterans.
GUIDELINE_
"If a project is late, do not add people. Remove features or push the date."
The XY Problem
LOG_01:Users get stuck on a solution (Y) and ask for help with it, forgetting the original problem (X).
GUIDELINE_
"When someone asks 'How do I do Y?', always reply 'What are you trying to achieve with Y?'"
Postel's Law
LOG_01:Assuming everyone follows the spec perfectly leads to brittle failures in distributed systems.
GUIDELINE_
"Be conservative in what you send and liberal in what you accept."
Hanlon's Razor
LOG_01:Assuming malice or sabotage for bugs/delays when it's usually just lack of sleep or context.
GUIDELINE_
"Never attribute to malice what is adequately explained by lack of context. Debug the system."
Hofstadter's Law
LOG_01:It always takes longer than you expect, even when you take into account Hofstadter's Law.
GUIDELINE_
"Double your most conservative estimate, then add 20%. Expect to be wrong."
Goodhart's Law
LOG_01:When a measure becomes a target, it ceases to be a good measure. Rewards for 'commits' create junk commits.
GUIDELINE_
"Never use a single metric to judge performance. Observe outputs, not proxies."
Lindy Effect
LOG_01:For non-perishables like software, the longer it has survived, the longer it is likely to survive.
GUIDELINE_
"If you need stability for 10 years, choose a technology that has already been around for 10 years."
Sunk Cost Fallacy
LOG_01:Continuing to invest in failing projects because 'we've already spent so much.' The brain hates loss.
GUIDELINE_
"Ask: 'If we started today with zero investment, would we choose this path?' If no, kill it."
Cargo Cult Engineering
LOG_01:Copying practices of successful companies (Spotify Model) without understanding the 'why'.
GUIDELINE_
"Adopt a tool because you have the exact problem it solves, not because Google uses it."
Amdahl's Law
LOG_01:Optimizing a part has no impact if the bottleneck is elsewhere. Resource waste.
GUIDELINE_
"Find the 1% of code that takes 90% of time. Only optimize that. Ignore the rest."
Leaky Abstractions
LOG_01:All non-trivial abstractions leak. You can't use SQL without understanding indexes eventually.
GUIDELINE_
"Use abstractions to move fast, but ensure someone understands the layer beneath it."
Pareto Principle
LOG_01:80% of bugs come from 20% of code. 80% of value comes from 20% of features.
GUIDELINE_
"Identify the 'Critical 20%' and give it 100% of your quality focus."
Survivorship Bias
LOG_01:We study only the successes that survived and draw conclusions, ignoring the silent graveyard of failures that used the same strategy.
GUIDELINE_
"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."
Kernighan's Law
LOG_01:"Debugging is twice as hard as writing the code. If you write the cleverest code you can, you are by definition not smart enough to debug it."
GUIDELINE_
"Code cleverness is a liability, not an asset. Write code your future self, sleep-deprived at 3 AM, can still understand in 6 months."
The Cobra Effect
LOG_01:A solution designed to fix a problem creates a worse one. A bounty on cobras led people to breed cobras for the reward.
GUIDELINE_
"For every incentive, ask: 'If someone wanted to game this, how would they?' If you find a way, the design is wrong."
Dunbar's Number
LOG_01:Humans can maintain ~150 stable relationships. Teams larger than ~8 experience exponential communication breakdown.
GUIDELINE_
"When a team exceeds 7±2 people, split it. If 'information-sharing meetings' multiply, you've exceeded the cognitive limit."
Worse is Better
LOG_01:A simpler, 'inferior' design that is easy to implement and adopt will beat a theoretically 'correct' but complex one. Unix beat Lisp. HTTP beat CORBA.
GUIDELINE_
"A solution 80% correct that ships today will outperform a 100% correct one that ships next year. Optimize for adoption, not elegance."
Cunningham's Law
LOG_01:"The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer." People correct mistakes faster than they answer questions.
GUIDELINE_
"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."
Bystander Effect
LOG_01:The more people present, the less likely any single person acts. 'Someone else will handle it.' A page to a group channel often means nobody responds.
GUIDELINE_
"Never say "Can someone look at this?" Say "@name, you are investigating this." Assign a single, named owner for every incident."
"Good engineering is not about avoiding all risks, but about deciding which risks are worth taking."
— SYSTEM_PRINCIPAL_MAXIM