Introduction
I listen to the podcast Art of Manliness – its title is possibly misleading, as it’s quite a mix of philosophy, practical skills, self improvement, lives of interesting people and so on. The episode I listened to most recently was about mental models, from Shane Parrish who is the person behind Farnam Street.
I recommend you listen to the episode and visit the site, but the TL;DR version is that mental models are things to help you make better decisions – in life, in business and so on. They are drawn from anywhere and could be used anywhere, but are part of what make Warren Buffett and Charlie Munger good at financial decisions. As a result, Farnam Street is followed by people from Wall Street and Silicon Valley, as well as professional athletes.
A dog walk helped me to realise how they resonate with my experience as a programmer.
Dressing for the occasion
Mental models aren’t for every decision – which flavour of toothpaste should I buy? isn’t something that you should spend much effort on. In those situations, just going with gut instinct (or whatever you call it) is probably fine. However, at the other end of the spectrum there are bigger decisions that should be the subject of more care and attention. Mental models are one way of doing that.
Too often, I realise that I go with my gut instinct too much for these heavyweight decisions, and fool myself that scrimping on the thinking is better overall because it saves me some effort.
It’s similar to programming. Fixing a typo in a GUI is a mechanical process that just involves keyboard and mouse with little brain effort required. For bigger things, like integrating two systems using SAML, you need more brain effort. In computing, this brain effort is architecture and design.
I’m used to this sliding scale as a programmer, based on what’s appropriate to the situation, but I don’t always get it right. Just as I could indulge in bike-shedding and other kinds of over-thinking, I can under-think and this can be a false economy. I should have a quick triage step ahead of dealing with a task (programming or making a decision): how much do I need to think about this? And I should be prepared for the cases when the answer is a lot, and do those cases justice by optimising over the long term rather than wimping out of brain effort in the short term.
Going against yourself
One part of Shane Parrish’s advice is to deliberately argue against the position you would normally hold. It helps you flush out biases, woolly and lazy thinking, and generally helps you come to better decisions. Instead of just glomming onto the first option that seems right to you, you’re going with the option that you think is the best among several options – because you’ve taken the time to consider those other options.
As a programmer, I see this as testing by a different name. In order to have good code or a good design, it’s not just a matter of doing the thinking and typing necessary to create. I need to switch to the other side of the mental table and try to attack or break my creation. The result isn’t merely the first thing I could be bothered to knock off – it’s something that has run the gauntlet of potential bugs and survived. (I still need help from colleagues who are professional testers, who are much better at building and wielding the bug-finding gauntlet, but that’s no excuse for doing a reasonable stab at it myself.)
Patterns and models
Mental models sound to me a lot like design patterns. Both are some thinking that has proven useful, is distilled to its essence and then given a name to help you remember it. The more mental models / patterns are in your mental toolbox the better (assuming you know when to use them and when not to).
Summary
I recommend you listen to the Art of Manliness podcast in general, and the Mental Models episode in particular. I’ve only just scratched the surface of the Farnam Street website, but it seems full of thought-provoking and useful articles. If you’re a programmer, a lot of this will seem familiar to you based on stuff I hope you already do as a programmer.
Random Tech Thoughts 