How to Actually Apply Algorithmic Thinking to Everyday Decisions
The book Algorithms To Live By The Computer Science Of Human Decision by Brian Christian and Tom Griffiths takes concepts from computer science and maps them onto human decision-making. It covers things like optimal stopping theory, caching, sorting, and scheduling. The premise is straightforward: the problems computers solve are the same problems your brain faces daily, just without the silicon. I read it two years ago and have been applying fragments of it ever since. Some ideas landed well. Others felt like intellectual decoration. Here is the honest breakdown of what actually works in practice and what to skip.
The Core Premise Behind Algorithms To Live By The Computer Science Of Human Decision
Computer science is fundamentally about managing uncertainty, limited resources, and incomplete information. Humans do the same thing constantly. The authors argue that algorithmic frameworks can give you better heuristics than gut feeling alone. Optimal stopping is the big one. Also known as the secretary problem. The rule is simple: when searching for something with no way to go back, explore for a set portion of your time, then commit to the next option that beats everything you saw during exploration. For a job search or apartment hunting, that ratio comes out to roughly 37 percent. Stop looking at 37 percent through, pick the next thing better than your best early option. This is not theoretical fluff. I used a modified version of this when hiring a contractor for a home renovation. I had maybe three weeks and couldn't revisit rejected bids. I interviewed three contractors in the exploration phase, established a baseline on price and timeline, then picked the fourth one who exceeded that baseline. It saved me from endless scope creep and decision fatigue. Total process took about nine days instead of the three weeks I was originally planning.
Explore vs Exploit
This concept comes straight from reinforcement learning. When should you try something new versus sticking with what already works? The answer depends on how much time you have left. Early in a process, exploration pays off. Later, exploitation becomes rational. The tension shows up everywhere. Restaurant choices, music playlists, career moves. Most people never notice they are in an exploit phase until they are already stuck. The workaround is setting a hard rotation rule. Every fourth or fifth attempt at something new, deliberately switch. It forces exploration without wasting all your time testing. I noticed this playing out with my daily work tools. I was using the same project management system for eighteen months. It was fine. Then I realized I hadn't evaluated alternatives in over a year. Switching to a different tool took me a week and cut my meeting overhead by about forty percent. The cost of switching was low because I had been meaning to look anyway.
Get the Full Details
Caching and the Cost of Memory
Caching is how computers handle the fact that access speed varies wildly. Fast memory is small. Slow storage is huge. You keep the things you use most in fast memory and move the rest out. The brain does this naturally, but poorly. We remember things we just saw, not necessarily things we need. The Least Recently Used eviction policy is the standard approach. When cache space fills up, drop what you haven't used recently. Applied to your life, this means offloading routine decisions into systems. Grocery lists. Recurring bills. Workout plans. Stop deciding these things every single time. Here is where it gets counterintuitive. Most people think remembering more is better. It is not. Having external systems for trivial decisions actually increases cognitive capacity for harder problems. I started tracking my weekly meals in a shared document about six months ago. It eliminated roughly twenty minutes of daily decision time. Over a month that is eight hours I no longer waste wondering what to eat for dinner.
Sorting and the Cost of Mess
Sorting algorithms exist because unsorted data is expensive to work with. Binary search on sorted data is logarithmic. On unsorted data it is linear. Every time you search something without organizing it first, you pay a hidden tax. Filing systems, email inboxes, and even physical spaces follow this rule. I reorganized my digital photo archive once using a folder structure based on year and event type. It took about forty-five minutes. Before that, finding a specific photo from two years ago usually took ten to fifteen minutes of browsing. Now it takes about thirty seconds if I remember the event name. The common mistake people make is waiting for the perfect sorting system. It does not exist. A mediocre system you maintain beats a perfect system you never finish building. I see this constantly with people trying to set up elaborate note-taking architectures. They spend weeks configuring tools and never actually take notes.
Scheduling and Prioritization
Shortest job first is a well-known scheduling heuristic. In theory it minimizes average wait time. In practice, it can starve long tasks indefinitely if short ones keep arriving. The workaround is round-robin scheduling: alternate between short and long tasks on a fixed cycle. I applied this to my workflow a while back. I was finishing small tasks quickly but my bigger projects kept getting delayed because something always smaller came along. I switched to blocking out specific afternoon slots for deep work, regardless of whether an email looked urgent. My project completion rate improved noticeably within three weeks. The urgency of immediate tasks is often inflated compared to actual importance.
Lapse Detection and When to Stop
One of the more useful ideas in the book is recognizing when you are in a local optimum. A local optimum is a solution that looks good compared to your immediate neighbors but is worse than solutions elsewhere. Algorithms get stuck here all the time. Humans do too. The escape mechanism is simulated annealing. Introduce randomness, allow worse options temporarily, then gradually reduce the randomness as you converge. In practical terms, this means deliberately making small suboptimal choices early on to avoid trapping yourself in a narrow path. I ran into this when planning a trip. I was optimizing for cheapest flights and cheapest hotels separately. The combined result was a terrible itinerary with long connections and bad locations. I stopped trying to optimize each piece individually and optimized the whole trip at once, even though some components cost more. The total experience quality improved significantly and the extra cost was marginal.
What the Book Gets Wrong or Oversimplifies
Some of the analogies stretch too far. Human brains are not general-purpose computers. We have emotional weighting, social context, and pattern recognition that no algorithm replicates. The authors know this but occasionally treat the parallels as more literal than they actually are. The book also downplays the cost of implementing these strategies. Optimal stopping requires knowing your sample size in advance. Most life decisions do not come with a clear endpoint. Caching requires discipline to maintain. Sorting requires upfront effort that feels pointless until you actually need to search. I found that the strongest applications are the ones that reduce friction, not the ones that try to optimize every decision perfectly. Perfection is the enemy here. A heuristic that is slightly wrong but easy to apply beats a perfect method you cannot sustain.
Practical Takeaways
Set exploration limits before you start searching. Whether it is a job, a relationship, or a product, decide in advance how many options you will review before committing. Thirty to forty percent of your estimated pool is a reasonable starting point. Externalize trivial decisions. Write things down. Use checklists. Stop relying on working memory for anything that repeats. Audit your local optima periodically. Ask whether your current choice is genuinely good or just the best among nearby alternatives. Change the set of options sometimes.
Accept that most algorithmic thinking is approximate. These are guidelines, not equations. The value is in having a framework, not in following it precisely.
