A collection of 189 laws, effects, mental models and fallacies that explain how people, organisations and systems behave. Each entry has a short definition, an explanation with examples, and a practical takeaway.

Which Law for Which Situation?

Use this as a lookup table: find your situation, then read the entries listed (numbers refer to the entries below).

Part 1: The Classic 11

1. Parkinson’s Law

Work expands to fill the time available for its completion.

Coined by C. Northcote Parkinson in 1955 after watching the British civil service grow while its workload shrank. If you give a task two weeks, it takes two weeks. Give it two days and it often gets done in two days.

Takeaway: Set tight but realistic deadlines. Timebox meetings, spikes and reviews.

2. Hofstadter’s Law

It always takes longer than you expect, even when you take Hofstadter’s Law into account.

From Douglas Hofstadter’s Gödel, Escher, Bach. The joke is that it’s recursive: padding your estimate doesn’t fix it, because unknowns compound in ways you can’t foresee.

Takeaway: Treat estimates as ranges, not promises. Track actuals against estimates to calibrate over time.

3. Hanlon’s Razor

Never attribute to malice what can be adequately explained by incompetence, carelessness or misunderstanding.

Most “bad behaviour” at work comes from people being busy, uninformed or under pressure, not from scheming.

Takeaway: Assume good intent first. Ask clarifying questions before escalating.

4. The Pareto Principle (80/20 Rule)

Roughly 80% of effects come from 20% of causes.

Named after Vilfredo Pareto, who noticed 80% of Italy’s land was owned by 20% of the people. In software, about 20% of bugs cause 80% of crashes, and 20% of features deliver most of the value.

Takeaway: Find the vital few. Prioritise the work with the most leverage.

5. The Peter Principle

In a hierarchy, people tend to rise to their level of incompetence.

From Laurence J. Peter (1969). People get promoted for doing their current job well, until they reach a role they’re not good at, and stay there.

Takeaway: Promote based on fit for the next role, not performance in the current one. Offer dual career tracks (IC vs management).

6. Hick’s Law

The time it takes to make a decision increases with the number and complexity of choices.

A UX principle from psychologists William Hick and Ray Hyman. Decision time grows roughly logarithmically with the number of options.

Takeaway: Reduce choices in UIs, menus and option papers. Offer sensible defaults.

7. Goodhart’s Law

When a measure becomes a target, it ceases to be a good measure.

Named after economist Charles Goodhart. If you reward lines of code, you get bloated code. If you reward ticket closure rates, tickets get closed without being solved.

Takeaway: Use metrics to inform, not to judge. Pair quantitative metrics with qualitative checks.

8. The Dunning-Kruger Effect

People with low skill in an area tend to overestimate their ability, while experts often underestimate theirs.

From David Dunning and Justin Kruger (1999). Beginners don’t know enough to see what they’re missing.

Takeaway: Seek external feedback. Be wary of confident opinions from people new to a domain, including yourself.

9. Occam’s Razor

Among competing explanations, the one with the fewest assumptions is usually the best.

Attributed to 14th-century friar William of Ockham. Not “the simplest is always right”, but “don’t add complexity you don’t need”.

Takeaway: When debugging, check the obvious first. When designing, avoid unnecessary moving parts.

10. Chesterton’s Fence

Don’t remove a fence until you know why it was put up.

From G.K. Chesterton (1929). A rule, process or line of code that looks pointless may exist for a reason you can’t see.

Takeaway: Before deleting legacy code or retiring a process, find out why it exists. Check commit history, ask the original owners.

11. Brooks’s Law

Adding people to a late software project makes it later.

From Fred Brooks’s The Mythical Man-Month (1975). New people need onboarding, and communication paths grow as n(n−1)/2.

Takeaway: Cut scope or move the date before throwing people at a late project.

Part 2: Systems, Software & Organisations

12. Conway’s Law

Organisations design systems that mirror their own communication structures.

From Melvin Conway (1967). Four teams building a compiler will produce a four-pass compiler. Org boundaries become service boundaries.

Takeaway: Design your team structure with your target architecture in mind (the “Inverse Conway Manoeuvre”).

13. Gall’s Law

A complex system that works is invariably found to have evolved from a simple system that worked.

From John Gall’s Systemantics (1975). A complex system designed from scratch never works and can’t be patched into working; you have to start over with a simple working system.

Takeaway: Start with an MVP or walking skeleton. Evolve, don’t big-bang.

14. Hyrum’s Law

With a sufficient number of users of an API, every observable behaviour of your system will be depended on by somebody.

From Hyrum Wright at Google. Response ordering, timing, error message text: if it’s observable, someone relies on it, whatever your contract says.

Takeaway: Every change is potentially breaking. Version APIs carefully and minimise what’s observable.

15. Postel’s Law (Robustness Principle)

Be conservative in what you send, be liberal in what you accept.

From Jon Postel, in early TCP specifications. It improves interoperability, though critics note that being too liberal lets sloppy inputs become de facto standards (see Hyrum’s Law).

Takeaway: Emit strictly valid output. Accept input tolerantly, but validate and log anomalies.

16. Kernighan’s Law

Debugging is twice as hard as writing the code in the first place. So if you write code as cleverly as possible, you are, by definition, not smart enough to debug it.

From Brian Kernighan.

Takeaway: Write clear, boring code. Optimise for the reader.

17. Amdahl’s Law

The speedup from improving part of a system is limited by the fraction of time that part is used.

From Gene Amdahl (1967). If 10% of a workload must run serially, you’ll never get more than a 10× speedup, no matter how many cores you add.

Takeaway: Profile first. Optimise the bottleneck, not what’s easy to optimise.

18. The Law of Leaky Abstractions

All non-trivial abstractions, to some degree, are leaky.

From Joel Spolsky (2002). ORMs leak SQL performance issues, TCP leaks network failures, low-code platforms leak their underlying runtime.

Takeaway: Understand at least one layer below the abstraction you work in.

19. Zawinski’s Law

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

From Jamie Zawinski. A tongue-in-cheek observation about feature creep: products keep absorbing adjacent features.

Takeaway: Guard product scope. Say no to features that don’t serve the core job.

20. Campbell’s Law

The more a quantitative social indicator is used for decision-making, the more it will be subject to corruption pressures and distort the processes it is meant to monitor.

From Donald Campbell (1976). A close cousin of Goodhart’s Law, focused on social and policy settings (e.g. teaching to the test).

Takeaway: Rotate or combine indicators. Watch for gaming.

21. Price’s Law

The square root of the number of people in a domain produce half of the output.

From Derek de Solla Price. In a team of 100, about 10 people do half the work. As groups grow, output concentrates further.

Takeaway: Identify and protect key contributors. Bigger teams don’t scale output linearly.

22. Sturgeon’s Law

Ninety percent of everything is crap.

From sci-fi writer Theodore Sturgeon, defending his genre: most of every genre is mediocre, so judge a field by its best work.

Takeaway: Be selective about inputs (articles, tools, frameworks). Curate ruthlessly.

23. The Lindy Effect

The future life expectancy of non-perishable things (ideas, technologies, books) is proportional to their current age.

Popularised by Nassim Taleb. A book in print for 100 years will likely last another 100; a framework released last year may not last five.

Takeaway: Favour proven technologies (SQL, Unix, HTTP) for foundations. Be cautious with the new and shiny.

24. Cunningham’s Law

The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.

Attributed to Ward Cunningham (inventor of the wiki). People are more motivated to correct than to help.

Takeaway: Share drafts and strawman proposals early; critique comes faster than ideas from a blank page.

Part 3: Thinking Tools

25. Murphy’s Law

Anything that can go wrong will go wrong.

Origin traced to US Air Force engineer Edward Murphy (1949). Less pessimism, more a design principle: plan for failure.

Takeaway: Design for failure: retries, timeouts, circuit breakers, backups you’ve actually tested.

26. Sayre’s Law

In any dispute, the intensity of feeling is inversely proportional to the value of the issues at stake.

From political scientist Wallace Sayre, originally about academic politics.

Takeaway: When a debate gets heated over something small, step back and ask what really matters.

27. Parkinson’s Law of Triviality (Bikeshedding)

Organisations give disproportionate weight to trivial issues.

Parkinson’s example: a committee approves a nuclear plant quickly but argues at length over a bike shed, because everyone understands the bike shed.

Takeaway: Timebox trivial decisions. Delegate them. Put the hard topics first on the agenda.

28. Brandolini’s Law (Bullshit Asymmetry Principle)

