When Programmers Don't Understand Code, Don't Blame The User

In this example, I blame the design of JavaScript. It's certainly possible to write bad code in any language, but I take exception to the gratuitous footguns.

I do value readability highly. Code is for humans, not just machines, or we'd still be writing programs in binary.

On the other hand, there really are basic things that you are supposed to know. Not being allowed to use them might make your code more comprehensible to a beginner, but it will also make too much code. You shouldn't have to reinvent the standard library.

There are certain elegant concepts like sets, or monads, or recursion, which a beginner might struggle with, but working around not having them when you need them probably isn't worth it.

I think this lesson extends behind the scope of programming, even behind the more general scope of technology. We should not be too humble before complicated, hard-to-understand things. We should not be too quick to assume the fault is in our inability to comprehend them. We should always consider the possibility that it's their fault being needlessly complicated, or even just plain nonsense.

I've seen some essays (often in the area of philosophy and/or religion) that - I believe - try to take advantage of that utility. They support their argument with cryptic, cumbersome and confusing reasoning that seem to me like an attempt to force their would be challengers to give up on the discourse for failing to understand it. Their supporters, of course, can remain - they are not trying to disprove the argument, so they don't really need to understand it.

To fight this mentality, we need to give more credit to ourselves. Is the person making the argument smarter than us? Maybe. Does their intelligence exceed our own so much that they can create coherent arguments we cannot understand no matter how hard we try? Very unlikely. Maybe not outright impossible, but the probability is low enough that we should insist on the argument being flawed even when they try to convince us we simply fail to understand it.

The language syntax and semantics are no longer the only part of its interface to the user (=programmer). It is also the IDE with all its syntax highlighting, contextual jumps and lookups, and often inline type annotations. So how understandable a piece of code is depends to a big degree on this kind of tooling. What your 'this' or 'that' refers to is much easier if you just have to hover over it and the IDE will show you. 

this is the context, it is necessarily contextual as opposed to being lexical. The old idiom is using var self = this; in the preamble of a function that wishes to expose it's context to functions it defines. The current idiom is using arrow functions whose context is their parent's context

Javascript is indeed notoriously opaque in terms of assigning "self" to a function call. There are multiple ways to do it more explicitly, including prototype inheritance, using Function.prototype.bind() etc., all being workarounds for passing and calling "selfless" methods. So yeah, I agree with your main point.

I got reminded how some practises that other languages use makes these kind of worries happen less. For example it migth feel stupid to that one ends up naming every first parameter of a class function "self". but in a situation like this where within the forEach inline function you could plausibly have different level self-reference you could avoid it by deliberately using a non-standard name such as "me".

I do think that as a programmer the line is good to make the code more readable and mitigate the confusing design of the language.

I also tripped ovder a little whether we are talking about the users of the program we are writing but here we are referencing the programmers being the users of the language or considering fellow programmers as users of our code as readers.

It seems likely to me that there is good, well-designed code that is hard to understand by the very nature of what it is or what problem it is solving. What percentage of all hard-to-understand-by-smart-and-competent-people code is that kind and what percentage is the kind you describe is probably the key thing you'd want to know.

Once you know that then you can know what to do when investigating code you do not understand.

The best thing I can come up with is "ehh, probably most hard to understand code is badly designed code?".

(As an unrelated aside, prompted by me just now closing this tab: Without consciously thinking about it I always try using my code editor hotkeys while editing text in non-coding contexts, and one of those hotkeys closes my browser tab!)

I started programming in Clojure this year, and it's the only programming language I've ever used that enforces round corners and soft edges. It's very readable (once you get used to the parentheses). It's functional. Data is immutable and persistent. It creates kind of a safe environment that has made programming fun again (for me).