mental models

As complexity grows in projects, decision making, planning, modelling, reasoning, programming! I’ve found that it’s far easier to make correct decisions using a more structured way of thinking. For this I use mental models;

So… What is a mental model?

definition

“A mental model is an explanation of someone’s thought process about how something works in the real world. It is a representation of the surrounding world, the relationships between its various parts and a person’s intuitive perception about his or her own acts and their consequences.” wikipedia

Mental models are a structured way of thinking about things, they can help with many different types of problems. Mitigating, deciding, negotiating etc. As the complexity that we are dealing with grows, we need more supporting structures for making sense of day-to-day problems. Many mental models you might recognise from sayings, or life! They draw on a bunch of different areas; sport (hail mary pass, unforced error), war (trojan horse, empty fort strategy), and physics (critical mass, leverage) to name just a few. Drawing on concepts that we are familiar can often help to add clarity to a situation, by grounding it in an area with an analogy or metaphor we understand.

how do they help?

As mentioned, mental models are a structured way of looking at the world. They are thinking tools to help understand situations. Adding structure to the decisions and grounding them in areas that you already know can help to make sense of the complexity. The behavioural mechanics of a group of individual shoppers my be hard to reason about, but we can all get behind and understand supply and demand. This is a mental model to reason about economics.

As the complexity of our projects and code increases, it’s easy to manage and contain that complexity with models for thinking.

what are some examples?

For a while, my difinitive, complete goto list has been this one.

I’ve been studying this list, and even created my own slimmed down version of it for those I find myself using the most often. But there are some that I think are missing from the list, and these are those few. Most of these are from my experience programming, and are rooted in fixing commonly found gotachas.

flow

Flow, colloquially known as being in the zone, is where a person is fully immersed in a task. Operating at full capability, with full involvement. It’s basically the complete absoption in a task. Often the idea state of programmers to be in, having all the pieces in mind, and operating with full understanding of the system and changes.

functional fixedness

This is a type of cognitive bias limits a person to using or seeing an object as being useful for it’s first observed purpose. Imagine not thinking of being able to stand on a chair to reach something on a top shelf, because a chairs intended purpose is to be sat on. This might seem like a trivial example, but in a complex system it easily possible to overlook code reuse. Being cogniscent to this bais helps to question if an object could actually be repurposed for another use. It also helps to think about how to design components so that future programmers do not suffer from functional fixedness when considering how your componenets could be used.

algorithmic vs. heuristic

As programmers, we work with algorithms, but does that mean that we do algorithmic work? Lets break some things down to see. An algorithm is a automated solution to a problem, step by step solution to a problem. Algorithms are what we use or create, but not what we do as programmers. The heuristic approach or just heuristic is any approach to problem solving, learning or discovery that employs a practical method. The method might not lead to the optimal solution immediately, but it’s an iterative and gradual process of improvement. More art than science. This is surely closer to what we do as programmers, and is why this mental model has made it into the list. Algorithmic vs. Heuristic is a model for establishing how to approach a problem. If it’s a solved problem then sure, employ an algorithmic approach. Not much gain in reinventing the wheel. But for all new problems that require problem solving, a heuristic approach is better.

blast radius

The blast radius of an explosion is the distance from the source that will be affected. Consider that the explosion is some error in code or some production system outage etc. What is the blast radius? It’s the area of effect, that could be contained to a single server, service, app. Or it could be cascading, it could affect a much larger area. The smaller the blast radius, the less clearing up is required when the explosion happens. Considering the blast radius helps to program defensively and reduce the number of affected components when something goes wrong.

lava flow programming

Lava flow programming is a mental model that’s grounded in the way that lava flows (in the name see!) It describes code that is written under time (or other) constraints that causes it to be sub-optimal code. This code gets added to and built upon before the original design is fully completed. It results in the need to maintain backwards compatibility with half finished code with sub-optimal design. Consider building on top of slow moving lava, it would be difficult to ensure the stability of the building.

These are just a few mental models that I try and employ when making decisions as a programmer. Being aware of a model is half the battle, it helps to identify a situation and make better decisions by classifying the type of problem and the best possible outcomes.