The amount of energy needed to refute nonsense is an order of magnitude larger than to produce it.

From Alberto Brandolini (2013).

Takeaway: Pick your battles. Prevent misinformation early (clear docs, ADRs) rather than chasing it later.

29. Second-Order Thinking

Consider not just the immediate consequences of a decision, but the consequences of those consequences.

First-order: “This shortcut saves us a week.” Second-order: “…and creates tech debt that costs us a month next year.”

Takeaway: Ask “and then what?” at least twice before committing.

30. Inversion

Solve problems by thinking backwards: ask what would guarantee failure, then avoid it.

From mathematician Carl Jacobi (“Invert, always invert”) and popularised by Charlie Munger.

Takeaway: Run pre-mortems: “It’s six months from now and this project failed. Why?”

Part 4: Engineering & Architecture

31. Little’s Law

Average items in a system = arrival rate × average time each item spends in the system (L = λW).

From John Little (1961), queueing theory. It holds for any stable system: request queues, thread pools, Kanban boards. If 100 requests/sec arrive and each takes 0.5s, about 50 are in flight at any moment.

Takeaway: Use it for capacity planning (connection pools, worker counts). On teams, limiting work-in-progress cuts lead time.

32. CAP Theorem

A distributed data store can guarantee at most two of: Consistency, Availability, Partition tolerance.

From Eric Brewer (2000). Since network partitions will happen, the real choice is between consistency and availability when they do. PACELC extends it: even without partitions, you trade latency against consistency.

Takeaway: Decide explicitly per use case: payments lean consistent, social feeds lean available.

33. The Fallacies of Distributed Computing

Eight false assumptions developers make about networks.

From Peter Deutsch and colleagues at Sun: the network is reliable; latency is zero; bandwidth is infinite; the network is secure; topology doesn’t change; there is one administrator; transport cost is zero; the network is homogeneous.

Takeaway: Use the list as a review checklist for any design that crosses a network boundary.

34. Tesler’s Law (Conservation of Complexity)

Every application has an inherent amount of complexity that cannot be removed, only moved.

From Larry Tesler. Someone has to deal with the complexity: the user, the developer or the platform.

Takeaway: Absorb complexity in the system so users don’t have to. Low-code platforms move complexity; they don’t remove it.

35. Premature Optimisation (Knuth’s Principle)

“Premature optimisation is the root of all evil.”

From Donald Knuth (1974). The full quote says we should forget small efficiencies about 97% of the time, but not pass up the critical 3%.

Takeaway: Make it work, make it right, then make it fast, guided by measurement. Do think about architecture-level performance early.

36. The Ninety-Ninety Rule

The first 90% of the code takes 90% of the time. The remaining 10% takes the other 90%.

From Tom Cargill at Bell Labs. Edge cases, integration, hardening and polish are consistently underestimated.

Takeaway: Budget generously for the “last mile”: testing, security, deployment, documentation.

37. Linus’s Law

Given enough eyeballs, all bugs are shallow.

Named by Eric Raymond after Linus Torvalds. More reviewers make problems easier to spot, though Heartbleed showed that “enough eyeballs” isn’t automatic.

Takeaway: Invest in code review and open internal codebases, but don’t assume someone else has looked.

38. YAGNI (You Aren’t Gonna Need It)

Don’t build functionality until it’s actually needed.

From Extreme Programming. Speculative features cost time to build, maintain and understand, and often turn out to be wrong.

Takeaway: Design for extension, but implement only what’s required now.

39. KISS (Keep It Simple, Stupid)

Most systems work best if they’re kept simple rather than made complicated.

Attributed to Lockheed engineer Kelly Johnson: jets should be repairable by an average mechanic with basic tools in the field.

Takeaway: Prefer the solution a new joiner can understand. Complexity must earn its place.

40. Law of Demeter (Principle of Least Knowledge)

A module should only talk to its immediate friends, not to strangers.

From Northeastern University (1987). Avoid chains like order.getCustomer().getAddress().getCity().

Takeaway: Reduce coupling. At the architecture level, services shouldn’t reach through other services’ internals.

41. Principle of Least Astonishment

A component should behave in the way most users expect it to.

If a function named getUser() also deletes a cache, that’s astonishing.

Takeaway: Naming, defaults and API behaviour should match intuition. Surprise is a bug.

42. Lehman’s Laws of Software Evolution

A system in use must continually change or become less useful, and as it changes its complexity increases unless work is done to reduce it.

From Manny Lehman (1970s onwards), based on studying IBM’s OS/360.

Takeaway: Budget for refactoring and tech-debt reduction continuously, not as a one-off.

43. Metcalfe’s Law

The value of a network is proportional to the square of the number of connected users (n²).

From Robert Metcalfe, co-inventor of Ethernet. It explains network effects in platforms, marketplaces and shared services.

Takeaway: Shared platforms and common APIs grow in value with adoption. Lower the barrier to joining.

44. Wirth’s Law

Software is getting slower more rapidly than hardware is getting faster.

From Niklaus Wirth (1995). Bloat, layers of abstraction and heavier frameworks eat up hardware gains.

Takeaway: Hardware won’t save inefficient software. Keep an eye on dependency weight and performance budgets.

Part 5: UX & Design

45. Fitts’s Law

The time to reach a target depends on its distance and size.

From Paul Fitts (1954). Big, close targets are fast to hit; small, far ones are slow.

Takeaway: Make primary actions large and easy to reach. Put destructive actions out of the way.

46. Jakob’s Law

Users spend most of their time on other sites, so they expect yours to work the same way.

From Jakob Nielsen.

Takeaway: Follow established conventions. Innovate on what’s valuable, not on where the login button goes.

Part 6: Economics, Bias & Strategy

47. The Cobra Effect

An incentive meant to solve a problem makes it worse.

The story goes that colonial Delhi paid a bounty for dead cobras, so people bred cobras. When the bounty was scrapped, they released them. It’s Goodhart’s Law with consequences.

Takeaway: Before setting an incentive, ask how someone could game it.

48. Jevons Paradox

Making a resource more efficient to use can increase total consumption of it.

From William Stanley Jevons (1865): more efficient steam engines led to more coal use, not less. Cheaper cloud compute leads to more compute spend.

Takeaway: Efficiency gains don’t automatically mean savings. Pair them with governance (e.g. FinOps).

49. Sunk Cost Fallacy

Continuing something because of what you’ve already invested, rather than its future value.

“We’ve spent two years on this platform, we can’t abandon it now.”

Takeaway: Decide based on future costs and benefits only. Past spend is gone either way.

50. Survivorship Bias

Drawing conclusions only from the successes that survived, ignoring the failures you can’t see.

The classic example: in WWII, Abraham Wald advised armouring the parts of returning planes that weren’t hit, because planes hit there never came back.

Takeaway: When studying “what worked”, ask what happened to the ones that failed.

51. Planning Fallacy

People underestimate the time, cost and risk of future tasks, even when they know similar tasks overran.

From Daniel Kahneman and Amos Tversky (1979). The behavioural science behind Hofstadter’s Law.

Takeaway: Use reference-class forecasting: base estimates on how long similar past projects actually took.

52. The Map Is Not the Territory

A model of reality is not reality itself.

From Alfred Korzybski. Architecture diagrams, org charts and dashboards are simplifications that can drift from what’s real.

Takeaway: Validate diagrams against running systems. Go and see.

53. Circle of Competence

Know the boundaries of what you genuinely understand, and operate within them.

Popularised by Warren Buffett and Charlie Munger. The size of the circle matters less than knowing where its edge is.

Takeaway: Be confident inside your circle, humble outside it, and bring in experts at the edges. (A good antidote to Dunning-Kruger.)

54. One-Way vs Two-Way Doors

Some decisions are irreversible (one-way doors); most are reversible (two-way doors).

From Jeff Bezos’s shareholder letters. Treating every decision as one-way makes an organisation slow.

Takeaway: Decide two-way-door choices quickly and lightly. Reserve deep analysis for irreversible ones (data models, public APIs, vendor lock-in).

55. Regression to the Mean

Extreme results tend to be followed by more average ones.

Described by Francis Galton. A record-breaking quarter or a terrible sprint is often partly luck, and the next one will likely be closer to normal.

Takeaway: Don’t over-react to outliers, and be careful crediting (or blaming) an intervention that followed one.

Part 7: Decision-Making

56. The Eisenhower Matrix

