I recently picked up a copy of Daniel Kahnemann’s Thinking; Fast and Slow. It’s an excellent book describing, amongst other things, the many ways in which our brains process signals and inputs from our environment. I’m talking here about various stimuli which affect our behavior both consciously and subconsciously.

In processing these stimuli, he proffers that our brains have two processing modes which he personifies as System 1 and System 2. System 1 concerns itself with simple, lower order cognitive processing: facial recognition, hazard perception (in most people); the kind of thing we probably consider intuitive thinking. System 2 is attributed with tasks which require effortful mental activities: computational, logical processing.

Activities which are likely attributable to System 1’s processing might include resolutions to questions such as:

• 2 + 2 =
• Detect hostility in a facial expression
• Detect that one object is further away than another

System 2 comes into play resolving problems of the order:

• 27 x 42 =
• Focus on the voice of a particular person in a noisy crowd
• Check the validity of a complex logical argument

It is this last point, and indeed its effortful nature, that is of interest and relevance to this blog.

JUMPING TO CONCLUSIONS; ANSWERING AN EASIER QUESTION

Kahneman offers the observation that System 1 is gullible, but an essential mechanism for allowing the brain to process information effectively; to avoid needless, effortful cognitive processing by System 2. System 1 purportedly offering suggestions which System 2 can either accept, or reject and engage higher order, effortful processing.

It is this facet that is particularly interesting in relation to software development.

At Pivotal, we practice a process we call red-green-refactor. Write a test case, watch it fail, write the code to make it pass, look for opportunities to refactor and improve based on the change you’ve just made. This process requires effortful, mental consideration at each step of the process. Over time, you begin to identify patterns which reduce that cognitive load.

The project I’m currently working on is a reasonably complex, mathematical application. As the application grows, I am finding benefit in forcing myself to recheck many of these assumptions, re-considering the mental paths which have built up as a go-to means to present a given datum to the user. With the help of my programming pair(s), this curiosity and enforced distrust of assumptions has pushed some really valuable simplifications, and kept the app flexible to change.

When it comes to code, it never hurts to ask the question why.