How the StreetLight Bias can affect your debugging skills?

Do you often find yourself stuck when you're trying to debug codes? The Streetlight bias might be an explanation.

How the StreetLight Bias can affect your debugging skills?

The brain has a strange effect. The moment I start working, it wants to distract itself with something easier to do or some kind of novelty. As I start writing the first draft for this article, I feel the urge to check my Twitter account.

Not willing to sacrifice my limited time, I start a Pomodoro timer of 25 minutes and start writing down.

In this post, I am going to write on how cognitive biases - especially the StreetLight bias - affect our productivity and decision making as software developers.

What is a Cognitive Bias?

A Cognitive bias is a way of thinking that is different from what we normally do. They are patterns of thinking that deviate from our rational judgement. You can refer these biases as blind spots that affect our decision making.

A cognitive bias (e.g. Ariely, 2008) is a systematic (non-random) error in thinking, in the sense that a judgment deviates from what would be considered desirable from the perspective of accepted norms or correct in terms of formal logic.

In addition, our rational way of thinking is also affected by our emotional states, leading to many of these biases which does not otherwise occur.

Likewise, these biases affect our decision making when programming and debugging codes.

Streetlight effect

The streetlight effect, also known as the drunkard's search, is an observational bias occurring when people only search for something where it is easiest to look.

So how does this bias affects us developers when debugging codes?

On first encountering a bug, we tend to search where it is easiest to look and not necessarily where the bug most likely is - unless we already have a clear idea of it's origin.

For example, when I have a bug when coding in JavaScript on the browser, the first thing I look is the console. This often gives me enough information on the stack trace, and the file in which the issue arises. I do this because this is the easiest place to start looking and is actually an efficient approach for most minor bugs.

When working with TypeScript and/or SPA frameworks such as VueJS, however, the error is often not as simple. The compiled codes are different from the ones I write. For instance, I often get the error that parameterName has a type error in file js - while I work with TS files.

The biggest problem with this bias - is you can become too focus in the details - that you lose sight of the bigger picture.

To illustrate, thinking that TypeError e is the problem, I waste my time searching on the Internet for the issue while in reality, I have forgotten to install important libraries.