Familiarity Bias is Holding You Back: It’s Time to Embrace Arrow Functions
Eric Elliott

At a glance, arrow functions may be valuable. I’m not deep enough into Javascript to argue about that.

But…that whole article seems to be based on a truism: If you are familiar with something, you can catch it more easily (with less cognitive load). Of course, what else?

If you are familiar with PCRE, you can build beautiful, concise constructs that do really weird stuff — which can hardly be understood by the unfamiliar. The same applies to a whole bunch of other languages that claim syntactic sugar.

Assuming that code is more often read than written, and should therefore be optimized for readability, the real question is: What do those that have to read the code (~ your Team?) prefer — now and in the (near) future?

I’m not talking about taste here: The complexity of the code is to be determined by the cognitive load of building a mental model of what’s that code doing. If someone is unfamiliar with a particular syntax, that load is much higher, than in the other case — and therefore ppl. prefer another style.

The number of lines, characters or internal code structure are — at best — correlated to that complexity, but rarely causes. If a team has been using 4-Level-Deep if/else constructs for ages — which most of us would consider to a horrible style — it’s likely that they have also built the capability to deconstruct them.

Familiarity vastly influences the notion of complexity. There is no objectively better; there’s only an environmentally better that should drive decisions like this.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.