Sort tasks by urgent vs important: do, schedule, delegate, or drop.

Attributed to Dwight Eisenhower: “What is important is seldom urgent, and what is urgent is seldom important.” Important but not urgent work (architecture, learning, relationships) is where long-term value lives, and it’s the first thing to get crowded out.

Takeaway: Protect time for important-not-urgent work. Delegate or drop the urgent-not-important.

57. Opportunity Cost

The true cost of a choice is the value of the best alternative you gave up.

Saying yes to one project is saying no to everything else that team could have done.

Takeaway: Always compare against the next-best option, not against doing nothing.

58. Expected Value

Weigh each outcome by its probability, then add them up.

A 10% chance of a $1M gain is worth more on average than a guaranteed $50K. But watch for ruin: never take a bet where the downside wipes you out, however good the average.

Takeaway: Think in probabilities and payoffs, not just “will it work?”. Avoid bets with catastrophic downside.

59. Probabilistic Thinking & Bayesian Updating

Hold beliefs as probabilities and update them as new evidence arrives.

From Thomas Bayes. Instead of “this vendor is reliable”, think “I’m 70% confident”, then adjust after the PoC, the reference checks and the first incident.

Takeaway: Avoid binary certainty. Ask “what would change my mind?” and look for it.

60. The 70% Rule

Make most decisions with about 70% of the information you wish you had.

From Jeff Bezos. Waiting for 90% usually means you’re too slow, and being good at course-correcting makes being wrong cheaper.

Takeaway: Combine with one-way vs two-way doors: decide reversible things at 70%, gather more for irreversible ones.

61. Analysis Paralysis

Over-analysing a decision until no decision gets made.

More options and more data can make deciding harder, not easier (see Hick’s Law). Not deciding is itself a decision, usually a bad one.

Takeaway: Set a decision deadline and a “good enough” bar up front.

62. Satisficing vs Maximising

Satisficers pick the first option that meets their criteria; maximisers search for the best possible option.

From Herbert Simon. Research by Barry Schwartz suggests maximisers often get slightly better outcomes but feel less satisfied with them.

Takeaway: Maximise only for high-stakes, irreversible choices. Satisfice for the rest.

63. Regret Minimisation Framework

Project yourself to age 80 and ask which choice you’d regret less.

Used by Jeff Bezos when deciding to leave his job to start Amazon. People tend to regret what they didn’t do more than what they tried and failed at.

Takeaway: Use it for big personal and career decisions where spreadsheets don’t capture what matters.

64. The 10/10/10 Rule

How will I feel about this decision in 10 minutes, 10 months and 10 years?

From Suzy Welch. It separates short-term emotion from long-term consequence.

Takeaway: Useful when a decision feels emotionally charged or uncomfortable in the moment.

65. Weighted Decision Matrix

Score options against weighted criteria to compare them objectively.

List criteria (cost, security, scalability, skills fit), weight each by importance, score every option, and multiply. Standard in vendor and technology evaluations.

Takeaway: Agree the criteria and weights before scoring options, so people can’t reverse-engineer them to justify a favourite.

66. Margin of Safety

Build in a buffer between what you expect and what you can tolerate.

From Benjamin Graham (investing) and engineering, where bridges are built to carry far more than their expected load.

Takeaway: Add headroom to capacity, budgets and timelines. Your estimates are wrong; the buffer absorbs it.

67. The OODA Loop

Observe, Orient, Decide, Act, then repeat.

From US Air Force Colonel John Boyd, originally for fighter pilots. Whoever cycles through the loop faster gains the advantage.

Takeaway: In incidents and fast-moving situations, speed of iteration beats perfection of any single decision.

68. The Five Whys

Ask “why?” repeatedly (about five times) to get from symptom to root cause.

From Sakichi Toyoda and the Toyota Production System. “The service crashed” → why? → “out of memory” → why? → … → “no load testing in the release process”.

Takeaway: Use in post-incident reviews. Stop when you reach something you can fix systemically, not at “human error”.

69. The Cynefin Framework

Match your decision approach to the type of situation: clear, complicated, complex or chaotic.

From Dave Snowden. Clear: apply best practice. Complicated: analyse or ask experts. Complex: run safe-to-fail experiments. Chaotic: act first to stabilise.

Takeaway: Most architecture failures come from treating a complex problem as merely complicated, analysing when you should be experimenting.

70. Steelmanning

Argue against the strongest version of the opposing view, not the weakest.

The opposite of a straw man. If you can’t state the other side’s case so well that they’d agree with it, you don’t understand it yet.

Takeaway: In design reviews, articulate the best case for the option you’re rejecting before you reject it.

71. Disagree and Commit

Voice your disagreement fully, then commit wholeheartedly once a decision is made.

Popularised by Intel and Amazon. It avoids both endless consensus-seeking and passive-aggressive half-effort.

Takeaway: Make it safe to disagree before the decision, and expect full commitment after it.

Part 8: Cognitive Biases

72. Confirmation Bias

We seek, interpret and remember information that supports what we already believe.

One of the most robust findings in psychology. Once you favour a solution, you notice evidence for it and discount evidence against it.

Takeaway: Actively look for disconfirming evidence. Assign someone to play devil’s advocate.

73. Anchoring

The first number or idea you hear disproportionately shapes your judgment.

From Tversky and Kahneman. The first estimate thrown out in a planning session pulls every other estimate towards it.

Takeaway: Have people estimate independently before sharing (e.g. planning poker).

74. Availability Heuristic

We judge how likely something is by how easily examples come to mind.

A recent, vivid outage makes that failure mode feel more likely than it statistically is, while quieter risks get ignored.

Takeaway: Use data and base rates, not memorable anecdotes, to prioritise risks.

75. Loss Aversion & Status Quo Bias

Losses feel about twice as painful as equivalent gains feel good, so we cling to the current state.

From Kahneman and Tversky’s Prospect Theory. It’s why legacy systems survive long past their usefulness and why change proposals face extra resistance.

Takeaway: Ask “if we were starting fresh today, would we choose this?” Frame change in terms of what staying put costs.

76. Groupthink

A group’s desire for harmony overrides realistic evaluation of alternatives.

From Irving Janis, who studied the Bay of Pigs fiasco. Warning signs: no dissent, rushed consensus, deference to the most senior person.

Takeaway: Have the most senior person speak last. Collect opinions in writing before discussion.

77. Hindsight Bias & Resulting

Judging a decision by its outcome rather than by the quality of the decision at the time.

From poker player Annie Duke (“resulting”) and psychologists studying hindsight bias. Good decisions can have bad outcomes through luck, and vice versa.

Takeaway: Record decisions and their reasoning (e.g. Architecture Decision Records) so you can review the process, not just the result.

Part 9: Evidence & Reasoning

78. Hitchens’s Razor

What can be asserted without evidence can be dismissed without evidence.

From Christopher Hitchens. The burden of proof lies with whoever makes the claim, not with the sceptic.

Takeaway: When someone says “this vendor scales to millions of users”, ask for the evidence before you have to disprove it.

79. The Sagan Standard

Extraordinary claims require extraordinary evidence.

Popularised by Carl Sagan. The more a claim departs from what’s already well established, the stronger the proof it needs.

Takeaway: Be most sceptical of “10× faster, zero cost, no trade-offs” claims.

80. Falsifiability (Popper’s Principle)

A claim is only meaningful if there is some way it could be shown to be false.

From philosopher Karl Popper. “This architecture will be more flexible” can’t be tested. “This lets us add a new payment provider in under two weeks” can.

Takeaway: Turn vague goals and claims into testable statements with clear success criteria.

81. Newton’s Flaming Laser Sword (Alder’s Razor)

If something cannot be settled by experiment or observation, it isn’t worth debating.

From mathematician Mike Alder.

Takeaway: End circular design debates by building a prototype or running a benchmark.

82. Correlation Does Not Imply Causation

Two things moving together doesn’t mean one causes the other.

Both may be driven by a third factor, or the link may be coincidence. Ice-cream sales and drownings both rise in summer.

Takeaway: Before acting on a correlation in your metrics, look for confounders or run a controlled test (e.g. A/B).

83. Base Rate Fallacy

Ignoring how common something is in general when judging a specific case.

If a security alert is 99% accurate but real attacks are 1 in 10,000 events, most alerts will still be false positives.

Takeaway: Always ask “how often does this happen in general?” before reacting to a specific signal.

84. Law of Large Numbers (and the Law of Small Numbers)

Averages from large samples are reliable; small samples swing wildly.

