The original was published on my blog on 07/11/2020. If I understand correctly, this is not a problem.
I believe that software development is very much about programming in pseudocode. If you have provided pseudocode, then translating it to Python, C, whatever is not a problem. The main difficulty lies in this conceptual activity, and not in coding. You need to know how to approach certain issues. Modularity, abstraction. Flexibility, reliability, simplicity. Design patterns. Unit testing. Yu know.
There is in the world a course "Structure and Interpretation of Computer Programs" (hereinafter SICP), which is positioned as an introduction to Computer Science and was previously used at MIT to teach freshmen. Two years ago, I gladly mastered a course of lectures on it. and took up the book. First, I'll tell you about the good.
The text tells about things that are very far from my daily work and allowed me to take a fresh look at programming. Functionality is a whole world that lives by its own laws. The Lisp language is very different from the C language I am accustomed to by insane flexibility due to dynamic typing, automatic memory management, the ability to redefine anything at runtime. I have developed a more versatile idea of how, in principle, you can solve different problems. Speaking in a chess language, I have greatly expanded my repertoire of homework that comes in handy in my work (albeit not every day). Exercise made my brain work (at times very intensely), rethink and systematize earlier knowledge. In general, studying SIKP made me a better developer, broadened my horizons. I am sureI began to look at different things with a more systematic and mature view.
The book constantly prompted me to think, for this she bows deeply. I deeply realized things that everyone seems to know, but which, therefore, everyone is too lazy to mention. For example, that all software is made simple at first, and then inevitably becomes more complex in order to improve performance. The user doesn't care how many lines of source code are inside, but speed matters.
What about specific effects to work with? I became better at seeing shortcomings during code review (first of all, my own code). Loved small functions, preferably as general as possible. I began to practice the careful and appropriate use of macros - sometimes in C you can carefully do something not according to the rules, and everyone will only win from this. The experience I gained from doing the exercises in the book helped me with some of my work problems.
But this is one side of the coin. Another is that the approach of this course to learning can be expressed in the English phraseological unit "sink or swim". There is a crossbar in front of you, next to it is the task: to pull up 10 times. In principle, this is enough to complete the task, but this approach cannot be said to be pleasant. I would say he is quite exhausting! You are thrown into battle half-prepared, and you learn part of the material not from explanations, but from your mistakes. Perhaps this is an acceptable way of teaching highly motivated people, but he squeezed me out as a lazy person. I could hardly endure it for 3 out of 5 chapters (sometimes I paused for several months!), Did the exercises in them from start to finish, but it seems that my patience is exhausted.
For example, the book doesn't say a word about how to organize your workflow. There is not even a rough consideration of such concepts as "debugging" (it is specific here), "IDE" (they are specific here), "unit tests", "splitting into files for reuse". There are fragments where a certain complex system is being developed, which will be fully ready only by the end of the chapter, and tasks appear after each paragraph of the text. Those. strictly speaking, having read up to page N, in some cases you cannot solve the problem from this page without dragging the code from the subsequent pages. The code must be dragged carefully, because the notes may discuss non-obvious subtleties, and sometimes some code is given as an example of a broken idea. This is annoying! Yes, it's just like in real life - you need to define the task yourself, look for something on the Internet,but damn ... this is a tutorial! I am full of difficult tasks at work, and maybe the authors should have been more pedantic about the text? Okay, I'm a professional pogromist with fast internet access, but what about an MIT freshman in the eighties? I'm sure it's not sweet ...
Let me emphasize the main advantages of the book: it allows you to gain personal experience, fill your own cones, and think about complex problems in general. The disadvantages are directly related to them: it is complex and often gives you few clues to understand something. For example, if you have some kind of combat experience, then you know that code without unit tests cannot be called a solution, but the book will not tell you about it. You have to get to this yourself! What did you think? Well, or I'm lying, the book will tell you about it, but in the most sadistic way. You will have the next task based on the previous one (this is often there). If you have previously earned one test case and you decided “Ok, let's go further!”, Then around the corner you will be happy to debug the solutions of two tasks at once. Probably, when this happens several times, you will realize that you are doing something wrong. The main thing,so that at such moments you do not give up the course, but understand, then everything will be fine!
Another annoying feature of the text: tasks (again, as in real life) are sometimes not well defined. I was doing an exercise the other day, in half an hour I sketched out a solution, began to re-read the problem statement. It turned out that if you think pedantically, then I fulfilled it 95%, spending about 40% of the effort. Most of the dudes I checked with did the same. One did it fully, but used a hack from another Lisp interpreter. I got upset and spat, having lost motivation to continue in the near future. Once again I will tell you the essence of the problem: there are tasks in which everything is solved simply and logically, but only if you are not strict with yourself. So in real life, I understand, but I had different expectations from the textbook. When you do the exercise in your free time and check yourself, you want to solve the problem 100%,not “good enough for the current iteration”.
The problem with unit tests is actually the same kind. Sometimes you need to sweat a little and think in order to simply implement them into the system. I know that there is nowhere without them, but simpler guys just sketch out solutions without checking and move on! The stricter, more attentive, more experienced you are, the more difficult tasks become for you. Sometimes just at times! This is demotivating, because here, unlike work, they do not praise or pay for it, and the iterative approach is poorly applicable. Knowledge and skills, useful in real life, hurt hands when solving student problems!
It is worth saying that the book contains a lot of math. Solving the exercises, I understood the beauty and power of this science, but sometimes it was hard for me precisely because of these specific issues, only indirectly related to the problems being solved. It's just that the authors decided to show something with an example of integration, so remember and botay!
In general, I do not regret that I fit into this adventure, it was useful for me. However, I recommend other people to look for something better. For example, on the basis of the SIKP, taking into account his mistakes (as they say, I did not check), a course "How to Design Programs" was recently made. I suppose I should have coveted him too, but the time will not be unwound.
PS Peter Norvig wrote a wonderful review of SIKP .