Bruno Baketarić
1 min readJun 22, 2017

--

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.

--

--

Bruno Baketarić

Ex-Dev & Ex-Head of ... now Agile Coach @ SAP. I draw from lean, agile, kanban, complexity theory, systems thinking and social sciences. Opinions are my own.