The “law of small numbers” (Tversky and Kahneman) is our tendency to trust small samples as if they were large ones.

Takeaway: Don’t draw conclusions from one sprint, one load test or three user interviews.

85. Simpson’s Paradox

A trend that appears in several groups can reverse when the groups are combined.

Option A can beat Option B in every department separately yet lose overall, because the groups differ in size.

Takeaway: Slice your data by meaningful segments before concluding. Aggregates can mislead.

86. The McNamara Fallacy

Measuring only what is easy to measure, then treating what can’t be measured as unimportant.

Named after US Defense Secretary Robert McNamara, who judged the Vietnam War largely by body counts.

Takeaway: Not everything that counts can be counted. Keep qualitative judgment alongside dashboards.

87. The Streetlight Effect

Searching for answers where it’s easiest to look, not where they’re likely to be.

From the joke about the man looking for his keys under the streetlight because “that’s where the light is”.

Takeaway: When debugging or researching, ask whether you’re looking in the right place or just the convenient one.

88. Law of the Instrument (Maslow’s Hammer)

If all you have is a hammer, everything looks like a nail.

From Abraham Maslow and Abraham Kaplan. People apply familiar tools and methods to every problem, whether they fit or not.

Takeaway: Ask whether you’re choosing a technology because it fits or because it’s what you know.

Part 10: Risk, Behaviour & Bureaucracy

89. Law of Unintended Consequences

Actions in complex systems always have effects beyond the ones intended.

Popularised by sociologist Robert Merton. Effects can be unexpected benefits, unexpected drawbacks, or outright backfires (see the Cobra Effect).

Takeaway: Pair second-order thinking with small rollouts and monitoring to catch side effects early.

90. Law of Diminishing Returns

Beyond a point, each extra unit of input produces less additional output.

The tenth hour of analysis adds much less than the first. Going from 99.9% to 99.99% uptime costs far more than going from 99% to 99.9%.

Takeaway: Find the point where extra effort stops paying off, and stop there.

91. Fundamental Attribution Error

Blaming other people’s behaviour on their character while blaming our own on circumstances.

“He missed the deadline because he’s careless; I missed mine because requirements changed.”

Takeaway: Look at the system and context first. It pairs well with Hanlon’s Razor and blameless post-mortems.

92. The Halo Effect

One positive trait makes us rate everything else about a person or thing more highly.

A polished demo makes the whole product seem better engineered; a confident speaker seems more competent.

Takeaway: Evaluate each criterion separately, ideally before seeing the overall pitch.

93. The Framing Effect

The same information leads to different decisions depending on how it’s presented.

“90% success rate” feels very different from “10% failure rate”, even though they’re identical.

Takeaway: Re-frame important choices both ways before deciding. Be aware of how you frame proposals to others.

94. Decision Fatigue

The quality of decisions drops after a long session of making them.

Popularised by Roy Baumeister’s research. Tired people default to the easy option or the status quo.

Takeaway: Schedule important decisions early, reduce trivial ones with defaults and standards, and avoid ending long meetings with big calls.

95. Buridan’s Ass

Faced with two equally good options, being unable to choose can be worse than either.

Named after philosopher Jean Buridan: a donkey placed between two identical bales of hay starves because it can’t decide.

Takeaway: When options are genuinely close, the choice matters less than choosing. Pick one, or flip a coin.

96. Yerkes-Dodson Law

Performance improves with pressure up to a point, then declines.

From psychologists Robert Yerkes and John Dodson (1908). Some pressure sharpens focus; too much causes panic and poor judgment.

Takeaway: Avoid making major decisions in peak-stress moments, e.g. mid-incident. Stabilise first, decide later.

97. Black Swan Theory

Rare, unpredictable, high-impact events shape outcomes more than we expect, and get explained away afterwards.

From Nassim Taleb. Forecasts based on past data systematically miss them.

Takeaway: Instead of predicting black swans, build resilience: redundancy, buffers and the ability to recover.

98. The Precautionary Principle

When an action risks serious or irreversible harm, lack of certainty isn’t a reason to go ahead.

Common in environmental and health policy. Critics note that applied too broadly, it blocks all progress.

Takeaway: Apply it to one-way-door decisions involving security, privacy or citizen data. Don’t apply it to everything.

99. Pre-commitment (Ulysses Contract)

Bind your future self to a decision in advance, before temptation or pressure arrives.

From Ulysses, who had himself tied to the mast so he could hear the Sirens without steering towards them.

Takeaway: Set kill criteria for projects and stop-loss rules for investments before you start.

100. Gell-Mann Amnesia Effect

Noticing that a source is wrong about a topic you know well, then trusting it on topics you don’t.

Named by Michael Crichton after physicist Murray Gell-Mann.

Takeaway: If a source gets your area of expertise wrong, apply the same scepticism to everything else it says.

101. The Semmelweis Reflex

Rejecting new evidence because it contradicts established norms or beliefs.

Named after Ignaz Semmelweis, whose evidence that handwashing saved lives was rejected by fellow doctors.

Takeaway: When new evidence clashes with “how we’ve always done it”, examine the evidence rather than dismissing it.

102. Pournelle’s Iron Law of Bureaucracy

In any bureaucracy, the people devoted to the bureaucracy itself eventually gain control over those devoted to its goals.

From Jerry Pournelle. Process ends up serving itself rather than the mission.

Takeaway: Regularly ask whether each process, approval step or governance gate still serves the outcome it was created for (but check Chesterton’s Fence first).

Part 11: People & Behaviour

103. The Zeigarnik Effect

People remember unfinished tasks better than finished ones.

From psychologist Bluma Zeigarnik (1927), who noticed waiters remembered unpaid orders perfectly and forgot them once paid. Open loops nag at the mind until they’re closed.

Takeaway: To beat procrastination, just start (even for two minutes), and your brain will want to finish. Stop mid-task so it’s easy to resume. Write open loops down to free up mental space.

104. The Hawthorne Effect

People change their behaviour when they know they’re being observed.

From studies at Western Electric’s Hawthorne Works in the 1920s–30s: productivity rose with almost every change researchers made, partly because workers knew they were being watched.

Takeaway: Be careful interpreting results when people know they’re being measured. Use it deliberately: tracking your own habits (spending, sleep, time) tends to improve them.

105. The Hedonic Treadmill

People quickly adapt to gains and losses and return to a baseline level of happiness.

From psychologists Philip Brickman and Donald Campbell (1971). A raise, a new car or a promotion feels great for a few weeks, then becomes the new normal.

Takeaway: Don’t expect any single purchase or achievement to make you permanently happier. Invest in experiences, relationships and gratitude, which fade more slowly.

106. The Streisand Effect

Trying to hide, remove or censor information draws more attention to it.

Named after Barbra Streisand, whose 2003 lawsuit to suppress an aerial photo of her house drew hundreds of thousands of people to see it; before that, it had been downloaded six times.

Takeaway: Think twice before aggressively suppressing criticism or bad news. Transparency and a calm response usually do less damage than a cover-up.

107. The Dilbert Principle

Companies tend to promote incompetent employees into management to limit the damage they can do.

From Scott Adams (1995). A satirical cousin of the Peter Principle: instead of rising to incompetence, people are moved out of the way of real work.

Takeaway: Treat management as a skill to be developed, never as a reward or a dumping ground.

108. Amara’s Law

We tend to overestimate the effect of a technology in the short run and underestimate it in the long run.

From futurist Roy Amara. The internet was overhyped in 1999, then the dot-com crash came, yet 20 years later it had changed nearly everything. AI, blockchain and cloud have followed similar arcs.

Takeaway: Don’t get swept up in hype cycles, but don’t dismiss a technology when the hype fades. Ask where it will be in 10 years, not 1.

109. The Pygmalion Effect

Higher expectations lead to better performance.

From Robert Rosenthal and Lenore Jacobson (1968): teachers told that certain (randomly chosen) students were “about to bloom” gave them more attention, and those students improved more. Its opposite, the Golem Effect, is when low expectations drag performance down.

Takeaway: As a leader or parent, set high but credible expectations and show you believe people can meet them.

110. Social Proof

When unsure, people copy what others are doing.

From Robert Cialdini’s Influence. Busy restaurants attract more diners, “most popular” labels drive sales, and hotel guests reuse towels more when told most guests do.

Takeaway: Use it ethically to drive adoption (testimonials, “most teams use X”). Be suspicious when your own main reason for a choice is “everyone else does it”.

