Let's face it, the book on programming sucks. These general books on distributed systems, data science, and so on can be read endlessly. But with rare exceptions, practical language / framework / DBMS / toolbox guides have something in common. The animal on the cover, examples of artsy applications, they are so easily forgotten, so banal, so ... they do not teach anything.

I think I finally understand why I don’t like them. And not only because they teach skills that will soon become obsolete. This is their pedagogical approach as a whole. The learning algorithm seems to be this: write these programs, where we say everything that needs to be done, and now you know this language / framework / database / toolbox. The main thing in these books is the long code listings that the reader must reproduce. Here is an example from one of the best books in this category .

class User < ApplicationRecord attr_accessor :remember_token before_save { self.email = email.downcase } validates :name, presence: true, length: { maximum: 50 } VALID_EMAIL_REGEX = /\A[\w+\-.]+@[az\d\-.]+\.[az]+\z/i validates :email, presence: true, length: { maximum: 255 }, format: { with: VALID_EMAIL_REGEX }, uniqueness: { case_sensitive: false } has_secure_password validates :password, presence: true, length: { minimum: 6 } # …  30 ... end 

Traditionally, there are two ways to explore this page:
')

1. Enter each line of code manually.
2. Copy the code from their site, maybe play around and make small changes.

In the first case, as in the lectures, the code goes from the page of the book to the screen of the reader, bypassing the brain. The second option is how to try to assemble cars by disassembling the seat belt and stereo: you just play with small pieces. Both options are not suitable for training.

An experienced mentor will not teach you a page with a code. But we have such books. How to read them so as to follow the principles of learning? We will understand.

Mental images

According to C. Anders Eriksson in his book Peak , expertise is the process of building mental representations (mental images). We can see them, because the minds of experts store knowledge in a compressed form. A musician is able to memorize a page with a melody much faster than a page with random notes. An experienced chess player, who was told to remember the position on the board, would do it much better than an amateur, but if he makes a mistake, he will confuse a whole group of pieces.

This is possible because in music and chess composition there is a structure, because of which they look completely different than a page of random notes or a random arrangement of pieces. Technically speaking, they have lower perplexivity than random noise. Thus, although the English alphabet has 26 letters, Claude Shannon showed that the information content of the English language is about 1 bit per letter: knowing the random beginning of a paragraph, people guess the next letter in about half of the cases.

That is why an experienced programmer can read the code as fiction, dwelling only on unusual bits, while the novice puffs, reading line by line. That is why a smart auto-completion tool guesses a long code sequence from the first pair of lines. Better mental images simply make code easier to understand.



(How do these mental images work? My colleague Zenna Tavares claims that these are data structures that are sensitive to distribution ).

This is exactly what the “just enter the code” approach lacks: nothing forces your mind to present a program as something better than just a sequence of characters. However, if you force your mind to do this, then you quickly grasp the essence of the concept. Here is an idea 200 years ago how to achieve this.

Benjamin Franklin Method

I don’t know what is more impressive: that Benjamin Franklin became a star in everything, from politics to physics, or that he didn’t need modern educational methods, such as schools, teachers or StackOverflow. Instead, he discovered a powerful method of self-study. Let him tell himself (or you can read someone else's brief retelling ).

Around this time, I got into the hands a scattered volume of the "Spectator". That was volume three. Until now, I have not seen one. I bought it, repeatedly re-read from cover to cover and was from him in complete admiration. The syllable seemed incomparable to me, and I decided, as far as possible, to imitate him. To this end, I took some essays and jotted down the meaning of each phrase, then I put them off for several days, and then tried to restore the text without looking at the book and stating the meaning of each phrase as fully and in detail as in the original, for which I resorted to expressions that seemed appropriate to me. Then I compared my “Spectator” with the original, found some of my mistakes and corrected them.

-Benjamin Franklin. Autobiography

This process is a bit like the human version of the auto - encoder in machine learning. The autocoder is a neural network that attempts to reproduce at the output the same data as it was at the input, but passing through an intermediate layer that is too small to fully represent the data. During this procedure, he has to learn a more compact representation of the data. Here, a cluster of dendrons in your head acts as a neural network.

K. Anders Eriksson likens the method to how the artist practices, trying to imitate some famous works. A mathematician learns to prove theorems on his own, without reading a book or a scientific article — even if he fails, then it will be easier for him to reduce the proof to basic insight. I used this process to better understand graphic design; it was like laser vision correction.

But with regard to books on programming, the basic idea is especially simple, and at the same time effective.

How it works:

1. Read the book as usual. When you get a sample code, read it.
2. Close the book.
3. Try typing the code.

Just right? But try and see how you have to study and understand the structure.
Everything is very similar to what you did before, only with better training.