Tech Support
Documentation
Login
Contact Us
A bat and a ball cost $1.10 in total. The bat costs $1 more than the ball! How much does the ball cost?
10 cents? Congratulations, you’ve just fallen into the cognitive trap Daniel Kahneman explored in his book Thinking, Fast and Slow. Before we move on, the correct answer is 5 cents. But, of course, most people don’t do the calculations; they just rely on their gut. This is nothing more than a mental reflex that Kahneman calls System One.
According to Kahneman, System One is the brain’s automatic and intuitive mode of thinking that often leads to fast responses. This system of our brain is always eager to respond and continuously scans patterns it can solve with little effort. But the unfortunate reality is that this system is often wrong.
On the other hand is System Two, a slower, more deliberate process that puts in the effort. It starts working when we stop ourselves from shouting “10 cents.” However, this system uses energy, and that’s why it’s not the go-to option for our brain. These two systems don’t just show up in logic puzzles.
For developers, they determine how code gets written, how problems are debugged, whether you wait for a build or give Slack a quick look, and more. If both of these systems are working every time you open your IDE, the question is which one do you use often, and how can you use one or the other to improve development practices? Let’s find out!
Kahneman 101 – Thinking Fast And Slow
Before we get into how both these systems can be used to build development efficiency, let’s look at what they really are. Kahneman, a psychologist who won the Nobel Prize in economics and proposed these systems, wasn’t awarded for financial forecasting or market predictions.
In fact, he was awarded for a reality that economists had long ignored. The reality that humans are not rational decision makers. Kahneman spent 50 years of his life studying how humans make decisions when faced with uncertainty. The results of his work completely changed the assumption that humans choose based on logic and reason.
In his book, Thinking, Fast and Slow, Kahneman introduced a model of the human brain, claiming that it’s divided into two systems:
| Characteristics | Functionality | |
| System 1 | Fast
Emotional Cheap Intuitive |
This system jumps to conclusions based on patterns, even when those patterns are misleading. It’s the system that instinctively shouts “10 cents” in the bat-and-ball puzzle. For developers, this is what makes you say “Looks fine to me” when you see the code, but don’t really think about it. |
| System 2 | Expensive
Slow Logical Controlled |
This system is what you activate when you catch yourself before shouting the wrong answer, or when you think through a particular design pattern to figure out whether it’s the right fit based on your project architecture. However, this system doesn’t start unless you force it to. |
So, what does all this mean for developers? The answer is that your brain is constantly choosing between a “fast, but wrong” or a “slow, but right” process. But here’s the catch – when you’re tired and exhausted, your brain will automatically start using System One, and this can severely impact the quality of your code.
System One Vs. System Two – What Do Developers Use The Most?
When you ask any developer which system they rely on the most, the answer will most certainly be System Two. It’s slow, logical, and requires effort. All of this aligns with coding perfectly. In fact, in a live poll, nearly 90% raised their hands for System Two. They’re not wrong. Why? Most developers need deep, focused thinking.
But here’s the problem. System Two is quite expensive as it burns a limited cognitive resource we commonly refer to as mental fuel. When that fuel runs out, the human brain automatically goes to System One, and if the task still requires precision, that’s just too bad.
Quite a great concept, right? Well, it’s not just theory. Behavioral scientists have found real and measurable evidence that our mental energy works similarly to a phone battery. So, every time you write code, debug, or prevent yourself from getting distracted, the battery drains. Dr. Gloria Mark, who has spent 15 years studying human attention, claims that:
- The average person checks their email 77 times a day.
- The amount of time spent on screen before switching is just 3 minutes and 47 seconds.
- It takes 25 minutes to be fully focused on the original task after being distracted.
So, that three-minute wait on a build you used to check your email is actually costing you 25 minutes in reality. But, this isn’t the worst part. Every time you switch context, your brain automatically goes back to System One, even if you were working in System Two. This is why mistakes happen, quality drops, and you end up writing “Okay code.”
Is “Okay Code” Worse Than Bad Code?
Not all bad code is a real threat. There are times when “Okay code” can be just as dangerous, if not more. What’s the reason behind that? It compiles, it passes tests, and it often slips through pull requests unnoticed.
So, in essence, code written in System One mode tends to be just good enough to fly under the radar. The cherry on top is code reviewers who are running on depleted mental fuel. They glance at such code and say, “Looks fine to me.”
These pipelines, by design, operate like System One models, and the result is mediocre code turning into a mediocre product. Kahneman notes that repetition and feedback loops can move skills from System Two to One, so is it possible to train developers to write better code instinctively?
Techniques For Protecting System Two
When it comes to using all this for developer efficiency, start by knowing that System Two is your most powerful tool as a developer, but it’s also the most fragile. Given this, it must be protected from constant distractions, and there are many ways to do that.
Time management is the key here. It’s possible that systems like the Pomodoro technique, where you do 25 minutes of focus and then a 5-minute break, are effective, but they can backfire if your deep work session is interrupted right when you’re about to enter the flow. Therefore, you should treat 25 minutes like a minimum and continue if you’re in the zone.
Apart from this, task batching is also a great technique that can protect System Two mechanisms as it helps avoid context switching. Developers can even use different AI-based tools to add focus sessions to their schedules while keeping room for meetings, a win-win. Next on the list is protecting mental fuel.
To do this, sleep is the only full reset option. However, there are a few other techniques that can be handy. For example, drinking coffee and lying down for a few minutes until the coffee kicks in can help. Apart from that, there are things like mindfulness and meditation. They sound like hippie stuff, but science is in their corner.
Developers Should Do This To Improve Practice And Efficiency
First and foremost, the underlying principle behind all of this is that quality results come from System Two, meaning that the state developers must be in if they want to get better results. Given this, some key things to try include:
- Guarding System Two times by using tools that schedule deep focus slots and auto-adjust based on availability, alongside time blocking methods to stay in the flow for longer periods.
- Using automation and AI to reduce cognitive load by allocating repetitive tasks to automation and AI tools, as it saves time and helps avoid context switching.
- Batching similar tasks together can also help avoid context switching, which preserves mental fuel and helps maintain focus.
- Recharge using sleep and mindfulness techniques, as these can help protect your cognitive resources, allowing you to stay in System Two longer.
- If something is not your expertise and is taking too much time, delegate it so that experts can create better and more secure solutions for you while you focus on core activities that drive business growth.
Final Thoughts
While Daniel Kahneman might not have written Thinking, Fast and Slow for developers, the insights contained within the book are exactly what software teams need the most. The harsh reality is that when you’re coding on autopilot, you get functional results. But you end up missing out on cleaner and scalable solutions that are hiding beneath the surface.
At the end of the day, writing great code doesn’t have much to do with talent or skill. It’s about being in the right mindset, the System Two mindset. Today, identifying when you’re slipping into System One and designing your workflow to keep you in System Two longer is the competitive advantage.
So, the next time you code, pause and ask yourself whether you’re coding fast or coding smart!