111. The Bystander Effect

The more people who witness a problem, the less likely any one of them is to act.

From John Darley and Bibb Latané (1968). Responsibility diffuses across the crowd: everyone assumes someone else will step in. At work, a bug that “everyone knows about” never gets fixed.

Takeaway: Assign a named owner to every problem, incident and action item. In an emergency, point at one specific person: “You, call for help.”

112. Cognitive Dissonance

Holding conflicting beliefs or actions feels uncomfortable, so people change a belief to reduce the tension, often the wrong one.

From Leon Festinger (1957). Someone who has invested heavily in a failing project convinces themselves it’s working rather than admit the mistake.

Takeaway: Notice when you’re defending something because admitting it was wrong would hurt. Make it culturally safe to say “I was wrong.”

113. The IKEA Effect

People place disproportionately high value on things they helped create.

From Michael Norton, Daniel Mochon and Dan Ariely (2011): people valued furniture they assembled themselves far more than identical pre-built pieces. It’s why teams over-value their homegrown tools and resist replacing them.

Takeaway: Involve people in shaping a change to increase buy-in. Be sceptical of your own attachment to things you built (“not invented here”).

114. The Spotlight Effect

We overestimate how much other people notice our appearance, mistakes and behaviour.

From Thomas Gilovich (2000): students made to wear an embarrassing T-shirt guessed half the room noticed; the real figure was about a quarter. Everyone is mostly thinking about themselves.

Takeaway: Don’t let fear of looking foolish stop you from asking questions, presenting or trying new things. Far fewer people are watching than you think.

115. The Baader-Meinhof Phenomenon (Frequency Illusion)

Once you notice something, you suddenly start seeing it everywhere.

Selective attention plus confirmation bias: after you buy a red car, red cars seem to be everywhere. The frequency didn’t change; your attention did.

Takeaway: Don’t mistake “I keep seeing this” for “this is becoming more common”. Check the data.

116. Hyperbolic Discounting (Present Bias)

People strongly prefer smaller rewards now over larger rewards later, more than rational planning would suggest.

Well documented in behavioural economics, e.g. by David Laibson. It’s why we skip the gym, under-save for retirement and take on tech debt.

Takeaway: Make the future reward feel present (visual progress, automation), and make the right choice the default, e.g. automatic savings or CI quality gates.

Part 12: Growth, Strategy & Systems

117. Compounding

Small, consistent gains grow exponentially over time.

Attributed to Einstein (probably wrongly) as “the eighth wonder of the world”. Getting 1% better each day makes you about 37× better in a year. It applies to money, knowledge, relationships, habits and code quality, and to debt too.

Takeaway: Favour consistent small improvements over occasional heroics. Start early, and be just as wary of compounding negatives (tech debt, bad habits, interest).

118. Theory of Constraints

Every system has one constraint (bottleneck) that limits its output; improving anything else is an illusion.

From Eliyahu Goldratt’s The Goal (1984). If testing can handle 10 features a week, writing 30 features a week just builds a pile of untested work.

Takeaway: Find the bottleneck, exploit it fully, subordinate everything else to it, then elevate it. Repeat, because the constraint moves.

119. Via Negativa

Improvement often comes from removing things, not adding them.

Popularised by Nassim Taleb. Removing a bad habit, an unnecessary meeting, a dependency or a feature often helps more than adding something new.

Takeaway: Before asking “what should we add?”, ask “what should we stop doing?” Keep a “stop doing” list alongside your to-do list.

120. Antifragility

Some things don’t just withstand stress; they get stronger from it.

From Nassim Taleb (2012). Fragile things break under stress, robust things resist it, and antifragile things improve: muscles after exercise, immune systems after exposure, and systems hardened by chaos engineering.

Takeaway: Expose yourself and your systems to small, frequent, survivable stresses (practice, game days, small experiments) instead of avoiding all volatility.

121. The Peak-End Rule

People judge an experience mostly by how it felt at its most intense point and at its end, not by the average.

From Daniel Kahneman and colleagues. A long holiday with a great final day is remembered fondly; a good meeting that ends in conflict is remembered as bad.

Takeaway: Design the peaks and endings: finish presentations, customer journeys and projects on a high note. Fix painful peaks first.

122. Tragedy of the Commons

When a resource is shared and free to use, individuals acting in their own interest overuse it until it’s ruined for everyone.

Popularised by Garrett Hardin (1968). Overfishing, traffic, a shared Slack channel full of noise, a shared cloud account with runaway costs.

Takeaway: Give shared resources owners, limits and visible costs (quotas, chargebacks, norms). Elinor Ostrom showed communities can manage commons well with clear rules.

123. The Matthew Effect (Cumulative Advantage)

Advantage begets more advantage: “the rich get richer”.

Named by sociologist Robert Merton after a Bible verse. Well-known scientists get more credit for the same work; popular products get recommended more; early wins attract more resources.

Takeaway: Early momentum matters disproportionately, so get small wins early. When judging, correct for reputation, not just results.

124. The Bus Factor

The number of people who would have to disappear before a project stalls.

A team where only one person understands the billing system has a bus factor of one, which is a serious risk regardless of how good that person is.

Takeaway: Spread knowledge through pairing, documentation, code review and rotation. Aim for a bus factor of at least two on anything critical.

125. Ashby’s Law of Requisite Variety

To control a system, the controller must have at least as much variety (options) as the system it’s controlling.

From cybernetician W. Ross Ashby (1956). A rigid rulebook can’t govern a complex, changing environment, and a single playbook can’t handle every incident.

Takeaway: Match the flexibility of your response to the complexity of the problem. Empower front-line people to adapt instead of trying to script every case.

126. Moore’s Law

The number of transistors on a chip doubles roughly every two years.

From Intel co-founder Gordon Moore (1965, revised 1975). It drove 50 years of exponentially cheaper computing, and is now slowing as physics limits approach.

Takeaway: Expect what’s expensive today to be cheap tomorrow, and design for the costs of the future, not the present. Don’t count on it continuing for ever.

127. The Shirky Principle

Institutions will try to preserve the problem to which they are the solution.

From Clay Shirky. A tax-prep company lobbies against simpler tax filing; a consulting team benefits from a system staying complex.

Takeaway: When asking a group how to solve a problem, consider whether they’d be out of a job if it were solved. Look for incentive conflicts.

128. The Overton Window

The range of ideas considered acceptable at a given time, which can shift.

From Joseph Overton. Ideas move from “unthinkable” to “radical” to “acceptable” to “policy”. Advocates often push extreme positions to make moderate ones look reasonable.

Takeaway: To drive change, shift what’s discussable step by step. Notice when someone is deliberately stretching the window in a negotiation.

129. Sutton’s Law

Go where the money is: when diagnosing, consider the most likely cause first.

Named after bank robber Willie Sutton, who supposedly said he robbed banks “because that’s where the money is”. Medical students are taught it as “when you hear hoofbeats, think horses, not zebras.”

Takeaway: Look in the most probable places first when debugging, selling or researching. It pairs naturally with Occam’s Razor and the Streetlight Effect.

130. Benford’s Law

In many real-world data sets, the leading digit is 1 about 30% of the time, and 9 less than 5% of the time.

Observed by Frank Benford (1938) across populations, prices, river lengths and financial accounts. Made-up numbers usually have too even a spread of leading digits.

Takeaway: Used by auditors and fraud investigators to flag suspicious data. If a data set should follow it and doesn’t, look closer.

Part 13: Thinking Methods

131. First Principles Thinking

Break a problem down to its fundamental truths, then reason up from there instead of reasoning by analogy.

Going back to Aristotle and popularised by Elon Musk. Reasoning by analogy says “batteries cost $600/kWh because they always have.” First principles asks “what are batteries made of, and what do those materials cost?” The answer was about $80/kWh, which opened the door to much cheaper batteries.

Takeaway: When you’re told “that’s just how it’s done”, list the assumptions, challenge each one, and keep only what’s actually true. Save it for important problems, because it’s slow; analogy is fine for everyday decisions.

132. Socratic Questioning

Test an idea by asking disciplined, probing questions rather than asserting answers.

From Socrates’ method of dialogue. The core questions: What exactly do you mean? How do you know? What’s the evidence? What are you assuming? What would someone who disagrees say? What follows if that’s true?

Takeaway: Use it on your own beliefs before using it on others. In reviews and coaching, ask questions that help people find the flaws themselves instead of just pointing them out.

