UP | HOME

Reading is hard

I remember one of my early childhood experiences - when I tried to read a book which was not a kiddie book (a books for “adults” in the general sense) I got this very peciliar problem.

I already knew how to read individual words morpheme by morpheme from a page and to pronounce the result in my mind, but the problem was that I do not know this word (its meaning).

The same, of course, applies to a student of a foreign language - one might know how to “load” the world into one’s mind, but has no definition or association to anything already known. The “label” has no associated meaning (socially agreed upon or just from a dictionary).

And this very problem arises even more acute when one tries to read some source code. The “known” vocabulary of the reserved keywords of a particular language tends to zero, compared with the all the possible language constructs, which are potentially infinite.

The number of familiar common idioms is about a dozen, and the number of recognized syntactic sugars and commonly used “design patterns” (at a higher level) is also about twenty at maximum.

Everything else is on a page is unknown and even unfamiliar, and this is the real problem.

There is no shortcuts around knowing, understanding and becoming familiar first. This is why most of the beginners and amateurs fail - they got stuck (and eventually give up) because they are not familiar with, do not understand and do not know their problem domain well.

They know how to write the code (read) but do not know what to write and why (the meaning of words).

Now pay attention. This is the major cause of failures - not knowing what to write and why.

I also remember the experience of being stuck and overwhelmed while watching some classic programming lectures from MIT, which were full of mathematical concepts.

Just imagine, studying in a foreign (second) language, of an unfamiliar subject, with lots of cross-discipline references to unfamiliar concepts – most of the words are vague, and there are even some gaps due to unfamiliar words of the foreign language. One has be overwhelmed, I guess.

The solution? Watch it many times, until there are no gaps in understanding, and this is the only way through a programming project too. There must be no gaps in understanding of the particular problem domain before one could write any code (knowing the whats and the whys – the captured principles which govern or describe the underlying causality).

Yes, there are some “agile” methodologies, where one supposed to gradually refine one’s knowledge and understanding. This, of course, is a way too general idea and it “works” only in a theory or in the minds of Chuds.

To know some domain one has to somehow extract and internalize the fundamental underlying principles first. If one is a complete newfag, there is no way to know what is relevant or even approximate “weights”, leave alone what is the most fundamental.

I remember my early shitcoin trading experience – tons of spoken and written bullshit, which all seem to be “right” and “important” in the beginning. It takes an actual expertise (acquired by all the pains of trial-and-error iterations) to call the bullshit.

So, there is a well-known meme that a programmer spends only about 10% of the time actually writing the code. This is absolutely true. Getting familiar, developing the right, your own understanding (not what the others are saying or writing in low-effort “for profit” crappy books) and eventually knowing the whys is the remaining 90%.

Next time when you would find yourself staring blankly at an empty page in a code editor, do realize that this is not a programming language or libraries problem, but the lack of the domain knowledge and lack of the right understanding (of the underlying causality, principles and whys and hows) in general.

This, by the way, explains why the demand by employers for writing more than 10 lines of (fully-debugged, properly tested and committed) code per week (yet another well-known meme) is unrealistic. Otherwise one would get a low-effort crap, poorly designed, not even close to an optimum.

Remeber, that reading is hard, and good reading is slow, and require to pause, think and take notes. There are no royal road to good programming or math.

Author: <schiptsov@gmail.com>

Email: lngnmn2@yahoo.com

Created: 2023-08-08 Tue 18:41

Emacs 29.1.50 (Org mode 9.7-pre)