I’ve started reading Thinking Fast and Slow by Daniel Kahneman(check out my Kindle highlights)

Kahneman was one of the first to identify cognitive bias in our thinking, and this book describes a metaphor for two systems of thinking; System 1 (fast, intuitive, prone to bias) and System 2 (slow, methodical, conscious) working together to influence our interaction with the world.

System 1 is generally to do with emotion and feeling, but it also deals with facts if those facts have a strong belief behind them (for example, 2+2=4; Paris is the capital of France).
I have often coached people to use strong metaphors to express their ideas, and reading the early chapters of this book, I think part of the reason that I do this is that strong metaphors are much easier to absorb into System 1.

An engaging story is easier to absorb and express to others than a complicated description that requires conscious attention. This applies as much to code as is does to writing or speaking.

Admittedly, you will get underway faster, but that’s going to be very little comfort when you come to a grinding halt a few miles down the road.

I replied:
“Code _should_ start out messy. Finding the right places for things is harder when they’re already neatly in the wrong place”

If you have a preconceived idea of where your code should go, you will put it there by default. Antony told me an experience he had with this when he was untangling dependencies in jnarrate. By moving everything into a single package, then repackaging based on affinity, a much better package structure revealed itself.

At home, I would really like to re-organise my kitchen so that the pans are closer to the cooker. It makes sense from an ergonomics point of view. However, they already have a home. In order to rearrange the pans, I would have to empty the existing cupboard and the destination cupboard. It’s less work for me to put the pans back in their existing space, but it bothers me whenever I think of it. I really should fix that

These checks require very little in the way of skill or time. We should do them at least once per day, and preferably before every journey.
I don’t do these checks as often as I should, mainly because they are not habit and forming habits (good or bad) takes time and discipline.
If we were taught these checks as the first part of our driving instruction, it would seem unnatural to not do these checks before every journey. This is called Primacy and states that what is learnt first (good or bad) is hard to unlearn.

When learning to fly gliders, one of the first things I learned was the pre-flight check. This has the mnemonic CB SIFT CBE. To ignore this check would require a significant effort on my part. Even if I have already been through another, more comprehensive checklist, I will still run through this basic test before starting a flight, no matter what the aircraft. This significantly increases my chance of discovering a problem while I am still safe on the ground. Better to be on the ground, wishing you were flying, than to be in the air, wishing you were on the ground.

I know that writing software test-first leads to a better design and gives me a safety net within which to refactor. I know this in the same way that I know that I should check my oil regularly, but this is not the way that I learned to program. I still sometimes start writing code before I write the tests and find myself wishing I was down there, writing the tests first. It’s a hard habit to break.

Like the POWER checks, writing code test first is not difficult, it doesn’t take much extra time, and it pays benefits when we uncover problems before they get too serious. Until we unlearn the habit of jumping straight into the driving seat, we need the discipline to do our checks before hand.
Right now, I’m going to write two sticky notes. One for my car steering wheel that reads “POWER” and one for my computer monitor that reads “Have you got a test for that?”.