Running your brain bug-free when designing software

August 2020

You need to consider quite a bit when creating software: requirements, security, performance, ensuring your brain runs smoothly without glitches that may introduce defects early on.

After all, your brain is a computer, writing instructions for a non-biological computer. The brain is a sneaky instrument with the mind (ha!) of its own, so it helps to understand what you are up against.

The Einstellung (i.e., "attitude" in German) effect is a fascinating phenomenon that doesn't make logical sense.

If you are trying to address a problem that is familiar to you because you solved something similar a few times before, your problem-solving skills can be worse when comparing to the utterly inexperienced person. You may end up picking the least efficient solution, not even considering a simpler or better alternative. If the problem is similar, but with a twist, you may get stick altogether, not able to come up with a solution at all - declaring, "This cannot be done!".

The experiments in proving this effect were performed by various researchers across multiple domains of knowledge and with different age, gender, and education level test groups, always with the same results.

How could it be? And how do you fight it?

Cognitive Bias

Our brains are good at filtering out information they deemed unimportant and concentrating on patterns. Ignore the differences, focus on similarities, and come up with a solution quicker.

Great for survival - once you escaped from a hungry bear a few times, it would be a dangerous waste of resources to stop and consider alternatives.

The efficiency of recognizing the pattern increases as more experience is gained. It may take you a long time to write a first mobile app where people can share pictures, but the second one will be written much faster because you've done it before, selected all required technology and libraries, and drew the design. This efficiency is what makes mid-level software developers faster than the beginner.

The downside is once enough evidence is accumulated, and a viewpoint is formed, it's tough to notice new facts and change your opinion. If you have written the first three mobile apps in a native framework, the fourth one will more likely be native as well - regardless if this is the best approach from the project requirements standpoint.

How to outsmart cognitive bias?

Always try to come up with at least one alternative solution. Pay attention to minute details, and notice the differences. Experiments had shown that after a certain level of expertise, the Einstellung effect is reduced, perhaps because extensive experience means exposure to a broader set of problems, making it easier to notice subtle differences in situations.

Mechanical thinking and brain plasticity

There are also physical reasons for cognitive bias and the Einstellung effect.

Just like your muscle memory allows for tasks to be performed automatically, without thinking about each step, mechanical thinking automates the thinking process. You see the problem, and immediately start acting, following the simple loop - without actually thinking or asking yourself, "Is this still the correct solution"? Or, in other words, you start writing code immediately after glancing over requirements.

Our brains, just like the ML models, are continually training and rewiring themselves. Once the pattern emerges and is repeated a few times, a new connection is formed, making it faster and more efficient to follow with a minimum amount of resources spent, instead of firing up problem-solving synapse.

"Why am I doing this" helps to recognize the episodes of mechanical thinking.

Einstellung Implications for learning Software Engineering

"Transfer and Einstellung Effects Of Examples On Devising Computer Algorithms" was written by William Goddard (1963) as part of a Master's Thesis.

The paper looked at the use of examples when teaching students to create computer algorithms for solving easy and hard problems. The research was brought up by the observation that providing students with examples on how to solve the problem would improve their initial progression but did not translate into the ability to solve harder problems later on. The opposite was true - when no solutions were given, initial growth was slow, but with the better success of transferring obtained problem-solving skills to a much complex problem.

While the experiment was limited in scope and time, the author concluded that providing examples when teaching algorithm development hinders skill advancement and does not increase the number of students who can solve difficult problems without assistance.

This conclusion was refined in "The Impact of Examples on Creative Design: Explaining Fixation and Stimulation Effects" by Agogué et al. (2011). That paper presented two different types of examples: restrictive (that do not change anything about the object) and expansive (that introduce unexpected quality or attribute). While restrictive examples did create the fixation, exposure to expansive ones resulted in better solutions.

The conclusions bring up an interesting consideration to the discussion on preferred learning styles. Do you prefer to work through the examples or figure out things yourself?

Forewarned is Forearmed - Outsmarting the brain

  • Knowing about the Einstellung effect reduces the effect. Being aware that your brain may fixate on a solution that is not the best in the given circumstances makes you a better expert
  • Having more experience helps, but the dependency does not appear to be linear. Being humble is important.
  • When a problem doesn't want to be solved, going for a walk around the building, switching to a different task, or rubber ducking breaks the fixation on a pattern, jump-starting the creative flow.
  • Practicing mindfulness helps to reduce fixation brought on by experience ("Mind the Trap": Mindfulness Practice Reduces Cognitive Rigidity by Greenberg et al(2012)).

Approach a known technical problem with an open mind - you may have done something similar a few years back, but is this solution still the best industry practice? Asking yourself the "Why" question helps with not seeing every problem as a proverbial nail and churning up the same exact applications year after year.