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 . However, Alice is not the senior developer in the team and during a code review of her task, the local "senior" developer starts a crusade sworn to never ever use again because it is the slowest of all loops. 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 search on Google: map vs forEach speed https://codeburst.io/javascript-map-vs-foreach-f38111822c0f https://jsperf.com/loop-vs-map-vs-foreach - which I frankly don't understand https://github.com/dg92/Performance-Analysis-JS This made me quite curious because it made no sense to me. As far as I knew is basically with additional functionality. I had to investigate. 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 , 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. white and black swan theory Thus, I created this 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. CodePen example Now this is hardly a surprise. . Their fundamental world depends on it. Otherwise everything a person knew and believed in comes crushing down. People are naturally predisposed to being biased 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 is made to mimic what does. In other words, an improper use of functions and a generalisation of results. 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, still often .  Or even worse, we have no data at all. we have not enough data to back up our claims Such scenarios are dangerous because more experienced developers pass their opinions to less experienced developers. All of this increases the lifespan of an opinion regardless whether it's wrong or right. (or simply  gullible) 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 . Oops… a security vulnerability that was unknown to you because the framework you’re using works not the way you thought it did 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 These results, if generalised, might create a bias. Different contexts create different results. 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 was used instead of a 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. allows us to be more compassionate when seeing others encounter the same issues” Knowing how easy it is to make these kinds of mistakes 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.

CodePen

Bias in development and why it's dangerous

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How I Got Myself FIRED as a Software Developer and How You Can Do It Too

How To Monitor Your API Server

How-to: Website Benchmarks

How To Write Benchmarks In Golang Like An Expert

Why you should check the performance of your code?

Top 10 Crypto Trading Biases and How to Fight Them

How I Got Myself FIRED as a Software Developer and How You Can Do It Too

How To Monitor Your API Server

How-to: Website Benchmarks

How To Write Benchmarks In Golang Like An Expert

Why you should check the performance of your code?

Top 10 Crypto Trading Biases and How to Fight Them

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps