Algorithms to Live By Brian Christian and Tom Griffiths

Say you’re looking for a soulmate – When do you know it is the right time to stop looking and just commit to someone?

Or for that matter when is the right time to stop looking for an apartment to rent and just go with one?

Or when is the right time to stop test driving cars and just buy one already?

Or when is the right time to stop looking for the best parking spot and park in one that is available?

Problems like these are called “optimal stopping problems“.

Naturally the trade-off here is that the longer you wait the more your chances of getting a better deal, but that better deal may never come and you’d have passed up a good deal (and a good deal of time) waiting for a better one.

You can apply the 37% rule over the number of options you have or over the amount of time you have – it works in both cases.

So, what is the best approach here? It is to “look-then-leap“, that is, you first evaluate your options without committing to any of them (“look”), and after that commit (“leap”) to the first option that meets your criteria or is the best among what you’ve seen till now.

How long should you look before you leap? Look at 37% of the options without committing. After that commit to the first option that exceeds the quality of everything you’ve seen during the initial 37% and/or meets your criteria.

For example:

• If you’re interviewing 10 candidates, you should evaluate the first 3 or 4 (roughly 37%) without hiring. Then, hire the first candidate who is better than those initial 3 or 4.
• If you’re considering 20 apartments, you should explore the first 7 without deciding. Then, pick the next one that’s better than all 7.
• If you want to park your car in a parking lot having, say, 100 spaces. You’d start by driving around and examine the first 37 spaces without parking, simply observing their distance from your destination. After that, you’d park in the next spot that’s closer than any of those 37.

Variations to the 37% rule

The classic version of optimal stopping problem assumes that you cannot revisit your choices – once you pass on an option, it’s gone for good – you can’t go back and choose it later.

This assumption reflects real-world scenarios where opportunities expire, like a job candidate accepting another offer or an apartment getting rented to someone else.

But there are other real-world scenarios where you can actually revisit past options – like dating or online shopping for example.

In cases where you can revisit past options – Look for 61% of the time/at 61% of the options before committing.

And in cases where you can be rejected yourself by the other party – commit sooner. Look for only 25% of the time/at 25% of the options before committing.

And in cases where you have pre-determined criteria of performance (such as standardised test scores like the CAT or the SAT), then look for 58% of the time/at 58% of the options before committing.

The authors also talk about cases where waiting has a cost such as when we want to sell our apartment and waiting another month for a better deal will mean paying maintenance charges for the building.

“This principle applies to any situation where you get a series of offers and pay a cost to seek or wait for the next.“.

Imagine you’re in a casino, faced with a row of slot machines (a.k.a. “one-armed bandits”). Each machine has a lever and a different, unknown chance of giving you a reward (a jackpot). Your goal is to figure out which machine is the best one to play in order to maximise your total winnings.

The catch is you don’t know the payout rates of the machines upfront, and each pull of a lever costs you time and money. So, you have to balance:

1. Exploration: Trying out different machines to gather information about their payout rates.
2. Exploitation: Playing the machine that seems to have the highest payout so far to maximise your rewards.

The dilemma is how to allocate your attempts between exploring new options and exploiting the best one you’ve found. If you explore too much, you waste time on low-reward machines. If you exploit too soon, you might miss out on finding a better machine.

This is known as the “multi-armed bandit problem” and has real-life applications like:

• Online Advertising: Choosing which ads to show users to maximise clicks.
• Clinical Trials: Testing different treatments to identify one most effective.
• Investment Strategies: Allocating resources across investments to maximise returns.

While the “optimal stopping problem” is about when to make the one and only decision to stop, the “multi armed bandit problem” is about where to allocate your energy, time, and resources in cases where you have to make a decision multiple times.

And it’s not as simple as going with the option with the higher expected value (EV).

For example, say you’re deciding where to eat lunch and nearby are three restaurants:

