Bias in development and why it's dangerous

A short story about Alice.

Alice is happily coding away in scope of her Javascript task at work. When suddenly she has to loop over an array. Alice thinks for a bit about her task:

• She needs to do some side-effects (e.g. call an API, mutate an external object) with every item in the array
• She doesn't need to mutate the original array
• There is no need for a new result array

Naturally she dislikes for loops and chooses

Array.forEach

Array.forEach

This seems to be somewhat of a ubiquitous, unspoken agreement amongst JS developers from what I've heard and also as seen in just some of the links found with a

map vs forEach speed

• https://codeburst.io/javascript-map-vs-foreach-f38111822c0f
• https://jsperf.com/loop-vs-map-vs-foreach
• https://github.com/dg92/Performance-Analysis-JS - which I frankly don't understand

This made me quite curious because it made no sense to me. As far as I knew

Array.map

Array.forEach

In science a theory makes sense only if it is falsifiable. Meaning that it can be disproven. It’s like the white and black swan theory, where if you say “all swans are white”, your theory can be disproven by finding a single black swan regardless of how many white swans you’ve seen before that.

Thus, I created this CodePen example which turned out to be that black swan. But also it has confirmed my fears. The fears that some opinions we, developers, have about our programming languages are biased and unquestioned.

Now this is hardly a surprise. People are naturally predisposed to being biased. Their fundamental world depends on it. Otherwise everything a person knew and believed in comes crushing down.

Returning to my CodePen example, on average these are the results I received:

Chrome Version 77.0.3865.90 (Official Build) (64-bit)

Safari Version 13.0.1 (14608.2.11.1.11)

The difference between my tests and other perf tests is that in the other perf tests

Array.forEach

Array.map

Returning to Alice, she won the holy war against the "senior" developer and forEach was used in her case.

However, this is not unusual for teams to get stuck discussing topics they are frankly yet unqualified to discuss. I say unqualified because even if many of us would like to say we know our languages from A to Z, we still often have not enough data to back up our claims. Or even worse, we have no data at all.

Such scenarios are dangerous because more experienced developers pass their opinions to less experienced (or simply gullible) developers. All of this increases the lifespan of an opinion regardless whether it's wrong or right.

An opinion that is wrong might hurt you, the company and users of your product. Let’s say you believe that the security of your app is perfect because you followed the best practices. The next day you find out about a security vulnerability that was unknown to you because the framework you’re using works not the way you thought it did. Oops…

Be sceptical. It’s never too early to question things. In fact, in a company, that’s what good management wants.

By the way, did you notice that a simple for loop was way slower than any of the other loops? ~90–95% slower to be exact. Weird, huh? I yet haven’t managed to understand the reason for this, but I suspect that I accidentally created a bias example towards a simple for loop. Now go out and scream from the rooftops:

For loop is dead. Long live for loop.

In conclusion, what I'm getting at is this:

• Test your claims
• Test your data
• Test what others claim
• Test the data and results of others
• Different contexts create different results. These results, if generalised, might create a bias.

In case of programming, understand also that compilers are getting better and better at managing you code. In this case - loops. Most real life projects will never have a performance bottleneck because an

Array.map + Array.filter

Array.reduce

Instead it's more important to focus on having guidelines instead of waging war against your teammates.

“Understanding others needs to start on an individual level — understanding yourself. Knowing how easy it is to make these kinds of mistakesallows us to be more compassionate when seeing others encounter the same issues”

Happy Coding!

P.S. This article expresses no preference towards the functions, methods used here. It is purely about human bias and why it's dangerous.

P.S.S. If you see a clear bias in my CodePen example or that I'm wrong in something, I'd be happy to hear why. Also, that would only further prove my point of how easy bias occurs.