Cognitive Biases
Programming with that Disreputable Part of your Brain
Summarized using AI
Programming with that Disreputable Part of your Brain
by Brian MarrickIn the talk titled "Programming with that Disreputable Part of your Brain" by Brian Marrick at the Rocky Mountain Ruby 2013 conference, the speaker explores the interplay between the automatic and effortful systems of the brain as it relates to programming. Marrick highlights that while programming is often viewed as a rational and precise endeavor, much of our thinking is influenced by the automatic processes of the brain, typically operated on autopilot. He proposes that by learning to work with this automatic part of our brain, rather than against it, we can enhance our programming skills and effectiveness.
Key points discussed in Marrick's talk include:
- Personal Journey: Marrick shares his transition from consulting to working for a tech company, which rekindles his interest in becoming a better programmer.
- Kahneman's Dual Systems: He references Daniel Kahneman’s "Thinking, Fast and Slow," explaining the two systems of the brain: the effortful system, which is slow and deliberate, and the automatic system, which is fast and intuitive.
- Examples of Learning: Marrick illustrates the differences in cognitive tasks, such as adding numbers versus instant recognition of simple math (like 2+2), to explain how the brain operates in both controlled and automatic manners.
- Training the Automatic System: He discusses the possibility of training the automatic system through practice. An anecdote about Steve Freeman illustrates how skilled programmers can recognize 'good code' instinctively, suggesting that the goal is to train the automatic brain to identify high-quality solutions easily.
- Best Practices in Programming: Marrick emphasizes the importance of repeatedly revisiting code, akin to techniques used in veterinary medicine for training perception, to improve one's coding instincts over time.
- Set and Setting Concept: He introduces "set and setting," originally a concept from psychedelics, to explain how one's environment and mindset affect performance and creativity in programming.
- Conclusion and Resources: Marrick concludes with insights on the significance of learning through XP (Extreme Programming) methodologies, promoting an environment that supports continuous learning, followed by an offer for his book on functional programming as a resource.
In summary, Marrick argues that by understanding and honing our automatic cognitive processes, programmers can produce better code with less conscious effort, thereby facilitating a more intuitive approach to coding and problem-solving. Connecting cognitive processes with practical programming techniques offers valuable lessons for both new and seasoned developers.
00:00:30.800
Okay, good morning. I am here to brainwash you into something crazy.
00:00:36.880
Let me start out by saying a strange thing happened to me in May: I got a job. After many years as a consultant, I now work for a real company that pays me on holidays and provides the whole salary arrangement. It's pretty interesting.
00:00:52.879
The reason I decided to get a job was that as a consultant, I would go into companies, pair with people, and teach them Test-Driven Development (TDD) and refactoring. However, I never got to do anything but visit a codebase. I had my own open-source projects, including a Closure testing tool that's been fairly popular, but I wanted a chance to work on a large codebase over a long period and see it improve over time.
00:01:17.119
Now that I'm being paid to produce software, it has caused me to reinvigorate my interest in a question that's intrigued me for a long time: What makes a good programmer? How does one become a good programmer? In particular, how can I become a better programmer?
00:01:28.480
This talk is about some of the things I've been doing recently in the quest to become a better programmer, which I hope will be helpful for you as well. My self-improvement efforts are somewhat based on the book "Thinking, Fast and Slow" by Daniel Kahneman, a psychologist who won the Nobel Prize in Economics. He recognized that humans are not rational calculating machines; instead, we have brains that often behave irrationally.
00:02:05.360
In the book and his work, he divides the brain into two systems, which he refers to as System One and System Two. I can never remember which is which, so I call them the effortful system and the automatic system.
00:02:16.640
For example, an effortful activity performed by the effortful system is adding two numbers, such as 123 plus 82. If I ask you for the answer, most of you won't come up with it immediately. Some of you might revert to the method learned in grade school, adding digits from left to right or right to left and carrying the one. Others may know some helpful tricks, like recognizing that 12 plus 8 is 20, and thus 123 plus 82 is 205.
00:02:39.440
However, this is still a step-by-step linear effortful activity. In contrast, if I ask you what 2 plus 2 is, you don't need to process it step by step; you immediately know the answer. It's impossible for you to hear '2 plus 2' without thinking '4'. Similarly, when I say a word in your native language, you don't perceive it just as a sound; you understand its meaning instantly, thanks to the automatic system translating it before the effortful system can act.
00:03:01.200
Another example of the automatic system in action occurs while driving. Picture yourself driving on a quiet country highway, not encountering busy traffic. After half an hour, you realize you haven't actively paid attention to driving; you've navigated curves and stayed within the lane, yet you have no conscious memory of doing any of it. That's because the automatic system handles those tasks for you.
00:03:20.319
In contrast, if you are trying to park in a very narrow space, you must consciously focus on the dimensions of your car and its relation to the surrounding objects. This focus is very different from how you drive on the highway.
00:03:36.319
Lastly, imagine standing on a hill in Scotland, tasked with counting a flock of sheep below. That would be an effortful activity as you track each sheep and deal with their movement. However, should you see one green sheep, you would notice it immediately without even thinking, assuming you're not colorblind. The automatic system is in charge of that perception. The effortful system is referred to as such because it indeed requires effort; performing calculations or programming tasks can be tiring. If your job is to add five-digit numbers throughout the day, you'll feel fatigued by the end of it.
00:04:05.440
If you're diligently programming—well, as long as you aren’t distracted by social media—you're likely to feel tired too. When you perform an effortful task, your pupils dilate in proportion to the difficulty of the task. Researchers can gauge whether you’ll give up on a task based on the dilation of your pupils. The effortful system can be exhausting.
00:04:41.440
Conversely, the automatic system operates in the background; it is always active and requires no conscious effort. However, it also operates in a parallel manner, continuously monitoring for other stimuli. For instance, when looking at a green sheep, your automatic system is still alert for any potential threats approaching you, despite the parallel tasks occurring.
00:05:02.160
In contrast, the effortful system can only manage a single task at a time. Thus, if you're asked to add five-digit numbers while simultaneously parking your car—especially in a tight space—your performance will suffer markedly in both tasks.
00:05:10.639
As I build up the importance of the automatic system, it's essential to note that the effortful system, being taxing, often seeks to offload as much work as possible onto the automatic system. This is beneficial because it minimizes your overall effort. The caveat, though, is that the automatic system is limited in its capacity to manage tasks. Furthermore, it has evolved in an environment vastly different from our current one.
00:05:30.560
This evolution contributes to various cognitive biases and poor financial planning decisions; we didn’t have to make complex financial choices in the African savannah 200,000 years ago. The automatic system isn't tuned for handling such tasks effectively.
00:05:50.560
The effortful system is a general-purpose system; however, it should only be employed when the automatic system can't perform the task effectively. Interestingly, an activity like parking a car, which is hard for most people when learned for the first time, becomes automatic with practice. Car park attendants, for example, can park cars as effortlessly as most of us drive on highways.
00:06:04.560
There’s also an interesting observation regarding chess players. Really good chess players have a remarkable ability when they look at a board—they see only the strong moves available. In contrast, less skilled players perceive all possible moves, leading to an overanalyzing of the situation. This difference relates to the automatic and effortful systems in our brains.
00:06:30.240
A case in point is Steve Freeman, a programming consultant from London who has been involved in many notable software developments in the past 15 years. He worked at the first XP company in London and co-authored the first paper on mock objects. During our discussion about the automatic and effortful system, he revealed that as a programmer, he has to write bad code for others to practice refactoring. However, he noted that as he has become a more skilled programmer, it has become increasingly difficult for him to write bad code.
00:07:10.800
When reflecting on problems, he finds good code to be immediately obvious; it leaps out effortlessly at him. Conversely, it's a struggle to produce bad code, as he has to consciously suppress his automatic instinct for good code. My goal became to emulate him—wouldn’t it be wonderful if our automatic system naturally produced good code, and we had to make an effort to write bad code?
00:07:38.720
To accomplish this, I've focused on training the automatic part of my brain. This talk will explore how my automatic system can improve, similar to how veterinary students at the University of Illinois are trained.
00:08:01.600
In veterinary medicine, assessing whether an animal is bright or dull in addition to taking its temperature or blood pressure is crucial. This distinction aids diagnosis and is perceptive. The surprising fact is that veterinarians perceive an animal's state with the same clarity as noticing a green sheep; yet, they do not start from that level of perception. They require training to achieve this recognition.
00:08:36.880
One key aspect of their training is naming, wherein they associate specific words with groups of animals. The process takes significant repetition, as all forms of learning do. However, the interesting part is their realization of distinction isn’t achieved through the effortful part of their brains. Students won’t be shown a bright cow and asked to list its characteristics; nor would they modify a dull cow to become a bright one. Engaging the systematic, analytical part of the brain slows the learning process and is counterproductive.
00:09:20.160
Instead, the student is presented with different animals, makes judgments about their brightness or dullness, and receives corrections based on their evaluations. This cycle repeats until the students recognize these distinctions without conscious thought. Asking a veterinarian how they differentiate bright from dull animals would strike them as a silly question; the recognition process is instinctive.
00:10:03.360
Analogously, in programming, we have concepts like code smells—issues in code that imply it could be improved. These code smells bear more resemblance to veterinarian diagnostics of health (e.g., brightness) than the concrete metrics like high blood pressure. One of the most critical code smells is duplication.
00:10:44.160
The rudimentary view of duplication focuses solely on finding literal repetitions of text; however, this only scratches the surface of what skilled programmers perceive. Programmers who are better than I can identify types of duplication that escape my notice, and they often refer to even better programmers who discern duplications that they cannot see. This intricate understanding ultimately enhances their ability to improve code.
00:11:17.760
This parallels the relationship between experienced veterinarians, who likely identify a sick animal differently due to their prolonged exposure. For developers, we often revisit the same code over and over. Time passes, and with each revisit, we enhance our ability to identify issues like duplication or other code smells.
00:12:00.320
Often, I leave a piece of code feeling something is slightly off, although I can't pinpoint what it is. After stepping away and returning later, I may suddenly understand. It's a process of developing my perception incrementally.
00:12:40.320
Thus, I assert that the best way to learn how to write good code is to repeatedly revisit bad or borderline code until your automatic system becomes better at identifying those flaws. However, it can be challenging to justify the time spent revisiting code simply for professional development. Fortunately, in my role at GetSet and through the practice of Extreme Programming (XP), this method perfectly aligns with the philosophy.
00:13:24.080
Extreme Programming is fundamentally about learning as much as it is about performance. One feature of XP that facilitates learning is the concept of 'You Aren't Gonna Need It' (YAGNI). Its philosophy suggests that you shouldn't write code you don't need because future use cases are often unpredictable. Soon after reverting to previously written code, you can significantly improve your skills as a programmer by viewing it through an enhanced perception.
00:14:09.840
I emphasize that as programmers, we are situated within our environment, and our physical and social contexts matter. A programmer I once met conveyed a rather extreme viewpoint: "My body is just a thing that keeps my brain from falling to the ground." Most of us appreciate the necessity of our peripherals, such as large monitors or ergonomic chairs, yet they aren’t universally essential.
00:14:52.959
As humans, we are embodied and social beings, and our surroundings significantly influence the tasks we perform and the learning experiences we encounter. My next focus is a concept called 'Set and Setting.' I encountered this phrase while reading about jazz musicians and intravenous drug users, both of whom utilize their environment to shape their experiences.
00:15:45.600
Originally associated with psychedelics, Timothy Leary popularized 'set and setting' to explain the variance in drug experiences. Leary observed contrasting results: while the CIA viewed LSD as anxiety-inducing, his own experiences suggested otherwise. His conclusion emphasized that drug experiences depend on not just the substance but also the user’s mindset and environment.
00:16:25.119
The 'set' refers to an individual's internal state—personality, expectations, mood, and preparation. In contrast, 'setting' encompasses the external environment—both physical and social aspects. The culture in which Leary operated was vastly different from that of the CIA, which accounted for their differing experiences.
00:17:10.080
To illustrate, I'll show you a video of tango dancers performing in an unclear setting—an average gym floor. Despite the surroundings, they'll establish their mindset, which is crucial in any performance context. Watch for how they craft their set, along with appreciating their movement.
00:17:57.840
(The video demonstration is presented here. Following the demonstration, I’ll provide insights into the relationships between tango, test-driven design, and baseball's fly-catching techniques.)
00:22:15.520
In wrapping up my talk, I want to express gratitude for your kind attention. I recognize there's been less laughter than I anticipated, but your support is appreciated.
00:22:57.920
In my professional capacity at GetSet, I'm employed as a Closure programmer. It was Glenn Vanderberg who introduced me to Closure, and he's the last speaker of this conference. I also authored a book called "Functional Programming for the Object-Oriented Programmer." It’s available as an eBook through Leanpub, and since you've been great, I want to offer a coupon for free access.
00:23:40.720
Finally, the coupon code is 'rocky', but please refrain from sharing that on social media. Thank you for your time and attention!
Explore all talks recorded at Rocky Mountain Ruby 2013
+13