133. The Principle of Charity

Interpret other people’s arguments in their most reasonable, rational form before responding.

A foundation of good-faith philosophy and debate. If a colleague says “this design won’t scale”, assume they mean something specific and sensible, and ask what, rather than assuming they’re being negative. Steelmanning (#70) is this principle put into action.

Takeaway: Before disagreeing, restate the other person’s point in a way they’d agree with: “So your concern is…?” Most arguments shrink once both sides feel understood.

134. The Ladder of Inference

We climb from raw data to conclusions in rapid, invisible steps: observe → select → interpret → assume → conclude → believe → act.

From Chris Argyris, popularised in Peter Senge’s The Fifth Discipline. A colleague checks their phone during your presentation; you select that detail, interpret it as boredom, assume they don’t respect you, and conclude they’re against your proposal, all within seconds.

Takeaway: When you feel certain about someone’s motives, climb back down: “What did I actually observe? What else could explain it?” Share your reasoning steps, not just your conclusions.

135. Scout Mindset

Aim to see things as they are, not as you wish they were.

From Julia Galef (2021). The “soldier mindset” defends beliefs like territory; the “scout mindset” explores to map the terrain accurately, even when the truth is uncomfortable.

Takeaway: Ask “Is it true?” instead of “Can I believe this?” or “Must I believe this?”. Treat changing your mind as a win, not a loss, and reward others for doing the same.

136. Red Teaming

Assign a person or group to deliberately attack a plan, argument or system to find its weaknesses.

From military and security practice: a “red team” plays the adversary. Used in penetration testing, war-gaming, strategy reviews and intelligence analysis. It structures dissent so it isn’t left to chance.

Takeaway: Before committing to a major plan, ask someone (ideally outside the team) to try to break it. Rotate the role so dissent isn’t tied to one person’s reputation.

137. The Pre-mortem

Before starting, imagine the project has already failed, then work out why.

From psychologist Gary Klein. Telling people “it failed” (rather than “what might go wrong?”) makes it safe to raise doubts and improves the identification of risks by about 30% in research.

Takeaway: At kickoff, give everyone 5 minutes to write down reasons the project failed, then share and address the top risks. It’s Inversion (#30) applied to a specific plan.

Part 14: Logical Fallacies

138. Ad Hominem

Attacking the person making an argument instead of the argument itself.

“Why listen to her views on security? She’s only been here six months.” Her tenure has nothing to do with whether her point is correct.

Takeaway: Separate the message from the messenger. Ask “Is the argument right?” regardless of who made it. (Relevant conflicts of interest are worth noting, but they don’t refute the argument.)

139. Straw Man

Misrepresenting someone’s argument as a weaker or more extreme version, then attacking that.

“We should add more tests.” → “So you want us to spend all our time writing tests and never ship anything?”

Takeaway: Restate the other person’s position accurately before responding. If someone straw-mans you, calmly restate your actual position.

140. False Dilemma (False Dichotomy)

Presenting only two options when more exist.

“Either we rewrite the whole system or we live with the bugs forever.” Incremental refactoring, fixing the worst modules or replacing one component at a time are all options too.

Takeaway: When you’re offered an either/or, ask “What are the other options?” There are almost always more than two, including combinations and doing nothing for now.

141. Slippery Slope

Claiming that one small step will inevitably lead to a chain of extreme consequences, without evidence for each link.

“If we let one team work from home on Fridays, soon nobody will come to the office and the company culture will collapse.”

Takeaway: Ask for evidence of each step in the chain. Some slopes are real, so judge each link on its merits rather than accepting or dismissing the whole chain.

142. Appeal to Authority

Treating a claim as true because an authority figure said it, rather than because of the evidence.

“Our CEO says microservices are the future, so we’re migrating everything.” Expert opinion is useful evidence, but it’s a fallacy when the authority is outside their field or when the evidence points the other way.

Takeaway: Ask whether the person is an expert in this specific area and whether experts generally agree. Then look at the reasoning, not just the title.

143. Post Hoc Ergo Propter Hoc

“After this, therefore because of this”: assuming that because B followed A, A caused B.

“We launched the new homepage and sales went up 10%, so the homepage worked.” It might be seasonal, a competitor outage or a marketing campaign.

Takeaway: Ask what else changed at the same time. Use control groups or A/B tests before claiming credit. It’s the time-based version of Correlation ≠ Causation (#82).

144. Circular Reasoning (Begging the Question)

Using the conclusion as one of the premises.

“This framework is the best because it’s superior to all the others.” Or “We can trust this source because it says it’s trustworthy.”

Takeaway: Ask “What’s the independent evidence?” If removing the conclusion leaves no supporting reason, the argument is circular.

145. Appeal to Nature

Assuming something is good because it’s “natural”, or bad because it’s “unnatural”.

“This supplement is all-natural, so it’s safe.” Arsenic and hemlock are natural too; many synthetic medicines save lives.

Takeaway: Judge things on evidence about their effects, not on whether they’re natural, traditional or “how things have always been done”.

146. No True Scotsman

Protecting a generalisation from counterexamples by redefining the group.

“No real engineer would use a low-code tool.” → “But our best engineer does.” → “Well, then she’s not a real engineer.”

Takeaway: If a claim can be rescued from any counterexample by shifting definitions, it isn’t saying anything (see Falsifiability, #80). Define terms before the debate starts.

147. Texas Sharpshooter Fallacy

Cherry-picking clusters in random data and treating them as meaningful, like firing at a barn and then painting a target around the tightest group of holes.

“Look, three of our biggest customers who churned all had the same account manager!” Out of hundreds of customers, some clusters will appear by chance.

Takeaway: Form your hypothesis before looking at the data, then test it. Be wary of patterns discovered after the fact in large data sets.

148. The Gambler’s Fallacy

Believing that past independent random events affect future ones.

“Red has come up five times in a row, so black is due.” Each spin of the roulette wheel is independent. In the 1913 Monte Carlo casino, black came up 26 times in a row and gamblers lost millions betting on red.

Takeaway: For independent events, the past doesn’t change the odds. Check whether events are really independent before reasoning about “streaks” (and for dependent ones, see Regression to the Mean, #55).

Part 15: More Cognitive Biases

149. Overconfidence Bias

We are more confident in our judgments than their accuracy justifies.

In studies, when people say they’re “99% sure”, they’re wrong far more than 1% of the time. Around 90% of drivers rate themselves above average. It drives failed acquisitions, blown budgets and risky bets.

Takeaway: Express estimates as ranges with confidence levels (“70% sure it’s between 4 and 8 weeks”) and track how often you’re right. Calibration improves with feedback.

150. Optimism Bias

We believe we’re less likely than others to experience bad outcomes.

From Tali Sharot’s research. Most people think they’re less likely than average to get divorced, have an accident or see their project fail. It’s a key driver of the Planning Fallacy (#51).

Takeaway: Keep the motivation of optimism, but plan with realism: use base rates, pre-mortems and margins of safety for anything important.

151. The Curse of Knowledge

Once you know something, it’s hard to imagine not knowing it.

From a 1990 Stanford study: people tapping a song’s rhythm predicted listeners would guess the song 50% of the time; they guessed 2.5%. Experts write documentation full of jargon and skipped steps because it’s “obvious”.

Takeaway: Test explanations on a real beginner. Use concrete examples, define terms and resist skipping steps. Onboarding docs should be written or reviewed by new joiners.

152. Recency Bias

Giving too much weight to recent events and too little to earlier ones.

Annual performance reviews dominated by the last month; investors piling into whatever rose last quarter; a team rewriting its whole process after one bad sprint.

Takeaway: Keep running notes and records (decision logs, brag documents, incident histories), and look at the long-term trend before reacting to the latest data point.

153. Bias Blind Spot

Recognising cognitive biases in others while believing you’re less affected yourself.

From Emily Pronin’s research (2002). Most people rate themselves as less biased than average. Ironically, being smart or knowing about biases doesn’t reduce it; it can make it worse.

Takeaway: Don’t rely on willpower to avoid bias. Use processes instead: checklists, independent estimates, devil’s advocates, blind reviews and decision records.

154. The Bandwagon Effect

Adopting beliefs or behaviours because many others have, regardless of the evidence.

Technology hype cycles, investment bubbles and “everyone is using framework X”. Related to Social Proof (#110), but focused on beliefs spreading through a group. As a logical fallacy it’s called argumentum ad populum: “millions of people can’t be wrong.”

Takeaway: Ask “Would I choose this if nobody else were doing it?” Popularity is a signal worth noticing, not proof.

155. Choice-Supportive Bias

After making a choice, we remember it as better than it was and the alternatives as worse.

You buy laptop A over laptop B and soon recall A’s strengths and B’s flaws more vividly than you did when deciding. It makes us poor judges of our own past decisions.

Takeaway: Write down your reasoning and expectations at the time of a decision (a decision journal), then review honestly later. Pairs with Hindsight Bias (#77).

Part 16: Learning, Mastery & Estimation

156. The Feynman Technique

If you can’t explain something simply, you don’t understand it yet.

Named after physicist Richard Feynman. Four steps: (1) pick a concept, (2) explain it in plain language as if teaching a 12-year-old, (3) notice where you get stuck or reach for jargon, which is where your gaps are, and (4) go back to the source, then simplify again.

Takeaway: After reading or watching something, close it and explain it out loud or on paper. Teaching others is one of the fastest ways to learn. Pairs with the Curse of Knowledge (#151).

157. Spaced Repetition (and the Forgetting Curve)

We forget most new information within days unless we review it at increasing intervals.

Hermann Ebbinghaus (1885) showed memory decays sharply after learning: without review, much of it is gone within a day or two. Reviewing just as you’re about to forget (after 1 day, 3 days, a week, a month…) makes memories last far longer with less total effort than cramming.

Takeaway: For anything you want to remember long-term (languages, exam material, key concepts), use flashcard apps like Anki or a simple review schedule. Test yourself rather than re-reading; active recall beats passive review.

158. Deliberate Practice

Expertise comes from focused practice on specific weaknesses with immediate feedback, not just from time spent.

From psychologist Anders Ericsson’s research on experts. The popular “10,000-hour rule” misreads it: 10,000 hours of comfortable repetition makes you experienced, not excellent. Deliberate practice is uncomfortable by design: it works at the edge of your ability.

Takeaway: Break skills into components, practise the weakest one, get fast feedback (a coach, tests, recordings), and repeat. If practice feels easy, you’ve probably stopped improving.

159. Fermi Estimation

Estimate an unknown quantity by breaking it into smaller pieces you can reasonably guess, then multiplying.

Named after physicist Enrico Fermi, who famously asked students “How many piano tuners are there in Chicago?” Population ≈ 3M → ~1M households → maybe 1 in 20 has a piano → 50,000 pianos → tuned once a year → a tuner does ~1,000 a year → about 50 tuners. Errors in each guess tend to cancel out, so the answer is often in the right ballpark.

Takeaway: Use it for quick sanity checks: market sizes, capacity planning, costs, “is this claim even plausible?”. Getting within a factor of 2–3 in five minutes beats having no number at all.

Part 17: Strategy, Games & Incentives

160. The Prisoner’s Dilemma (Game Theory)

Two parties each acting in their own rational self-interest can end up worse off than if they had cooperated.

Formalised at RAND in 1950. Two suspects are questioned separately: if both stay silent, both get light sentences; if one betrays the other, the betrayer goes free; if both betray, both get heavy sentences. Betrayal is individually “safe”, so both betray and both lose. It explains price wars, arms races and teams hoarding information. In Robert Axelrod’s tournaments of the repeated game, the simple strategy tit-for-tat (cooperate first, then copy what the other side did last) won.

Takeaway: In repeated relationships, start by cooperating, respond in kind, forgive quickly and be predictable. Build structures (contracts, reputation, shared goals) that make cooperation the rational choice.

161. Comparative Advantage

Even if you’re better at everything, you gain by focusing on what you’re relatively best at and trading for the rest.

From economist David Ricardo (1817). A lawyer who types faster than their assistant should still let the assistant type, because each hour the lawyer spends typing costs a billable hour of legal work. It’s the foundation of trade, delegation and specialisation.

Takeaway: Delegate tasks you’re good at but that aren’t your highest-value use of time. On teams, assign work by relative strengths, not just absolute skill. Pairs with Opportunity Cost (#57).

162. Skin in the Game

Don’t trust advice or decisions from people who don’t bear the consequences of being wrong.

Popularised by Nassim Taleb (2018), echoing Hammurabi’s Code: if a house collapses and kills its owner, the builder is put to death. Advisers paid regardless of outcome, managers rewarded for short-term gains, and consultants who leave before results arrive all have asymmetric risk: upside for them, downside for you.

Takeaway: Ask “What happens to this person if they’re wrong?” Prefer advisers and partners who share the downside. Align incentives so decision-makers own the consequences.

163. The Peltzman Effect (Risk Compensation)

When people feel safer, they take more risks, partly offsetting the safety gain.

From economist Sam Peltzman (1975), who argued that car safety regulations led some drivers to drive less carefully. Similar effects appear with helmets, ABS brakes and backups (“we have backups, so we can deploy without testing”).

Takeaway: When adding safety measures, watch for behaviour changing to use up the margin. Pair safety nets with norms that keep people careful. Don’t let a backup become an excuse.

164. The Lucas Critique

Relationships observed in past data can break down as soon as you base policy on them, because people adapt to the new policy.

From economist Robert Lucas (1976), originally aimed at macroeconomic models. A historical link between inflation and unemployment fell apart once governments tried to exploit it, because people changed their expectations. It’s a broader cousin of Goodhart’s Law (#7).

Takeaway: When designing a rule, incentive or model, ask “How will people change their behaviour once this is in place?” Past behaviour under the old rules doesn’t predict behaviour under the new ones.

165. Parkinson’s Law of Bureaucratic Growth

Bureaucracies grow at a steady rate regardless of how much work there is to do.

From C. Northcote Parkinson’s original 1955 essay: the British Admiralty’s staff kept growing while the number of ships and sailors fell. His two drivers: “An official wants to multiply subordinates, not rivals” and “Officials make work for each other.” He estimated growth of about 5–7% a year whatever the workload.

Takeaway: Periodically justify headcount, roles and processes from zero rather than from last year’s baseline. Measure organisations by outcomes, not size. Pairs with Pournelle’s Iron Law (#102).

Part 18: Habits, Productivity & Wellbeing

166. The Two-Minute Rule

If a task takes less than two minutes, do it now. When starting a new habit, scale it down to something that takes two minutes.

The first version comes from David Allen’s Getting Things Done: tracking a tiny task takes more effort than doing it. The second comes from James Clear’s Atomic Habits: “read 30 books a year” becomes “read one page”; “go running” becomes “put on running shoes”.

Takeaway: Clear small tasks immediately to stop them piling up. For new habits, make starting ridiculously easy; once you’ve started, continuing is easier (see the Zeigarnik Effect, #103).

167. The Habit Loop

Every habit follows a loop: cue → craving → response → reward.

From Charles Duhigg’s The Power of Habit (cue, routine, reward), extended by James Clear. Phone buzzes (cue) → curiosity (craving) → check it (response) → novelty (reward). Repeat enough and it becomes automatic.

Takeaway: To build a good habit, make it obvious, attractive, easy and satisfying. To break a bad one, invert each: make it invisible, unattractive, difficult and unsatisfying. Change the cue or the environment rather than relying on willpower.

168. Deep Work

The ability to focus without distraction on cognitively demanding tasks is increasingly rare and increasingly valuable.

From Cal Newport (2016). Research by Sophie Leroy on “attention residue” shows that switching tasks leaves part of your mind on the previous one, so constant checking of email and chat degrades the quality of everything you do.

Takeaway: Block 1–4 hour stretches for focused work, with notifications off. Batch shallow work (email, admin) into set windows. Treat focus as a skill you train.

169. The Paradox of Choice

Beyond a point, more options make people less satisfied and less likely to choose at all.

From psychologist Barry Schwartz (2004). In a well-known study by Sheena Iyengar and Mark Lepper, shoppers offered 24 jams were far less likely to buy than those offered 6 (later replications show the effect varies by context). More options raise expectations and regret.

Takeaway: Limit options for yourself and others: shortlists, sensible defaults, curated choices. Combine with Satisficing (#62) and Hick’s Law (#6).

170. Hormesis

Small doses of stress make you stronger; large or constant doses harm you.

From biology and toxicology: “the dose makes the poison” (Paracelsus). Exercise, cold exposure and challenging work are beneficial stressors when followed by recovery. Burnout is what happens when stress becomes chronic and recovery disappears. It’s the personal side of Antifragility (#120).

Takeaway: Stress + rest = growth. Seek regular, manageable challenges, but protect sleep, breaks and time off just as deliberately. Pairs with the Yerkes-Dodson Law (#96).

Part 19: Niche but Useful

171. The Second-System Effect

The second system someone designs is the most dangerous one, because they pack in every idea they held back the first time.

From Fred Brooks’s The Mythical Man-Month (1975). After a lean, successful first version, designers feel confident and over-engineer the sequel. Big rewrites (“v2 will fix everything”) are the classic case.

Takeaway: Be most disciplined about scope on the second version. Ask of every addition: “Did real users need this in v1?” Prefer incremental evolution over grand rewrites (see Gall’s Law, #13).

172. Eagleson’s Law

Any code of your own that you haven’t looked at for six months might as well have been written by someone else.

Attributed to Peter Eagleson. Context, intent and clever shortcuts fade from memory surprisingly fast.

Takeaway: Write code, notes and documents for a stranger, because future-you will be one. Explain the why in comments and commit messages, not just the what.

173. Greenspun’s Tenth Rule

Any sufficiently complicated program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp.

From Philip Greenspun (there are no rules one to nine). The broader point: complex systems tend to reinvent general-purpose platforms (scripting engines, rules engines, config languages) badly.

Takeaway: When your configuration starts growing loops, conditionals and variables, stop. Use an established language, framework or engine instead of growing your own.

174. Dunbar’s Number

Humans can maintain only about 150 stable social relationships.

From anthropologist Robin Dunbar (1990s), based on primate brain size. Relationships form layers of roughly 5 (closest), 15, 50, 150 and 500. Military units, villages and some companies (e.g. Gore-Tex capping sites at about 150 people) mirror these sizes.

Takeaway: Expect culture and communication to change as a group crosses about 15, 50 and 150 people. Split teams and sites before they get too large to know each other.

175. The Ringelmann Effect (Social Loafing)

As a group gets bigger, each member’s individual effort tends to drop.

From French engineer Max Ringelmann (1913), who found that people pulling a rope in a group pulled less hard per person than when pulling alone. Later research named it “social loafing”: when individual contribution is invisible, effort falls.

Takeaway: Keep teams small, make individual contributions visible and give each person clear ownership. Pairs with the Bystander Effect (#111) and Brooks’s Law (#11).

176. Putt’s Law

“Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.”

From Putt’s Law and the Successful Technocrat (1981), written under the pseudonym Archibald Putt. Tongue-in-cheek, but it captures a real gap between technical and managerial knowledge.

Takeaway: Managers of technical work should invest in understanding it; technical experts should learn the business context. Build bridges, such as tech leads and engineering managers who stay close to the work.

177. Braess’s Paradox

Adding capacity to a network can make overall performance worse.

From mathematician Dietrich Braess (1968). When each driver picks the route that’s best for them, a new shortcut can attract so much traffic that everyone’s journey gets slower. Real cases: closing roads in Seoul (the Cheonggyecheon highway removal) and New York’s 42nd Street improved traffic flow.

Takeaway: In networks, systems and organisations, more isn’t automatically better. Test the effect of adding a route, server, channel or team on the whole system, not just locally.

178. Gresham’s Law

“Bad money drives out good.”

Named after Sir Thomas Gresham (16th century). When debased coins and full-value coins must be accepted at the same value, people hoard the good ones and spend the bad ones, so only bad money circulates. More broadly, when good and bad behaviour are rewarded equally, bad drives out good: low-quality content crowds out high-quality, and cutting corners crowds out diligence.

Takeaway: Make sure quality is visible and rewarded. If doing the right thing costs more but pays the same, expect people to stop doing it.

179. Baumol’s Cost Disease

Services that can’t easily become more productive get steadily more expensive relative to everything else.

From economists William Baumol and William Bowen (1960s). A string quartet needs the same four players and the same time as in 1800, but musicians’ wages must keep pace with industries whose productivity has soared. It’s why education, healthcare and live services grow costlier while electronics get cheaper.

Takeaway: Expect people-intensive costs (training, support, consulting, care) to rise faster than inflation. Look for where technology can augment them, and budget accordingly.

180. The Winner’s Curse

In a competitive auction, the winner usually overpays.

First described by oil engineers Capen, Clapp and Campbell (1971) studying lease bids, and later popularised by Richard Thaler. If many bidders estimate an uncertain value, the winner is usually the one who overestimated it most.

Takeaway: In bidding wars (acquisitions, hiring, property, contracts), assume winning means you were probably the most optimistic. Set a walk-away price beforehand (see Pre-commitment, #99).

181. The Wisdom of Crowds

The averaged judgment of a diverse, independent group often beats individual experts.

In 1906 Francis Galton found that the median of about 800 fairground guesses at an ox’s weight was within 1% of the truth. James Surowiecki (2004) set out the conditions: diversity, independence, decentralisation and a way to aggregate. Remove independence and you get groupthink or bubbles instead.

Takeaway: Collect estimates and opinions independently before discussion (see Anchoring, #73, and Groupthink, #76), then combine them. A crowd is only wise if its members don’t copy each other.

182. The Motte-and-Bailey Fallacy

Defending a bold, controversial claim by retreating to a modest, obvious one when challenged, then returning to the bold claim once the challenge passes.

Named by philosopher Nicholas Shackel (2005) after a medieval castle: the comfortable bailey is hard to defend, so you retreat to the fortified motte when attacked. “Agile means no documentation!” → challenged → “I just mean we value working software” → later → “So, no documentation.”

Takeaway: When someone’s claim shifts under pressure, pin down which version they’re arguing for, and hold them to it.

183. Mental Accounting

People treat money differently depending on which mental “account” it belongs to, even though money is interchangeable.

From economist Richard Thaler. People splurge a tax refund or bonus while carrying expensive credit card debt, or drive across town to save $10 on a $30 item but not on a $1,000 one.

Takeaway: A dollar is a dollar. Judge spending by total value and opportunity cost (#57), not by which budget it comes from. In organisations, watch for “use it or lose it” budget spending.

184. The Decoy Effect (Asymmetric Dominance)

Adding a clearly inferior third option makes one of the original options look more attractive.

Dan Ariely’s classic example from The Economist: web-only $59, print-only $125, print + web $125. Almost nobody chose print-only, but its presence pushed most people to print + web. Without the decoy, most chose web-only.

Takeaway: Recognise it on pricing pages and in proposals, and evaluate options on their own merits. Used ethically, it can steer people toward a genuinely better default.

185. The Endowment Effect

We value things more simply because we own them.

From Kahneman, Knetsch and Thaler (1990): people given a mug demanded roughly twice as much to sell it as others were willing to pay to buy one. It’s related to Loss Aversion (#75) and the IKEA Effect (#113).

Takeaway: When deciding whether to keep something (a tool, a project, a possession), ask “Would I buy this today at this price?” If not, consider letting it go.

186. The Benjamin Franklin Effect

People tend to like you more after they’ve done you a favour.

Benjamin Franklin won over a hostile fellow legislator by asking to borrow a rare book from him; the man became a lifelong friend. Cognitive Dissonance (#112) explains it: “I helped them, so I must like them.”

Takeaway: To build a relationship with a sceptic, ask for a small favour or their advice. People invest in what they’ve contributed to.

187. The Pratfall Effect

Competent people become more likeable after making a small mistake.

From Elliot Aronson (1966): listeners rated a highly competent quiz contestant as more likeable after he clumsily spilled coffee. The effect only works if competence is already established; for someone seen as average, the mistake lowers their rating.

Takeaway: You don’t need to appear flawless. Admitting small mistakes makes strong performers more approachable and trustworthy.

188. Flow

Peak focus and enjoyment happen when a task’s challenge closely matches your skill.

From psychologist Mihaly Csikszentmihalyi (1990). Too easy causes boredom; too hard causes anxiety. In between, with clear goals and immediate feedback, people lose track of time and do their best work.

Takeaway: Adjust tasks to stay in the channel: add constraints or ambition when bored, break things down or get help when overwhelmed. Protect flow with Deep Work habits (#168).

189. Grey’s Law

“Any sufficiently advanced incompetence is indistinguishable from malice.”

A play on Arthur C. Clarke’s third law, and the counterweight to Hanlon’s Razor (#3). At some point, the effect of repeated carelessness is the same as sabotage, whatever the intent.

Takeaway: Assume good intent first, but judge patterns by their impact. If the same “honest mistake” keeps causing harm, address it as seriously as if it were deliberate.

Quick Reference