Thinking Fast And Slow as a developer

In the excellent thinking fast and slow by Daniel Kanheman, the author proposes a representation of our mind with 2 systems:

–        System 1 is fast, but also prone to errors mainly due to biases
–        System 2 is slow, and can overcome some limitations of system 1, but we don’t like to use it

Think of driving. When you learn, you need a full focus and you can hardly have a discussion or listen to radio news when you drive (you use system 2). After a while, you can do it without thinking of it anymore, and you can easily discuss when you drive (you now use system 1).

An interesting thing occurs when you meet an unusual event (let’s say brutal stop of the car in front of you): you immediately stop to talk or to listen the radio. You now use your system 2 in order to manage the unexpected event.

We routinely use System 1. System 2 is involved when you learn something new, or to process complex thinking.

And if you wonder why Kanheman asserts we don’t like to use system 2, just try to calculate 21*17. You can do it, but you probably don’t want to, and you won’t do it just for pleasure. Even if you do it, it will be pretty slow.

What can we learn from this in software development?

Choose your battle

Technical skills (like mastering your IDE, TDD/BDD, a given language/Framework/Library, design pattern, SOLID…) should be practiced until they are fully integrated by system 1. You should be able to use them without thinking deeply about them. Ideally, if you master them very well, you can use your system 2 only to solve business problems, because all the technical stuff should be routinely managed by system 1. All the technical stuff is just the side effect, the goal is to solve a business problem.

But of course, we also need to learn/test new methods, language or libraries, or we will quickly be biased by our own knowledge. We’ll try to fix any business problem with the few technical things we master well. If all you have is a hammer, everything looks like a nail.

So we shouldn’t learn too much new things at once on a project, because the consequence will be less focus with system 2 on the actual business problem (or at least if we do, we should be aware of this limitation). If you learn TDD, do it in a language you master. If you learn a new language, don’t try to implement design patterns you never implement before. If you learn all this at once, do it on a pet project or in a coding dojo rather than for a customer that pay you to solve a business problem.

Choose your battle, you cannot win all of them at once.

How to teach TDD

Another thing we can learn from the system1/system 2 representation is: don’t be too rude when teaching TDD to a junior. First you should help him to master his IDE, language, libraries, patterns and good practices. Then he will be in better position to understand TDD. If you try to teach him everything at once, he will likely perform bad design and/or bad business decision. Not because he’s stupid, but because he’s already fully using system 2 to understand the TDD concepts he’s learning.

The interesting thing with TDD is that it actually challenges a bad design. But if your junior has no idea about what a good design is, he will just choose bad solution to solve what seems to him a pure “TDD problem”, not a design problem.

TDD rocks

Speaking of TDD, I was amazed to read this assertion in Kanheman’s book: “Whether professionals have a chance to develop intuitive expertise depends essentially on the quality and speed of feedback”.

In the book, he tries to explain the difference of expertise between financial experts and seasoned firemen. His point is: financial experts are pretty bad. Not because they are stupid, but because their job is to forecast, and we are terrible to do prediction. He performs several studies to demonstrate that traders “skills” are mainly due to chance.

But he was challenged by some other studies showing a true skill difference between seasoned firemen and novices. So Kanheman tries to understand these differences, and he concludes that the speed and quality of your feedback is essential to develop intuitive expertise. He explain it in a psychological way, because with a quick feedback your new knowledge challenges almost instantly your previous assumptions. It is not contestable because you clearly see the correlation between your thinking and the consequences. But when you have a very late feedback, or not at all, you missed that opportunity for improvement.

Prove immediately to someone that he’s wrong, and he could change his mind. Prove him the same thing some years later, and he might resist, or just refuse your argument. Ask to financial experts if they foresaw the 2008 financial crisis. Lots of them will answer they did, but only a few have actually spoken about it before it happened.

In software development I see exactly the same problem with architects that “don’t code anymore”. They are often reluctant to practice or spread TDD. Here again the power of TDD is to challenge your design in a very quick feedback loop. If it hurts, you can try to convince yourself that it’s because TDD is dead, or TDD sucks, or TDD doesn’t work in the real life. Truth is: your design sucks, that’s why it hurts.

To improve your expertise in software development, you have to find a way to obtain a quick feedback about design decision. That’s why TDD rocks.

Wish to read the book?

Of course there are much more than that to learn in this wonderful book, both for your professional and personal life, and not only for software developer. But I won’t spoil you anymore, if you have the chance, just read it.

And if you don’t want/can’t read it, at least remember:
– Choose your battle
– TDD rocks

It will definitely improve your developer’s life.

 

Thanks a lot to my reviewers: Johan Martinsson, Sebastian Larsson, Sébastien Rabiller, and Christophe Fernandez.
Thanks to Sandro Mancuso for recommending this book.