Mental Models

I just finished reading an excellent article on mental models here.

There are so many models that we could look into, but the article here gives 4 as a taster. The premise of the mental models being generic and applicable to life strike me as true because it look less than a minute to think of examples of them in the world of software development:

Inversion

Inversion is one of the most powerful mental models. Its origins can be found in the word “invert,” which simply means, turn upside down. As a thinking tool, it helps to identify and eliminate obstacles to success by tackling them from the opposite end of the natural starting point.

For example, say you were going on a date and you wanted to make a good impression. Instead of asking yourself, “What three things will make me look good?” ask yourself, “What five things will make me look like an idiot?”

In the world of software development, I think of applying this technique by asking “what if we don’t do this?” or “what if just we do this with a pen and paper?” It’s a good sanity check.

Many a project has been turned on its head by challenging the status quo or not just jumping in. Or even by asking the question ‘What if we don’t do this right now?‘

At one job we had to build out a new system to keep customers statements and invoices. Amongst other things we needed a user friendly internal app, so the accounts department could get access when the customers phoned in about the statements and invoices.

But as a team we asked ‘What if we don’t do this right now?’ – meaning that we instead considered waiting for a team with more UI capabilities to be available. We were to do this, us developers would have to retrieve customer requests manually for the accounts team until a UI was built. When we found that the accounts. team actually got a call roughly every other day, and the dev team we needed were available in a month, it became a no-brainer for us not to build the UI and just to wait.

First Principles

First principles thinking is one of the best ways to reverse-engineer complex problems. Often called reasoning from first principles, it is the act of boiling things down to their most fundamental truths.

This is done by separating the underlying ideas from any assumptions they might be based on. A first principle, therefore, is a basic assumption that cannot be deduced any further.

An excellent example was given on Elon Musk finding out about the true price of battery packs by going to the commodities market and finding the actual prices the raw materials were being sold at. He found that they were selling at only 13% of the finished costs.

We use first principles all the time in troubleshooting. The more tools we have our disposal here the quicker we can become.

Only yesterday we were having problems with an AWS lambda that was based off a webhook, frontend by an API gateway, sourced from commits in Bitbucket not firing. Bitbucket had a friendly transaction log showing the last time that hook fired, and the payloads required.

All of these could be copied into curl and directly submitted to our endpoint. That worked, so we could immediately start spending our effects looking at bitbucket.

Second Order Thinking

Every action has a consequence, and each of these consequences has further consequences. These are called second-order effects.

Second-order thinking means thinking about these second-order effects. In other words, it means thinking about the effects of the effects.

Never is this clearer to me than not investing in your own personal time for development. If we just acquiesce to deadlines today, we are slowing ourselves down for better development tomorrow.

As another example, at work, our builds were failing due to a connection to a third party vendor in our integration tests. If this vendor messed up, or was generally unavailable, all our pipelines immediately failed.

I suggested at work that a third party vendor that we connect to shouldn’t be part of our test success scenarios, since we were not in control if it. Others disagreed and said we should fail fast, and publicly, and also how would we then monitor when the vendor was actually unavailable?

It was an interesting chat that demonstrated perfectly the power in discussion of thinking things through – both sides had their merits and had thought the consequence through. We opted to fail fast in the end.

Pareto Principles

Named after Italian polymath Vilfredo Pareto, who noticed that 80% of Italy’s land was owned by about 20% of its population, the Pareto Principle (also known as the 80/20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes.

For example:

20% of your effort produces 80% of your gains.
20% of your customers produce 80% of your profits.
20% of your sources produce 80% of your happiness.
The point is to recognize that most things in life are not evenly distributed.

At my work, I used the Pareto Principle to great effect when the application security team wanted us to integrate a security scanning tool with all of our build pipelines. I was the go-between for the feature teams and the security team.

The problem was that each pipeline took a while to integrate, and the developers were flat out on feature work. So I asked what we wanted to achieve, and the security team explained that they wanted visibility of all the assets that development teams had. So the 80% value was actually in the visibility of the assets, not in the apps being fully integrated.

We were able to come up with a solution with Bash scripting and Python which got this reporting out the door within a few days. This actually worked even better because all the developers could see which assets were most vulnerable upfront, rather than integrating each asset themselves and only THEN seeing the results once they’d finished.

This principle dovetails nicely with second order thinking too. Sometimes writing some less robust code to get something out the door is ok IF that code isn’t staying around forever and it’s a spike to validate something. Then there’s a huge amount of value in the discovery (the 80%) vs the effort (the 20%). Tread with care on that one though!

Conclusion

I will be looking at reading the full article at some time to see what other mental models there are. I always like to have a set of tools that repay their investment, and this seems like a winner on that front. I’ll report back if there’s anything worthwhile.