Mental Models

I'm a big fan of the Farnam Street blog. One really neat section is Mental Models, where Shane Parrish explains the ideas of Charlie Munger in organizing knowledge using models. This resonates strongly with me as I have a great disdain for the rote memorization that sometimes passes as knowledge (usually in formal education settings, standardized testing, etc.). What's more, the focus here is for knowledge that's useful. I sometimes get so lost in books that I forget that to truly grasp the ideas I'm reading about, the idea needs to be put into practice.

So in that spirit, I've listed some of the mental models that I find relevant in my life (in no particular order). I'll try to expand on these models in future blog posts.

Joe's Mental Models

• Bottom-up Thinking
  • Software Engineering - If you truly want to understand how a program works, don't look at API specs or UML diagrams, read the damn source code!
  • Economics - Ray Dalio mentions in his Economic Principles that the best way to understand the economy is a bottom-up approach, it's really all just a bunch of transactions.
  • Golf - A tour pro once asked Ben Hogan for help with his golf swing. Hogan replied "Dig it out of the dirt, like I did". Hogan would spend long hours on the driving range working on his game. He'd hit golf balls until his fingers blistered, go inside and ice down the blisters until they were numb, then go right back out and hit more balls. I think the idea here is twofold: true knowledge requires unrelenting, focused action, and that sometimes you have to find it on your own. I wonder how this second part affects modern tour pros today. Most pros have a team of trainers and swing coaches, so you wonder how their swing holds up on the home stretch of a major when it's just them and the course (and millions of people watching).
  • Winston Churchill and Information Gathering - For the life of me I can't remember where I read this (and a quick Google search turned up nada) but I remember reading that Churchill preferred to get most of his wartime information directly from lieutenants on the front lines rather than from generals who might distort the information based on their own beliefs/ambitions.
• Picky in Selection but Aggressive in Execution
  • Poker (a.k.a. The Mike McDermott Principle) - In Rounders, Mike McDermott describes a solid Texas Hold 'Em strategy as being tight in pre-hand selection, but for the hands you do play, being aggressive. I like this approach, it requires discipline, and by default your opponents will assume you only play with good cards. Of course, in poker it's also good to deviate completely from this strategy to throw people off the scent, so if you're ever across the felt from me, you've been warned!
  • Information Consumption - In the books you read, the movies you watch, and the fields of study you undertake, I think you should be picky in what you choose to spend your time on, but be fully present and engaged in what you do. We're on this earth for a short while, you owe it to yourself to converse with the best art humanity has produced. And do try to limit social media, the endorphins are nice but there's so much else out there.
  • Shopping - With the notable exception of books, I tend to be pretty frugal when it comes to shopping. However, when I do buy something, in most cases I try to get something of higher quality and that will last. Case in point, I recently bought a pair of Plantronics over-the-ear headphones to minimize distractions at work. Given how often I use these and how important I value my time at work, it was a no-brainer to spend more money on them, and having a general system of fiscal conservatism made the financial outlay more bearable.
• Single Responsibility Principle
  • Software Engineering - When defining a class or a method, it should focus on doing only ONE thing and doing it well. If your method starts doing multiple things, it's probably time to split into smaller methods to handle each one things. This makes your code easier to reason about and easier to debug.
  • Business - For some companies/startups, it pays to focus on only ONE niche/market/service and have all of your decisions go through that one filter.
• Batching Tasks for Efficiency
  • Productivity - If you have a list of regular tasks that need to be done and aren't super time-sensitive, schedule an hour or a day a week to get them all done then. I have a "Taking Out the Trash" on Monday nights, which coincide with my actual trash day so it feels natural and I don't need a reminder. In addition to paying bills and balancing my checkbox, I also catch up on RSS to see the blogs/newsletters from the past week and do a bit of reading and/or assigning articles to Pocket. Inspired by several folks but first heard it from Tim Ferriss in The Four Hour Workweek. I'd also suggest that if a task takes two minutes or less, just do it right away.
  • Software Engineering - A typical pattern in ETL when moving large chunks of data from a big data source (i.e. huge Hadoop cluster) to another data source (i.e. relational database for reporting) is to batch the operation and run it once a day/week/month depending on your needs. Constantly running an expensive job like that will most often not make sense, so batching time-intensive operations late at night is effective.
• Premature Optimization
  • Productivity/Organization - I've noticed recently that in an effort to try to stay organized, I over-label emails in Gmail, documents in Evernote, and notes in Keep, yet whenever I want to find information in any of these platforms, I do a simple search (which is usually fast and effective). So my advice is, only use tags sparingly for a few main contexts that you use often. For example, in Keep I have tags for my clients, writing, shopping, housework, and general tasks.
  • Software Engineering - Premature optimization is the root of all evil. Couldn't agree more. I'd also extend that to the startup world to say that the premature building of software before proving out a market is evil and a waste of time and money.
  • Career Planning - I suggest rejecting the urge to plan your career two, five, or ten years in the future. Take the advice from Nassim Nicholas Taleb and try to be a flaneur. Explore new things, don't be afraid to let serendipity be your guide in life. Or in more practical, "fail fast" terms, try a bunch of small experiments with strong feedback and take the mindset of a tinkerer. This ensures minimal upfront cost, i.e. don't go to school for n years and spend X dollars to find you don't actually like your chosen profession.
• Efficient and Purposeful Storage (suggestions on better name welcome)
  • Data Structures - some data structures like balanced binary trees store data in such a way so as to make operations like search efficient. Certainly not a mind blowing concept but I appreciate thoughtful consideration ahead of time to improve future needs.
  • Folding Laundry - Before I met my wife, I NEVER would've folded my socks. Yet after living with her and seeing how she folds her socks, I've realized the wisdom in her ways. Spending the extra few seconds on folding (and grouping) a pair of socks together (i.e. data persistence) makes the finding of a pair of socks (i.e. data selection/reading) a lot easier (i.e. the effects are nonlinear).
  • Cassandra - this is efficient and purposeful storage on steroids. Cassandra, all but forces you to store data and design tables in an efficient manner. Schema design is based on the predefined queries you'll need in your application. Only a small subset of SQL is allowed to ensure that you run efficient queries over the cluster. While it definitely is not suitable for every use case, if you need to read/write Big Data effectively, this should probably be your datastore.
• Immutability
  • Software Engineering - Code is much easier to reason about and scale when you know the data structures you're using are immutable. See functional programming, Scala.
  • Data Persistence - Rather than storing data in a typical RDBMS where you can constantly mutate rows, consider an append-only datastore (also called Event Sourcing). Querying becomes more difficult (you effectively need to query the entire history of appends or save snapshots of queries) but you get an audit trail for free and schema evolution is trivial.
  • Accounting - Similar to previous point, data is never mutated, every transaction is entered into the ledger and aggregate queries like totals/sums are derived from the entire history.
• Addition by Subtraction
  • Dieting
  • Productivity