Thinking Fast & Slow
Lynn shares how the Engineering team are applying the principles of "Thinking Fast & Slow" to their everyday work!3 min read Published: 20 Jun 2023
At Glean we’re always eager to learn and share interesting thoughts with each other. We love a Book Club! Thinking Fast and Slow has been one of our recent reads so here’s some thoughts on how it can apply to our work in the Engineering Department.
"Thinking, Fast and Slow" explores the two systems of thinking that drive our decision-making processes.
The first system, which Kahneman calls "fast thinking" or "System 1," is intuitive, automatic, and operates quickly and effortlessly. It's the source of our immediate, gut responses to the world around us.
The second system, which he calls "slow thinking" or "System 2," is deliberate, logical, and requires effort and concentration. It's the source of our more deliberate and considered responses.
Fast thinking is automatic and easy, so as lazy humans our brains often prefer it, but beware! It can be heavily influenced by cognitive biases and heuristics, or mental shortcuts, that can lead us astray. As software developers, being aware of these cognitive biases and heuristics can help us make better decisions and avoid common pitfalls.
So what are some of the common pitfalls that might affect us as developers?
🧠 Confirmation bias is the tendency to look for, interpret or remember information in a way that confirms our existing beliefs or expectations while disregarding information that contradicts them. As a developer this could mean favouring certain languages or frameworks, even if they’re not the best fit for a project.
To combat this, it’s important to actively seek out information that challenges our assumptions. We might engage with others with opposing opinions, look for data against our hypothesis or do testing with users. We generally believe in the concept of ‘strong opinions, loosely held’, but sometimes we need to go a little further and try to prove ourselves wrong!
👀 Availability heuristic is the tendency to make decisions based on the most easily recalled or readily available information. You might prioritise tasks or features based on your own recent experiences or the experiences of others, even if these experiences are not representative of the broader user base or the project requirements. For example, fixing a bug you encountered, even if it is a rare issue that affects only a small subset of users.
To mitigate this, data is our friend. This can involve soliciting feedback from users and stakeholders, conducting user research or testing, and using data analytics to track usage patterns and identify areas of focus.
⚓️ Anchoring bias is where we give too much weight to the first piece of information or value that we encounter. For example, if the first person gives an estimate of 2 days to complete a piece of work, the rest of the team are fairly likely to give estimates clustering around this value.
To fight this bias, anonymous or concurrent estimation and feedback is extremely helpful. We like google forms, story point poker and slack bots to help.
💰 The sunk cost fallacy causes us to continue investing time and resources in a project because we have already done so, even if it no longer makes sense.
It’s important to make some time to review existing projects and remove the waste. It’s also important to foster an atmosphere where developers don’t feel embarrassed about abandoning previous approaches if they discover a better way. When tasks start to grow, remember to ask ‘Is it still worth it?’
🧐 Hindsight bias is the tendency to see past events as being more predictable and obvious than they actually were at the time. You might look back at a failed project, see all the signs it was going badly, and wonder why your team made such a mess of it!
To some extent, you’re always going to suffer from this when someone’s just introduced a bug into production! Introduce concrete mitigations to stop it happening again when you can, but try to be kind to yourself and your teammates!
Is ‘thinking fast’ always bad?
No! Although you could be forgiven for thinking so after reading all about how it could cause you to make all of those bad decisions! Making quick decisions can be essential in a time critical situation, and often efficiency is more important than considering a problem from all angles. Combining fast thinking with more deliberate analytical thinking, and being aware of when biases are likely to affect us can help us make more accurate and effective decisions overall.
Fancy joining Glean's book club?
Well, now's the perfect time! Visit our careers page to see all of our live roles.
More from Tech BlogView All
Mobile Updates Roundup
We've made a lot of updates to our mobile app recently - read on to find out what's changed!
Exploratory Testing at Glean
Zaryoon shares what Exploratory Testing is, and how it can be implemented in your tech teams to gain a deeper understanding of how your features work.
Maximising Engineer Value
Jonathan shares some practical tips on how you can maximise your Engineering teams value.