1. Restaurant A – You have been here 15 times and liked the food 9 times (i.e. 60% EV
2. Restaurant B – You have been here only twice and liked the food just once (i.e. 50% EV).
3. Restaurant C – You’ve never been here (can’t calculate EV).

So, do you go ahead and eat at Restaurant A? Not necessarily.

While Restaurant A has a higher expected value (60%), it’s also much better known to you, leaving less uncertainty.

Restaurant B, despite its lower expected value (50%), has been tried far fewer times and Restaurant C has not been tried even once – both having room for exploration and the possibility of being better than the numbers currently suggest.

This decision is about weighing risk and potential reward.

So, how do you decide when to pivot from exploring to exploiting and vice versa?

It all depends on your interval – that is, the time you available to enjoy the benefits of exploration. Naturally, if you do not have a lot of time to enjoy the potential gains from exploring new options then might as well stick to the tried and true.

This is why old people prefer the classics while the younger generation is always on the lookout for something new.

“So explore when you will have time to use the resulting knowledge, exploit when you’re ready to cash in. The interval makes the strategy.“

If one does not explore and decides to exploit early it may result in suboptimal outcomes over the interval.

Using the Gittins Index

The Dynamic Allocation Index (a.k.a. Gittins Index) helps us decide when to prefer giving the benefit of the doubt and when to not (i.e. when to explore further versus when to trust what you already know).

It is based on the foundational assumption that the value of something tomorrow is less than the value of something today (called the geometric discount factor, β, but that is getting too much in the weeds).

Practical enough.

Like the value of a good meal tomorrow is “X”% of the value of a good meal today. For a younger person this will be a higher, say 90%, while for a older person it will be lower, say 60%, because the time they have left to enjoy the benefits of exploring is less and they’d rather have the good meal now.

The Gittins Index is essentially a measure of the potential reward of continuing to explore an option balanced against the cost of doing so.

It assigns a “score” to each option based on:

1. The known reward so far.
2. The uncertainty around it.
3. The time horizon you have left to benefit from further exploration.

If an option has high uncertainty but some evidence of good results, the Gittins Index may suggest giving it another try—especially if your time horizon allows for further exploration.

This reflects the potential for uncovering untapped value.

If the Gittins Index of your “tried-and-true” option becomes significantly higher than the uncertain option’s index, it’s time to stop exploring and commit to exploitation.

This ensures you’re maximising rewards with minimal risk.

Reading a Gittins Index table (and choosing a place for lunch)

Continuing the restaurant example from above – assume that good meal tomorrow is worth 90% of a good meal to you today.

Conveniently, the authors have provided us with a table of Gittins Indices at 90% payoff value.

Do you have something simpler?

The problem with the Gittins Index is that it is hard to calculate (and not just because you don’t know with how much more something matters to you today versus tomorrow).

So what to do? A simpler solution comes in the form of Upper Confidence Bounds (UCB). Let me explain how it works by taking you to an (imaginary) ice cream shop where you get to choose from a variety of flavours you’ve never had before. Your goal is to find out the flavour you like best and have the most of it.

1. Start by trying everything: You take a small bite of each flavour to get an idea of what you like. At this point, you’re exploring all the options.
2. Keep track of what you like: As you try more flavours, you keep a record of how much you liked each one. For example, chocolate was a 9/10 and strawberry an 8/10.
3. Consider the uncertainty: Since you’ve only tried each flavour once, you might not have a full picture yet. What if the chocolate bite was unusually good, or the strawberry bite was unusually bad? UCB gives higher “confidence” to flavours that you haven’t tried much, so you’re encouraged to revisit them.
4. Pick the one with the best balance:
   • How much you’ve liked a flavour so far (the score it has) versus How much you still don’t know about it (how many times you’ve tried it).
   • For example, if you had chocolate 10 times and liked it every time, it’s a strong favourite. But if you’ve only had strawberry once and thought it was okay, try it again to make sure you’re not missing out on something great.
5. Focus on the best: Over time, as you try each flavour more and more, you become more confident in which is the best. Eventually, start eating only your favourite (exploitation).

Being able to rank (i.e. sort) things properly is very important – for example if the Google Search algorithm only did the searching part and not rank query results basis relevance to you then it would not be very useful.

Sometimes we use the ranking (sorting) algorithm to achieve an end result (e.g., sorting files in a computer’s memory for quick retrieval later) – Here we need to consider the trade-off between the time it takes to sort the data set versus the time it takes to get the result from it.

The authors explain how the Big-O notation helps calculate how long the sorting process will take as the dataset grows larger and rules of sorting grow more complex (linear, quadratic, logarithmic, exponential).

They further dive into Bubble Sort, Insertion Sort, Mergesort, Bucket Sort, algorithm robustness, noise/noisy comparator.

If you’re Google then it makes sense for you know all this to sort and rank your data beforehand, so that when the user types in their query you can search the database faster and return them the results quickly.

But for practical life, sorting just isn’t worth it.

Mostly there simply isn’t enough scale to justify the extra effort in sorting the data – searching would just be faster. “… ordering your bookshelf will take more time and energy than scanning through it ever will.“.

Sometimes however (and more relevant to real life IMO), the ranking itself is the end goal (e.g., how leaderboards are calculated in sports tournaments) – Here we need to consider the fairness of the algorithm.

An unfair algorithm would be one like Single Elimination in tennis while a fair algorithm would be the Round Robin.

One more thing: Think whether the game you’re playing relies more on ordinal ranking or cardinal ranking. When you are competing against a benchmark (say, running a marathon in 2 hours) then it is easier to focus and plan than when you are competing against a revolving door of rivals.

This is not only applicable to sports but also to life – set your sights on a benchmark you feel worthy and work towards it, don’t compare with others too much.

Computers have something called cache – basically a place where they store data temporarily to make things faster. A cache is like a computer’s short-term memory, holding frequently used information so it doesn’t have to fetch it repeatedly from slower storage areas, like a hard drive or even the internet.

If a computer is a chef then the cache is the chef’s table where they keep the frequently needed ingredients to make the recipe, so that they don’t need to go to the pantry each time to retrieve them.

Just like a chef’s table, a cache has limited space. And just like the chef only keeping frequently used ingredients and swapping them out as the recipe changes, a computer’s cache replaces older, less-used data with newer, more relevant information to ensure everything is optimised for speed.

A good question then becomes: When a new item needs to be added and there is not enough space in the cache (the chef’s table), which item from the cache do you put back to main memory (the pantry)?

There are five popular ways:

1. Least Recently Used (LRU): Items that haven’t been used for the longest time are sent back.
2. Least Frequently Used (LFU): Items that are accessed the least number of times often are replaced.
3. Most Recently Used (MRU): The most recently used item is removed, assuming it’s less likely to be needed again soon.
4. First In, First Out (FIFO): The oldest item in the cache (the one added first) is replaced first.
5. Random Replacement: Choose an item at random to replace.

Caching has lessons for practical life because IRL we have limited mental “cache” or bandwidth, and we often need to decide what to prioritise and keep readily accessible in our minds (or at least at hand).

BTW, in practical life the Least Recently Used (LRU) caching strategy is a good place to start. For instance, I’m writing this during spring cleaning season – LRU would advise that I get rid of those items first I haven’t used for the longest time.

• That sweater I haven’t worn in two years? Time to let it go (unless it holds sentimental value, cache doesn’t handle sentiment but we humans do!).
• Books I haven’t touched since college but thought I’d reread someday? They might be ready for donation.
• Kitchen gadgets gathering dust? They’re prime candidates for “cache eviction.”

One more thing about LRU-like systems is that they are self organising, and since humans are lazy, this is good news!

That is to say, if you are using the LRU caching system in practical life (like the Noguchi Filing System) then you do not have to worry about deciding the best organising scheme in advance because over the the things that really matter (need most often) will naturally organise to be near at hand, while the ones that do not can be confidently moved to deep storage.

“Tossing things back on the top of the pile is the very best you can do, shy of knowing the future.“.

Now, computers have multiple caches and so should you.

What this means is that you should have multiple quick access spots throughout your home (or office) and things should be placed in areas where they are most typically needed.

• Keep your “going out” essentials – keys, wallet, hat, sunglasses – by the front door.
• Tool kit should be in the place where you actually use those tools, like a shed.
• And of course, things spices, seasoning, pots and pans should be on (or under) the cooking counter by the stove.

When you start your morning you have a sense of the different things you need to do over the course of the day. Some of them can be done at any time, some of them depend on other things being done first, some of them have important consequences while some of them are easily reversible.

So how do you decide what to do first? There are lessons to be learned from how computers handle scheduling. A few common approaches are:

1. Earliest Deadline First (EDF)/Earliest Due Date (EDD): Do tasks that have closer deadlines first.
2. Moore’s algorithm: Use the EDD method but if you encounter a task that cannot be completed by its due date then remove it from the list. For example, If you’re overwhelmed by commitments, postpone (or delegate) larger, time-consuming tasks to meet urgent deadlines.
3. Shortest Job Next (SJN): Do first the thing that takes the least amount of time.
4. Directed Acyclic Graphs (DAGs): Identify which tasks must be done sequentially and which can run in parallel.

The way you schedule will depend on what you’re aiming for – task deadline, most number tasks done, difficulty of tasks done, benefit from tasks done and so on.

If you choose for instance, the number of tasks done as the main goal (which should lead you to choosing the Shortest Job Next, SJN, as the strategy) then you will commit the MAFA fallacy (Mistaking Activity for Achievement) as my previous boss once told me.

And the thing about real life though it that not all tasks come with the same level of importance i.e. weight.

The weight can be anything, like the amount of money earned/loss avoided, or emotional impact, or the relationships improved, or even the stress reduced.

Therefore, divide the weight of completing the task with the amount of time needed to complete it. This will give you weight per unit time. Do the thing with the highest weight per unit time first a.k.a. Weighted Shortest Job First (WSJF).

Beware of priority inversion: In computers it is when a low-priority task locks a shared resource (e.g., a file, a piece of memory) and a higher-priority task tries to access the same resource but has to wait because the low-priority task has it locked. And then a medium priority task (that doesn’t need the resource) comes in and takes away processing from the low-priority task to itself. In this way the higher-priority task is stalled by the low-priority task, which itself is being stalled by a medium-priority task. Hence, the “priority” order is inverted.

IRL imagine this: At a gas station an ambulance (high-priority task) is stuck behind a vacation van (low-priority task) because the gas attendant is cleaning a fuel spill near the fuel hose (medium priority task). In this the vacation van waiting for the spill to be cleaned up so that it can use the fuel hose. As a result, the ambulance is left stuck at the behind the vacation van, even though it should logically take precedence.

In such cases you will practice “priority inheritance” and allow the low priority task to temporarily inherit the highest priority so that its completion can move things along.

This concept applies beyond computing or traffic scenarios:

• Workplace Delegation: If a lower-priority project is holding up a high-impact initiative, you give temporary urgency to that smaller task—allocating resources or clearing bottlenecks—so the more critical project can move forward.
• Event Planning: If setting up chairs (low-priority) is delaying the main event, you temporarily focus on finishing the setup.
• Life Administration: If a low-priority chore (like renewing a document) is blocking a more important plan (like overseas travel), you prioritise the chore temporarily to unlock the larger goal.

One more thing to learn from computers is preemption – which means stopping work on the current task temporarily to focus on a new task that has just come in.

And here too the Weighted Shortest Job First (WSJF) approach is a good way to know whether you should stop your work and switch or if you should just carry on.

If the updated weight of the current task (since you’re already doing it the time required to complete it is lesser now, leading to a higher weight per unit time) is higher than the weight of the new task then you might as well not switch.

Beware of switching costs: Every time we (and computers) decide in favour of preemption (known as “context switch”) and switch to the new task there is “… certain amount of necessary overhead … [where] none of it actually advances the state of [the jobs to be done] … It’s metawork. Every context switch is wasted time.“.

Like how it takes me time to go “warm up” when I switch from sorting my email to, say, writing this blog.

At an extreme, when jobs are coming at your hard and fast, all you may be doing is switching between tasks back and forth and not any actual work (a.k.a. trashing).

How to remedy this?

1. Learn to say no unless the new task is genuinely has higher weight per unit time.
2. Time block where you will do one task and one task alone. And include in it the time you take to “warm up”.
3. Batch process small, repetitive tasks like paying all household bills on a fixed due date (or two) in a month or responding to email once (or twice) a day (a.k.a. “input coalescing”).
4. Set Boundaries for Interruptions by using “Do Not Disturb” settings or let colleagues know when you’re unavailable for ad-hoc requests during focus time.
5. Leave buffer periods between time blocks for unexpected tasks, ensuring they don’t completely derail your day.

There are “… two types of things in the world: things that tend toward (or cluster around) some kind of “natural” value, and things that don’t.” – The authors are talking about statistical distributions here.

I like to think of statistical distributions as shapes that describe how data behaves in the real world.

They’re like fingerprints, unique to the context they represent, revealing patterns, tendencies, and surprises.

When things cluster around a “natural” value, you’re often looking at normal distributions—a bell-shaped curve with most data points gravitating toward a central mean.

On the other hand, when things don’t cluster neatly, we may be seeing power-law distributions or Erlang distributions.

A power law distribution is where a small number of things happen very often or are very large, while a large number of things happen very rarely or are very small. It’s the opposite of a “fair and balanced” distribution—extremes dominate!

An Erlang distribution is when things happen randomly with a predictable average rate.

“Knowing what distribution you’re up against can make all the difference.“.

After a point more data is just not helpful when making decisions, it may in fact end up confusing you. The authors make a link between this very human experience and the data modelling error called overfitting.

Overfitting occurs when a model becomes too finely tuned to the data it has seen and starts capturing noise (random or irrelevant details) rather than the true underlying patterns. As a result, while the model performs well on the training data, it struggles to generalise to new, unseen data.

In practical life one can find all kinds of scenarios where overfitting can be observed. For example when students rote memorise the answers to a test and excel in it only to flounder when they start their careers. In this case one can say that the learning model used by the students overfit to the scenario they were in without considering the larger goal of getting an education viz. to be useful to society.

As the authors point out “… considering more and more factors and expending more effort to model them can lead us into the error of optimizing for the wrong thing …”.

And this in truly an unfortunate side effect of well intentioned incentive design – like when students start studying for grades instead of learning something, or salespersons hard selling things that have the highest commissions instead of the ones you really need.

So, how to avoid overfitting?

1. Cross validation: How good is your model in predicting things outside the training data. In practical life will mean seeing how good our training is in the real world. Like testing students in practical examinations along with the regular written tests – if the students are doing well on the written tests but not on the practical exams then you know there is a problem.

2. Regularisation: This means that we should make our model complicated only when the benefits outweigh the costs. That is, each variable will need to make the predicting power of the model significantly stronger than before or it will be removed – a complexity penalty. In practical life this can be applied to all kinds of areas like shopping – think about the benefits that will come from purchasing versus the added complexity in life (such as maintenance costs, clutter etc.)
3. Early stopping: A related point to the one above, early stopping means that we should start building our model by looking at the single most important factor and not start with a multi-variate model at the outset. Due to the Pareto principle most of your observations will be reasonably predicted by a handful of variables. After this point the added complexity is just not worth it.

“If you have high uncertainty and limited data, then do stop early by all means.“.

In a way the authors are telling us to keep things simple in life. If something is truly important, it will bubble up eventually.

By over-engineering minute details around each aspect of our lives we may be wasting time without making our life all that better. This is especially true when we have a lot of uncertainty – like when we are starting a new venture or a new phase of our lives. In such cases broad strokes planning is enough.

In mathematics there are a group of problems called “intractable“, which means that there is no efficient way to solve them within a reasonable amount of time, especially as the size of the problem grows.

Examples of Intractable Problems

• The Traveling Salesperson Problem (TSP): Finding the shortest route to visit a set of cities and return to the starting point is computationally demanding as the number of cities grows.
• Knapsack Problem: Deciding the most valuable combination of items to pack within a weight limit.
• Graph Coloring: Assigning colors to graph nodes so that no two adjacent nodes share the same color.

What does this have to do with real life? Well even in real life there are a few problems that you may call (figuratively) intractable – like fitting all activities you want to do in a day limited by 24 hours and constrained by many responsibilities.

Like in my case, I want to spend the most of my day working on Sunchaser, then spend the rest of the time on fitness, family, entertainment. But I have constraints imposed on me like needing to take care of my daughter or buying groceries because that’s my responsibility. Due to all these constraints it becomes very difficult if not impossible to do all I want to do.

1. Constraint relaxation: Constraint relaxation allows you to focus on the tasks that truly matter while loosening up where flexibility exists.
   • Instead of treating all your constraints as rigid and non-negotiable, ask yourself: Which constraints can I relax without breaking my core responsibilities or goals?
   • Could grocery shopping be outsourced (e.g., delivery services)?
   • Can fitness be simplified to a 20-minute home workout instead of a 1-hour gym session?
2. Continuous relaxation: This method helps you balance competing priorities by distributing time and effort more fluidly.
   • In math, continuous relaxation involves treating discrete variables (e.g., “yes or no” decisions) as continuous ones (e.g., sliding scales of “how much”).
   • In math, continuous relaxation involves treating discrete variables (e.g., “yes or no” decisions) as continuous ones (e.g., sliding scales of “how much”).
   • Instead of asking, “Do I spend time with my family OR work on Sunchaser?”, think in terms of how much time to allocate proportionally.
   • Example: Spend 4 focused hours on Sunchaser, 2 hours fully present with family, and a short but meaningful amount of time on fitness or entertainment.

3. Lagrangian relaxation: It’s about finding that balance between achieving your core goals and managing constraints without guilt.
   • In optimisation problems, Lagrangian relaxation allows breaking a hard constraint by assigning a penalty or trade-off cost for violating it. In life, this means:
   • If caring for your daughter or grocery shopping feels inflexible, you could assign “penalties” for slight deviations (e.g., asking a trusted person to babysit for an hour or buying slightly pricier pre-cooked meals occasionally).
   • You don’t completely ignore responsibilities—you just assess the trade-offs to free up time for high-priority activities.

When problems get hard to solve on paper the practical approach may be to use the universe as your computer – this method, often referred to as a Monte Carlo simulation, embraces randomness and iteration to approximate answers when analytical solutions are too complex or intractable.

We can use the Monte Carlo approach in practical life as well – all we need to do is run simulations.

Monte Carlo simulation is fundamentally built on the concept of sampling. At its core, it uses random sampling to approximate solutions to problems that are too complex to solve analytically.

Imagine you need to figure out how much monthly budget to allocate to grocery spends. If you take the analytical approach to this it will be very hard to solve because you’ll have to think about a host of variables like “how many times will we have guests over?” or “how many times will we just decide to eat out instead?”.

So instead of spending an afternoon planning an imaginary grocery budget – you just see what happens. In this way you are letting the universe do those calculations for you.

1. Get some base data and define the problem: Like a few months of actual grocery expenses, the good thing is that this is actual data and not imaginary. Say you find out that weekly grocery spend varies randomly from ₹3,500 to ₹4,500. There are 4 weeks in the month.
2. Set up the simulation: Randomly select a weekly expense (₹3,500–₹4,500) 4 times to generate a month’s total.
3. Run iterations: Repeat the simulation 1,000 times to simulate different monthly expenses. Can be easily done in Microsoft Excel. Record each monthly total (e.g., ₹15,200, ₹16,800, etc.).
4. Analyse the distribution: Average the totals to get an expected monthly expense. Identify the most likely range (e.g., ₹14,500–₹17,000).

Hill Climbing

Hill climbing is an optimization algorithm that, at its core, is about moving uphill—improving iteratively by taking small, positive steps.

The takeaway? Even if you sometimes act on bad ideas or make mistakes, you should always act on good ideas.

Don’t let perfectionism or fear of failure hold you back.

Recognising a good idea and acting on it, no matter how small the step, is how progress happens.

Momentum often builds by consistently choosing to climb higher, one actionable decision at a time.

The Metropolis Algorithm

Basically, assess bad ideas with proportionality

In decision-making, we’re bound to face bad ideas and temptations. The Metropolis algorithm gives us a counterintuitive yet brilliant strategy: your likelihood of following a bad idea should be inversely proportional to how bad it is.

Not every bad idea is catastrophic—some can teach you valuable lessons with manageable risks.

If an idea is slightly risky but intriguing, weigh it carefully. On the other hand, steer clear of truly terrible ideas.

This principle helps you balance exploration with caution, letting you embrace calculated risks without recklessness.

Simulated Annealing

In a sense, front-load your randomness

Simulated annealing teaches us the power of structured randomness.

Begin with an open, exploratory mindset—experiment, take risks, and embrace uncertainty.

Over time, reduce the randomness in your approach as you refine your goals and identify what works.

Think of it as “settling down” in your decision-making process: start by casting a wide net, then narrow your focus as you gather experience.

This strategy not only encourages growth and creativity but also ensures that you temper yourself—literally—into a state of calculated precision.

The world of computer networking is a marvel of efficiency, adaptability, and resilience. Beneath the surface of every webpage you load, video you stream, or email you send lies an intricate web of algorithms and protocols. But these aren’t just lessons for engineers—they offer practical insights for navigating life.

Exponential Backoff: Don’t Force It, Take a Step Back

When you face repeated failures—whether it’s trying to solve a problem, win an argument, or land a dream job—pause, reflect, and give it time. Instead of stubbornly forcing the issue, take progressively bigger breaks to recalibrate. Sometimes, patience is the key to success.

AIMD (Additive Increase, Multiplicative Decrease): Balance Growth with Control

Apply this in personal growth. Push yourself to improve steadily—whether in fitness, skills, or relationships—but be prepared to scale back quickly if you face burnout or obstacles. Growth is sustainable when balanced with awareness and control.

Avoid Bufferbloat: Keep Things Moving

Don’t overload your life with tasks, responsibilities, or possessions. Clutter—physical, mental, or emotional—slows you down. Focus on what truly matters, let go of excess baggage, and keep your momentum.

Practice Tail Drop: Set Boundaries Before It’s Too Late

When you’re overwhelmed, set boundaries and prioritize. Let go of non-essential commitments or habits before you reach your breaking point. Saying “no” to some things is necessary to say “yes” to what truly matters.

Triple Handshake and ACKs: Build Trust Gradually

Trust and collaboration in relationships—whether personal or professional—require clear communication and small, mutual steps. Don’t jump into commitments too quickly; build trust gradually with reciprocal actions that show readiness and reliability.

The Prisoner’s Dilemma has long been the poster child for exploring the complexity of human cooperation, sparking debates across philosophy, economics, and game theory.

But the authors offer a fresh perspective, arguing that the Prisoner’s Dilemma might not truly capture the essence of human cooperation. That is, the dilemma represents a situation where the odds are overwhelmingly stacked against cooperation—a worst-case scenario.

Instead of trying to out-strategize bad rules, Binmore’s insight encourages us to consider something more transformative: changing the rules themselves. This approach is at the heart of a fascinating branch of game theory called mechanism design.

1. Identify flawed rules
   • Focus on the systems or situations where cooperation or success feels impossible.
   • Action: Analyse what’s incentivised—are current rules encouraging selfishness or inefficiency?
2. Reverse engineer desired outcomes
   • Start with the behaviour you want to see, then design rules to promote it.
   • Action: For example, in teams, reward collaboration over individual wins.
3. Test and refine
   • Ensure the new rules produce the intended behavior without unintended consequences.
   • Action: Pilot changes in a small group and iterate based on results.