programming, slow

Software development is generally considered a thinking person’s activity. Word thinking usually implies deliberate pondering and careful reasoning. However, there’s a clear-cut difference between thinking fast and slow (coined Systems 1 & 2, respectively). Thoughts in the first happen automatically, and in the second, more purposefully.

Keeping the systems completely separate would require some level of psychopathy. Too much of analytical, emotionless and autistic thinking can suffer from a similar problem to “paradox of choice”. There, no decision is achieved because of the lack of impulse or intuition. Without any intuition or plain risk taking, one can succumb to a circlejerk of useless comparison and speculation.

Programming is largely about managing complexity and being aware of the so called known unknowns. This means that in addition to the complexity of the software’s known knowns (how it works and what it’s made of), the programmer should also be aware of the it’s potential vulnerabilities, flaws and unfinished or unoptimised sections. There’s always going to be a point where one has to stop optimising and reducing/generating complexity. This depends on the software’s domain, where the severity of a catastrophic failure can vary significantly.

That systems thinking is so hot right now. Oversimplified, it is about viewing things as a whole. It encourages the thinker to consider the cumulative effects of each smaller part of a whole and discourage optimising them separately. I like to think of it as a process of slowing down, stepping back and looking at the big picture. To have a clearer view, it’s beneficial to be aware of them mind clouding biases and errors in thinking.

some biases in thinking when programming and designing #

Mentioning, reading or hearing something immediately anchors the mind to it. It would be a good idea to have a period where one can think before exposing their mind to outside influences. Fore example, think of planning poker and the revelation of each estimate simultaneously.

The easier something is to recall , the greater it’s effects and consequences usually seem. This can have the unfortunate effect of stacking more and more experience on one subject, and inadvertently generating specialisation in it. It’s like the opposite of thinking outside the box.

In a team environment, presenting choices in a different way can have a huge effect on which decisions the team will make. One can also fool themselves by deliberately thinking in a fixed mindset.

Programmers are generally thought of being overly optimist and overconfident in giving time estimates. There’s a tendency to ignore unknowns and to not account enough time for unexpected problems. The larger the problem, the harder it is to understand it’s complexity. That is why projects and problems are important to split into smaller chunks.

Falling for sunk costs in development and especially in planning happens often. There’s an emotional investment in whatever you spend resources or effort on. It is emotionally difficult to discard that project, and instead one is prone to invest even more of the said resource on it.

detection #

There are clearly several more biases, but the point is to not necessarily catalogue or memorise them, but being aware of one’s own behaviour. This is where introspection and self-criticism become priceless. Objective criticism and feedback can also be invaluable, depending on their source.

Proper retrospection on both personal and organisational level will optimally provide critique from several viewpoints and provide action points on self-improvement.

Ideas from Thinking, fast and slow