Почему ты учишься неправильно? Гайд по самообразованию и книгам

Okay, alright. Hello everyone. We have our юбилейный twenty-second episode of the podcast today. Today we will have an interesting topic, which I have been postponing for a long time, as I wrote in the post, well, let's say, I saved it for the юбилейный one. And we will talk about learning. We had some similar episode where we talked about how a developer should develop, but this is a bit different, yes, and somehow the episode devolved again into discussing something about tests and clean code, I think, something like that. In general, everything went off plan. But this time we have a more general topic, that is, in general, how, how someone learns. It often happens to me that when I meet a very smart person who knows a lot and much more than me, I'm always interested, how, how did he get there? Is he just learning longer, or is his progress faster? Or maybe he chooses some other methods that help him progress faster. Maybe I, I don't know, spend a month reading a book, and now Klepa, I know he'll say that you shouldn't have read the book. But we'll figure out how to act then. if, if without books, for example. Here. And actually, the topic has been long overdue, because in every, probably, of our episodes, well, or almost every one, some advice has slipped through one way or another. Like, take a course on to Tetris, read this, I often talked about Pizzold. Well, by the way, probably one of those books that is definitely worth reading, because it is practical. But we'll get back to that, but all of this was in passing. and not structured, because if someone wants to trace all of this later, this thought, they will have to rewatch all the podcasts. And here I decided to gather it all together and discuss it in more detail. And here, I'll preface this by saying, we won't discuss whether it's necessary to learn and whether a foundation is needed. This is probably the most relevant question right now: is a foundation needed or not. Now, for some reason, a lot of people are arguing about this topic, but, well, not about that now. We might touch upon such things in passing, because it's impossible without it. But the main thing is, like, how, not why or what. Here. Who do we have as a guest today? It's Gleb. I think Gleb doesn't need an introduction anymore. He's present in almost every episode. But maybe you can briefly, in case someone new joined us. Hello everyone. Well, I am currently the founder of the company Pixel Storm. We publish technical games in Russia. And I've been programming for many years, since about 1987. Such an enthusiast and all that. Well, I'll add about Gleb myself, that I worked with Gleb for 3 years and, well, wherever you look, it feels like Gleb knows everything everywhere. This is not just about IT. Sometimes, the conversation turned to some biology, mathematics, even though I graduated from the physics department. Gleb seems to be much higher than me in mathematics. So I am a generalist; that is, I know a lot about nothing or nothing about a lot. I thought the same about myself, but I am a generalist, more like a dilettante. That's about me. Okay, well, so as not to praise too much. Lesha, tell us a little about yourself. >> I was born a year before Gleb started programming. >> I, by the way, was born later than Gleb started programming. >> Yes, I'm from eighty-six. Gleb today, I wasn't a year old when I was already writing programs. So, I entered this IT world, so to speak, around 2000, at 25 years old, not so long ago, yes, I actually started programming. So it turns out I've been writing code for 13 years less than Gleb, right? Well, excuse me, I wasn't even born yet. But for some more or less public activity, where I could be seen at conferences, because since 2014, I think, I started speaking more actively. First on topics related to my work at VKontakte, where I gave many talks, and then I just started talking about Go, about optimizations, some scientific things, not related to my job anymore. Then about another company, a third company. Well, now I don't know if I can talk about it. We probably won't talk about it. I'm not working on record. >> You mean your company doesn't mind, or >> Well, yes, I don't know, yes, so, yes, yes, in the chat, maybe not on record. Well, they don't work like that in Russia anymore, right? >> Continuing to work on optimizations, Go, self-development, but we'll talk about that later. That's exactly about self-development. So, even after 25 years, I'm still looking for challenges, complexities, learning new things to avoid getting stuck in my development. I invited Lesha not just for fun, because when I was still a junior and just learning everything, I also went to conferences and saw Lesha's talks there, where he talked about all sorts of hardcore stuff, about this. I remember the first time I saw you when you gave a talk, you came on as a replacement because some guy didn't show up, and it was in St. Petersburg, and you were talking about an even more interesting topic, something about C++ C Go. >> Well, there's CGo. No, I >> Yes, CGo. >> Well, I won't advertise it yet, but there's a link to YouTube. >> Yes, what can be advertised. Lesha has a lot of talks. He collected them all on one YouTube channel. Is that what you're talking about? Yes. Ah, yes, yes. You pushed me to do it last year. Let's do it. Yes. And I made an effort and collected all the more or less interesting talks from all over the internet, wherever they were posted, because there are 20 or 30 of them. And I just uploaded them to the channel, grouped by categories, by, well, by categories, yes, just by categories, they are different. Including, there are probably the ones you're trying to remember about CGo. There were several of them. I don't know which specific one you saw then. I can't remember either. Well, as it were, everything is there, probably. And before we start, I'll remind you once again that the sponsor of this podcast, as before, is still Avito Tech. I've mentioned it several times in several episodes, but I'll repeat it again, that they sponsor the podcast, they do it very coolly, they don't influence my content at all, they don't even ask what my episodes will be about, they say: "Do whatever you want, as long as you like your podcast, we want to support it. Here's money, release episodes regularly, and everything will be fine." The only thing they ask is to briefly mention them, that they have, first of all, a cool technical blog on Habr, they have a YouTube channel, and they are waiting for you to join them. They have a very large infrastructure, high loads, it's 370 development teams, 242 million ads, 3,000 services, almost 3,000 engineers. And, in general, you can become one of them if, well, we'll talk about learning something on the podcast, if your company has a boring infrastructure, no high load, no complex systems, a bunch of services. Well, you can come to the guys from Avito, and they have all of that. you can learn in practice there. In any case, check out their blog on Habr. They write often, they write interestingly. In general, many thanks to the guys from Avito Tech for their support. And we begin. And for a fun start, I have a question on the topic of learning. If you had to learn some topic, well, say, you have 48 hours for it, the topic is very complex, and you don't understand it, well, let's say it's some kind of Kubernetes, and you're not friends with Kubernetes, and you need to deploy some cluster or something like that. And how would you act, what's your tactic, who's ready to start? >> What are you thinking about? The tactic is primitive. You open YouTube, find any video on how to deploy Kubernetes, and start repeating it. As you watch, you look at other videos, ask ChatGPT what I'm doing. Well, and that's it, in about 12 hours you have a working Kubernetes cluster, and you roughly understand what's going on. Well, in general, I think that's it. If we're talking about Kubernetes, I have a slight idea of how it works. Well, that's roughly it. No more than 48 hours needed. >> Well, yes, especially now that there's ChatGPT, it's much easier. >> The main thing is not to ask it complex questions, because it will give you an answer that will surprise you, but later. Well, you can now run it to research, that is, it can find some guides, if there are answers to this topic somewhere, even if they are rare, it, well, that is, before, when it couldn't Google or research, it could just make mistakes because there was little material, and even if it learned from it, it's not a fact that it would remember, and here it finds a link, you can't be sure anyway, you understand? Well, okay, that's not the point, it's completely unimportant why. That is, even if it rambles, even if the video you found turns out to be irrelevant, then, as you, that is, what could be the mistake? Watching videos and getting a lot of information about how Kubernetes is built. No, you don't need to get any information, you need to do. You watched it, you immediately try to do it. If you succeeded in what the video said, great. If you understand what's happening, move on, if you don't understand, ask questions. Compare the questions with what you see on the screen. Based on these questions, try to take some actions independently. If it works, great, let's move on. If it doesn't work, start over. This is, by the way, a very important point. If something doesn't work, start over. I think I've told this story more than once, not even a story, but a personal experience. My first enlightenment in this area looked like this. It was back in eighty-seven-eighty-eight, when I got the keys to the computer lab. They gave me the keys and said, "There are BMPC computers here, we don't know what to do with them." At that time, the whole department worked on ES machines, on big computers like E25, 35, and other big machines. But I got the key to the lab. You turn it on, and there's only GV Basic and nothing else. Somehow I got a disk with Turbo Pascal, and a book in English, which I didn't know, which described the BIOS, its description, and interrupts, and so on. That is, not what we have now as an operating system manual, but a Talmud printed on paper, where system calls and interrupts were listed with ports, what to write in them, and what it all does with zero background knowledge. That is, I simply didn't understand what it was and what it was for. I read this book the first time, not knowing English. What I understood, I read with a dictionary. I flipped it over and started reading again. I read it a second time. I had some thoughts in my head. I read it a third time. Somewhere by the middle of the third reading, the picture in my head came together. I thought, "Oh, I know kung fu." I sat down and started trying. And it worked, text started appearing on the screen, programs started running, and so on. And that's it. And from that moment on, everything went normally, because it started to work, it became possible to check what you were doing in practice. Well, in general, that's the simple story. Therefore, if you don't understand something, then start over. And regarding practice, there are similar observations. Well, first of all, I probably learned to program through practice, essentially, because the materials I read, I've told this many times, were, well, essentially, I probably bought a pirated disk of Visual Basic, and there were some guides with it. I simply didn't have the internet back then, and I didn't know where else to look for materials. And these were pirated guides scanned from a real book using FineReader, with symbol confusion. I just copied a piece of code, then I had to restore it manually because, for example, the letter L could be replaced by a one. I had to decipher and somehow run such things. And yes, you just sit, read, and try to run at least what you read, and see if it works, essentially, that's practice too. Or, if we talk about more complex things, when you study mathematical analysis, I really caught that moment, and it's still fresh in my memory, a moment of insight, perhaps, when you read a chapter, and if you're reading a rather serious textbook, I was reading Zorich then, you read and think, "Well, I understood everything." And you're absolutely sure you understood everything, because you've carefully analyzed all the consequences, where everything comes from. But then, what's cool, he has exercises, and good exercises to think about at the end of each chapter. And you start solving the exercises and realize that the exercise isn't just about solving a problem, like calculating an integral, it's about proving a statement. You actually prove almost a theorem, right? Maybe even a theorem, why not? And you realize that you didn't understand anything at all. You go back, reread it, now knowing how you need to apply it, with a specific task in mind, and you realize that after another, second, third reading, the whole picture turns upside down in your head, and you understand that you understood everything incorrectly, and now you understand better. And you can already prove it, well, solve it and prove some statement. And this starts literally from the first chapter, when you read, say, the definition of a function. He, as far as I remember, defined functions quite cleverly using ordered pairs. Yes. And Lesha, do you have anything to add on this topic? Yes, I'll probably add. Well, first of all, I think, unlike Gleb, I perceive video very poorly. It's much easier for me to read text, or at worst, listen, but I'll read, so, the text version. Therefore, if there is some system that needs to be understood, a tool, the same Kubernetes, or some new thing, I will try to read the documentation. I won't start reading everything at once, just sit down and read it all. But I know, yes, like with the book, yes, you say: "No, read the minimum set, maybe understand some understandable things, go do something." I also prefer to do it in steps. While you're doing it, you realize that either you don't understand why it's like that, or you don't understand how it can be slightly changed to get something else. Or you'll continue reading the relevant part, and so, little by little, bit by bit, you expand your knowledge in this technology, or in something else. And if it's not about learning something that has documentation, but, I don't know, say, algorithms, or some abstract things, then I prefer to do it by drawing. A whiteboard or at least a piece of paper and a pen, and just gradually build a diagram, not as it's written, but as you understand it, visualize it for yourself. This option is more suitable for me. In general, the whiteboard, maybe we'll talk about it later. It's probably the most important tool I've been using for decades. It's really super. >> Well, yes, we can expand on this topic, because it's very interesting. Well, first of all, you said that you perceive video worse, but I also have something similar, but this is more because I often get distracted, well, that is, sometimes, well, I get distracted by my own thoughts. That is, I listen to someone, and some thought of theirs interests me, what they said, and I automatically start thinking about it in my head. And while I'm thinking, a couple of minutes pass, and I've already lost the thread. And the more often you lose the thread, the harder it is to listen further, because you no longer understand what they are talking about. And, well, sometimes I might listen for 15 minutes. And if it's YouTube, I just rewind. If it's a conference, you can't rewind anymore. >> It's easier to reread a sentence or two back than to rewind. >> Yes. >> Plus, sometimes, can I just a little bit, look, I want to return a little to this story with the Talmud and the book, and also to video. That is, why I mentioned video? Because I often combine video with something else. I go to have breakfast. You turn on the video, and it's good in this case, that is, why I started talking about video and why it's relevant to the story about this Talmud with documentation? Because in both cases, the task was essentially to get acquainted with the terminology. What I encountered when I started reading this documentation? I didn't understand what it was all about. I see the word "port," I open a dictionary. Well, of course, I read "cannon port," "ship port." What is it all about? Why do I need to write bytes into it? What is it at all? Completely unclear. Interrupt. What is it about? Watchdog. What kind of guard? Nothing is clear at all. I knew how to program, but I only knew application programming. I could go to the lab and write a program in Fortran, and it would work. I encountered the fact that I didn't understand what the documentation was about. After reading it several times, there were no other sources, I formed some terminology in my head. I started to understand what terms existed, how they related to each other, because they were mentioned in different contexts, in different places. There were letters that somehow explained it. And as a result, by the third reading, the picture came together. I understood, as it were, what it was about. Therefore, why is video good, or an introductory article, or something else? Video can be combined with something that, as it were, I like, time is not wasted. You start watching it. Ah, by the way, here's another personal choice when choosing videos. You see a video that's an hour and a half long, don't watch it. Find something for 15 minutes. Because, firstly, you'll quickly realize that it's some kind of nonsense and you need to find another video. Or you'll get the same information that you would have gotten in an hour and a half. Therefore, you find several short videos, watch them, you immerse yourself in the terminology, you understand what terms are there, how they relate to each other. You understand that this is, as it were, an overlay on Docker, there are pods, everything, like start, stop, deploy. After that, it's much easier to figure things out. Therefore, the main task of such videos is precisely that, that very replacement for triple reading of documentation without any background. That is, to get some background, some overview of the terminology, of what's happening, maybe, if we're talking from scratch, well, listen to how people define things. In any video, it starts with the person talking for at least a minute of introduction, about what they will talk about. This gives a general idea of the problem you are going to tackle. And in this sense, it is extremely important to start your learning. It is precisely with understanding what we are talking about, what terms are used, what they approximately mean. And then, when this picture comes together, you can engage in some learning. If this doesn't happen, you need to repeat, because nothing will work without it. >> Well, you've just dismissed all my videos with your fifteen-minute criterion. My videos are sometimes 3-4 hours long. Those are the best ones. No, no, no. These are completely different things, because those videos that are 3 hours long are not about the problem, they are simply, figuratively speaking, a description of how something works. And this is like >> this is, you know, the difference between a textbook and documentation. A textbook shouldn't be huge and thick. A textbook should be of a normal size. Knuth we set aside. That's an exception. >> Well, you read it anyway. >> Well, I read it, yes. >> Well, how else will we get back to it when we talk about books? >> And there's documentation? Documentation, of course, it's, well, whatever the topic is, that's how big the documentation is. >> Okay, Lesha was also talking about video. Finish your thought. >> Yes, yes, yes. Ah, yes. Look, regarding such a quick excursion, yes, into the topic of the problem. In my case, I don't impose it on anyone, I prefer to look for some reviews, comparisons, lists, oh, how bad everything is, how good everything is with this technology. This is exactly my way of understanding the problem. These are usually small, compact text, maybe with diagrams, options, containing pitfalls that people encounter, some comparisons with other technologies that they might know, yes? That is, as it were, this is my way of approaching it. There are some things I don't understand. Like, here it's compared with this. What is that, I don't know. I'll go read about this point. This is, well, I don't know, it can probably be compared to, uh, depth-first search, perhaps, in a way, that something is clear here, something is unclear here. I'll go, dig deeper, deeper. Aha, clear. I'll go back to the point where everything was, well, I found something unclear, I'll read further. Well, working through each point like that, probably, is the way. The main thing is to cut off the depth of this tree at some level, otherwise you'll go into infinity, yes. And regarding the story with the book, I have a very similar thing. Yesterday I sent Kolya a photo, I found that book. My first programming book was translated from French, a book on programming for DSDOS. A brown one. It was about interrupts, it was about Pascal, Basic, and commands, in general, of DOS itself. This was the first book I had on programming at all. There I learned about the existence of interrupts, Pascal. I didn't have any of that yet, but somehow, yes. And already understanding that this thing existed, fortunately it was in Russian, it was unclear, yes, for a schoolboy, but somehow, yes, it helped me understand some terms, by which I could search for additional information. The internet was already available via modems on cards, usually at night. Well, with the dial-up, yes, with the dial-up on the and I found something like, roughly speaking >> 2000, ninety-ninth. Well, around then, that's when I got interested in programming. I learned about it, read this book several times. Especially the last chapters on interrupts and Pascal. That was the only book I had. and I found somewhere, I don't know, maybe some BBS forums, maybe I don't know, somewhere on the internet, a list of Ralph Brown's interrupts. I don't know if you encountered it. Brown's book, well, Ralph Brown, it's a list, well, it's called a list, that's the kind of thing. Yes, yes, yes. It wasn't a bedside book, but it was a bedside reference that allowed me to delve very deeply into what the computer could do. Well, not the computer, but the BIOS, DOS, and so on. And with that, I really went deep. I learned about the existence of Pascal later, and well, far. >> Well, an interesting point arises here about learning in general. Well, probably no one will argue here. It only goes well when you have some interest, enthusiasm. If you study something by force, then it, well, it might go, but it will be difficult. And what drove you then? That is, you describe quite complex things that are difficult to touch and difficult to delve into. >> It's quite simple. I got a computer thanks to my parents in middle school, probably, I don't know, ninety-sixth, ninety-seventh. I'm definitely bad. Well, around then, yes. But for me, a computer was a device that allowed me to play Diablo, Doom, Warcraft, well, games like that. Games, yes. Yes, for me, Windows was like Steam for launching games. Roughly the same for the computer in general, yes. But by around 2000, my ninth grade, I got bored of just playing games. I wanted to know, how are games made, like, how does all this happen, this magic that appeared in DOS and Windows, yes? And Windows was probably or Millennium at that time already. So I became interested in how.

Here is the translation of the provided Russian text into English:

So, essentially, I found this book, I knew about the interruption, there was a magic word of weight with graphics. I was like, "What is this at all? No idea, like some instructions, some RGB layers. But it was cool. I went to dig. So, I had Turbo Pascal, and in it, there was Turbo Assembler. So, I started trying to draw something in Pascal, some kind of lace patterns, fills. Well, everyone probably imagines, like BASIC, Pascal, plus or minus, right, it's a built-in language feature. I tried to make some first primitive, like, 2D games, super primitive, but I quickly realized, I think, a month, maybe half a year, plus this transition period, even in high school, most likely, that I lacked the speed of this Pascal library for graphics rendering speed. I, of course, didn't know about some optimizations, like redrawing the changed screen, these, well, some things, right, right, right, we try to optimize by just erasing the whole screen again, drawing again, erasing. Well, you understand, right, and neither the hardware of that time, nor Pascal, despite the fact that you encountered a lot of difficulties, that you still didn't have the desire, like, right, well, I'll go play Diablo further or, I don't know, mods. >> No, I was interested, of course. Yes, yes, yes. I even remember one of all the somewhat memorable finished games in terms of mechanics. Yes, I remember, well, it lagged terribly, it lagged a lot. And I wanted it to be like in games. I play games. So, they can. Why can't I? Right, and no one could help. There's no information, no internet. There's an idea. Why? How does it work that someone will start, well, surely many had such desires in childhood, right, and now you play a game and want to make your own. But I think most people stop at the stage where something didn't work out and they go back to playing someone else's game, rather than hacking away at their own, and someone just digs to the end, and they fundamentally want to reach some result through all the difficulties after, I don't know, a year. How, how do you think, what can this depend on? Some personal, I don't know, settings in the head or is it something else? >> I just, I've been nurturing and cultivating for my whole life the acquisition of endorphins through feedback. I did something cool. It could be a red pixel on the screen, it could be a complex system, some kind of weapon system, right, it's, well, depending on the period. But I get a lot of positive emotions, you understand, right, I can do it great, wonderfully, it's a lot of endorphins, I'm happy about it. And I understand that this is a very good way of self-development for me, that I get not just knowledge, but I get some pleasant feedback in the form of endorphins. You learn something, you do something, something works out, some kind of cool thing, you optimize something, improve something, fix a problem. Well, options, right. >> Well, it's just easier to get these, >> conditionally. >> Well, I have such an option, right, I'm making myself and the world better, and it's pleasant for me in such a way. A mechanistic approach, so to speak. I don't even know, I think it's much simpler. Well, at least for me, it's much simpler. You just have to do what you like, and that's it. And what each person likes is a tenth thing. And what difference does it make why? >> Well, what difference does it make why? If >> well, look, if it had turned out if it had turned out that way, then running would bring me pleasure. I wouldn't be programming, I'd be running, and I wouldn't be reflecting on it. There are people who go out in the morning, run for 3 hours, come home very happy, they got a lot of endorphins, by running their route, a little faster, a little better, or just running, it doesn't bring me any fun at all. I don't do it. >> It brings me, programming brings me pleasure. I like to think, I like to create something. I don't engage in reflection, why I like it. What difference does it make? If you like it, do it. Well, that's how it happened, I think, that I like it. Well, I like to think in general, I like to think. That's why I like, I don't know, watching videos about mathematics or reading books about mathematics, solving some problems. This is such a simple way to get quick endorphins. You see some interesting mathematical problem, well, you stop, think, and move on. Like, you like to think when you're doing something, right, like I'm planning some system, I like to figure out how it will be structured, and get confirmation in the form of a working product that it is indeed structured that way. I like playing computer games, I play them, so it seems very simple how it all works out, that, for example, computer games don't displace other activities. For example, >> I don't like the feeling of hunger, so I don't play computer games 24 hours a day. If >> well >> I thought you meant hunger in a metaphorical sense? No, in a literal sense. Well, listen, well, that is, look, it's all very simple. There's work for which you can get money and which you like, right? So, if we take this simple thesis, of course, it's simplified. I like to think. When I work, I think, I like it, and I get paid for it. Well, great. I also like to eat afterwards. I if the money there, well, I'm simplifying all this again, right, but in any case, my approach is very simple. I recommend it to everyone. I understand that not everyone succeeds, but never do what you don't like. If you don't like some work, look for another. >> Well, there are many jobs. This works if you like something useful. For example, there's a trap here in the sense that you don't yet understand if you will like it, and sometimes you can teach yourself to love something. And it's like, well, it's happened to me. There's also this point that again, you might take modern games, for example, some with tricky mechanics, they can pull all the levers in your brain, as it were, and make you fall in love with them. Well, for example, Dota, World of Warcraft, well, games that can be played for. Well, here, for whom >> I don't play Dota. >> I don't play Dota. Dota probably affects me. If I return to it, then I'll be, just a second, look, look. What was I talking about? You say modern games can pull levers and make you fall in love. No, >> they can't. It's just that you like it here, and I don't. >> Well, if you just break down why I like it, then there's, for example, the desire to develop. And in programming, development is slow and not always with such feedback. And there, development is fast, and you get instant feedback. You learned something new, you tried it in a new session, it worked out immediately. Here, this cycle is much faster, and they optimize it so skillfully that it affects your head much better. >> So your statement in this case should be understood as: "I like fast feedback." Then you will like anything in life that gives you fast feedback. >> So, test, verification, result. The shorter this cycle, the more pleasure you get, because the time between the start of work and receiving feedback is important to you. And that's why games of this type hook you. And possibly why programming hooks you, because it's actually quite short feedback in programming. You quickly understand, whether it works or not, whether it will work or not. It's not for nothing that it's considered that the maximum task length should be no more than one day, otherwise it needs to be broken down into subtasks again, again for the same feedback, because otherwise you get bogged down in endless attempts to get something, improve something, time passes, there's no result, motivation is lost, and so on. It's just that for some it's more important, for some it's less important, but the cycle size, well, for you, it's probably extremely important if you give a correct assessment of your actions. Yes. >> Well, I gave Dota as an example for a different reason, because if you just tell a person: "Do what you like," and they say: "Oh, I like Dota, why should I look for something else? I'll just do this." And it's clear that if they just play Dota their whole life, they won't find much happiness. Although, arguably, they could become an esports player and earn millions. Yes. >> Can I return to this, by the way? >> Yes. Go ahead. >> I have a question for both of you. I don't know, if you had n hours of free time, a day off, right? No tasks, no family obligations, nothing. Eight hours of time, would you play games or would you program something cool? Not for work, for example, or even for work, it's not that important. The question is. I think it's a question of choice, right? >> Let's go, Gleb, you. >> Well, first of all, any activity gets boring, so if I have too much time to play, I probably would play for a few hours, literally. For a few hours. No, if it's just a few hours, then I'll probably go play, because I work more than I play. >> Well, it depends on various factors, on your mood, your fatigue, how hard the week was. For me, actually, I can answer this question precisely, because it happens to me every time. Not that it's a few hours, but generally on Saturdays I don't plan any heavy activity, for example, programming, writing a script for a video, that kind of thing, because I understand that after a work week I'll start procrastinating, because there's not much energy left, and I'll just, well, I record podcasts on Saturdays, well, that's one of the reasons why I record on Saturdays, because Sunday is a more valuable day for me, there I, how to say, have more strength left, and then I'll either program or something like that. And on Saturday, I record a podcast, just to chat. And that's also pleasant, it's not hard work. And then I just play games, walk with the dogs, things like that. And on Sunday, well, if it's because I just have little time, a lot of things to do. But if, for example, to consider it in a vacuum, that I just have a few hours, then, well, well, it will depend on what I want right now, how long it's been since I last played, how tired I am, if I have an interesting project that I really want to finish now. So if I, I don't know, am writing some service for myself and everyone likes it, everyone visits it, and I want to write some feature, of course, I'll write the feature first, and then play games. Something like that. >> They don't happen. Of course, there are situations when a task is extremely interesting, and you're like, "Eh, what weekend, what sleep? I'm on fire, give me the keyboard." That happens too. >> That's exactly it, right, that's exactly what I was talking about regarding getting feedback about something that you like, that you like both, and you like playing, right, and you like programming. For example, some task that can be done for work or not for work in exchange for hours and get quick, right, pleasure, endorphins, as it can be called, or play games for the same amount of time and get the same thing, right. So, we find ourselves in a dilemma, which pleasant option should we choose at this moment? Well, for me, personally, I love to play, I don't have much time, but I try, I like it, right, but there are really situations when I sit and play, and my thoughts are at work or on some personal project, or some task. For example, I sit here, I'm supposedly playing, I'm enjoying it, right, you'll say it's good, right, I'm happy, I'm doing something pleasant, it's interesting to me, but my head is elsewhere. I'm like, "Ah, damn it, Alt-Tab, IDE." This is just, apparently, at this moment I will get even more positive emotions, some pleasantness, if I complete the task, than even if I play my favorite game. Such situations happen. I think this is one of the ways of self-development, that I didn't rest, right, I pushed myself further. This is my duty in the future for my health, right, but I'm still doing something pleasant. Yes, Gri, go ahead. Well, the human consciousness is structured in such an interesting way that if something you like, some task bothers you, then the work on it continues constantly in your brain. It never stops. >> And if you've never had this, it's better not to do programming. It's not for you. That is, if you've never, standing in line at the store, without stopping, said, "Damn, that's how it should be done," then most likely you're not doing the work you like, and it's better not to do programming at all, do something else. Well, or how, I don't know, well, anyway, that's a secondary matter. And this applies not only to programming, but to absolutely any task. The same thing happens, I don't know, with mathematical problems or puzzles, you encounter something, discuss it, and then you part ways. That is, no, no one found a solution. Then somewhere, I don't know, a week later, you're driving a car, and you're like, wait. >> Yes. >> You get out your phone, call the person, and say, "What about this?" They say, "Yes, that's right." You say, "Ah, yes, I understand, finally. Great. Hooray! You didn't think about this task for a week?" Yes. That means that all this time, some work was happening somewhere. It was happening on its own. The same thing happens with programming. If there's a problem you're solving, programming is essentially divided into two parts, right? First, you need to come up with a plan for a solution, and then implement it. And this process of coming up with a solution plan, solving some problem, if it's not trivial, it always happens and it happens in the background in your head. And it's completely natural and normal when you, I don't know, in the middle of a game, at any moment it can happen, you understand how this task should have been solved. And in general, ideally, now ideally, I don't know about you, but I don't know, this has become less common now, and perhaps because of this, work has become worse and programming less interesting. Before COVID started, everyone went home, and so on, there was an interesting time when you commute to work and from work, and you're not doing anything. And usually, on the way to and from work, I thought about work. That is, you're driving and thinking about what you're going to do. And these were 2 hours of such reflections. And it was a rather interesting part of the work. Now, because from the bed to work is exactly, I don't know, 20 steps down the stairs or there are two doors open, this part disappears somewhere as a result, because, being at home, you, I don't know, talk to your wife, you, well, you can walk the dog, think. This is, yes, possibly, but still this period of time has shortened, and I think we've lost something as a result. Well, regarding what you said. Well, first of all, you described my life story exactly when I called about a solution. In school, when I was studying, my physics teacher, well, all of us, gave us a problem, you know, the kind where you have to answer: "Yes or no." Like, he describes a very unclear situation, and you can only answer yes or no, and you need to figure out what happened. And it hooked me so much that I called him several times during the day on his home phone, and it was a rotary phone, you dial and ask: "What about this?" He'd say: "No." I'd say: "Damn, I have to think again." And you sit and think, just think: "I already have the solution." Yes. And about walks, yes, there is that. It's even better to walk to work than to drive, because I heard something that when you walk, your brain works better. And there were, like, all these philosophers who used to walk specifically to think while walking. And I even started catching myself sometimes just unconsciously thinking, "Damn, I should go for a walk," and I remember, "Did I order something on Ozone or not?" Because Ozone is located such that it's about 40 minutes round trip, maybe a little more if you don't rush, and I think, "Damn, I didn't order anything, so I won't go for a walk." Well, I'll sit at home and think. Well, something like that. And then, when you remember that you need to walk, you think, "Oh, okay, I'll go for a walk now and think about it." So yes, it even works unconsciously, and you need to use it. And also about games, there's a trap that what we love in real life, for example, well, Game Dev, you want to write your own game, become a cool developer, earn money from it. And all these mechanisms that you get in the long run, they are compressed in the game. Literally, there's a game called Game Dev Tycoon, I think, that's its name. It's also very addictive. And all these processes are there too. Well, of course, in a simplified form, but they happen faster. That is, you sit in the garage, hacking away at some game, well, your character, and he quickly starts to generate income. He gets a studio, a team, he makes more expensive games. And it can happen that in your life it goes slowly and satisfies you quite a bit, and you just retreat into virtual reality, where it's exactly as you wanted. Or, for example, Factorio, or these factories. You build microservices at your job, you find it interesting, well, not necessarily microservices, but some complex system. And there you encounter the need to test it, deploy it, read logs. Well, not all of this is always interesting. Arguing with people during reviews, and in Factorio, you build it alone, and your factory works immediately. Well, Factorio is very similar to development, there are many parallels, but there, all the boring parts are removed, all the interesting parts are left. So. And how to deal with this? Well, probably, at some point, convince yourself that you need to return to the real world and recognize the mechanics that hook you there and try to find them here. Something like that. >> I think it's all very complicated. If games hook you so much that you have to persuade yourself to return to the real world and become aware, then maybe it's better not to play at all. I don't even know. >> Well, that's one way, so I fundamentally don't install Dota. But yes, I want to play with friends, they invite me, like, come on, let's have an evening. I had a situation where I quit playing, then I got a job at Lamoda, and my colleagues played Dota. I thought, well, I'll install it, I'll only play with them. And, damn, I don't know, I think I would have been fired soon because of how much I got hooked, and it just gets boring, and then anxiety starts when you think on a workday, you think, "Well, I work remotely, but maybe I should play?" And you think, "That's it, I'm screwed, it's time to delete it." >> Well, that's already an addiction, when it becomes >> Well, yes, that's how it is. How to deal with it? Well, simply, well, in the case of Dota, you can delete it. Okay, we've lingered here. Alex, do you have anything else to add on this topic? You've spoken the least. >> I can share my similar experience regarding these ideas that you suddenly wake up with, that suddenly come to mind. I have a special app on my phone, I record all my ideas there. It's not always a solution to a problem, but it's a thought or a direction that's worth, later, when I'm more prepared at the computer, for example, right, I can try. I record it immediately, maybe I wake up at night, or maybe in the car while walking, well, anything can happen. An idea comes to me, as you say, I just record it immediately so as not to lose it, and then I go about my business. But I remember that I have something recorded, and when I'm ready, calmly, when no one is distracting me, I'll come back and think it through. This situation often arises. And regarding perception, you talked about walking, that it's useful for you to go to Ozone, right? And I've noticed that for me it's been like this since school. I remember and think better this way, but I don't walk, I walk around the room, around the house. When I go outside, it's worse for me because of distractions, people, cars, traffic lights, new things. You get distracted, you lose your train of thought, and that's it. And it's better to work when I'm at home, I calmly walk in circles, I can walk for an hour, two hours, until my head starts spinning, right, in the other direction. This really improves perception, brain function, memory, and the creative process. Now, well, before, when they only traveled by train, I used to take the metro to work, right, I had 30-40 minutes there, I would think, I would listen to podcasts, well, that kind of thing, I would absorb information. Now, this is only possible if I'm driving, I turn on a podcast and just listen to it as input material. Thinking is difficult, but walking in circles still, for me, is the best. Yes, I actually remembered that I caught myself doing this, I mean, on the desire to walk in circles. I, well, probably the most difficult and interesting tasks for me were related to physics. And when I was in physics, NIF, as it's called, I don't know if anyone studied in St. Petersburg, maybe in Peterhof there's NIF, Physics NIF. And the theorists' wing there was usually empty because all the theorists worked from home and met maybe once a week, something like that. And it's huge in itself. And so, well, I lived in a dormitory, so it was easier for me not to sit at home, but there, I took the keys to the office. And when you're sitting, at some point you think, you think, and you realize that you want to walk, I just, like you, but not in circles, but along the long corridor. >> You had a place where there were no >> distractions. It's quiet, calm. I mean, an apartment or a house. Yes, >> that's probably one of the most pleasant places for contemplation. Such a quiet and calm atmosphere, dim light, no one around, long corridors. And it reminds me of the Strugatskys. >> Monday Begins on Saturday, right, where he worked in nothing. >> Such romance there was. >> It's similar to programming. It's precisely some complex algebraic problem, not some obvious rearrangement of components, right, then I often switch from a sitting position to standing and work standing up, because my brain also works better when I can shift my weight, walk around, approach something, that really works better. >> Well, and by the way, these standing desks can also be used, and some, >> well, yes, any method, right, a standing desk, putting a book under it, a higher tabletop, anything. I take it and go somewhere to work standing up for an hour, two, three, so that my brain really starts to work better and faster. >> Well, I'll say a couple of words about the standing desk too. Something that many might underestimate. I myself thought it was a stupid idea, like, I'm more comfortable working sitting down than standing. But then I got into it myself, because sometimes you get so engrossed that you don't even want to sit down anymore. That is, you raise the table, you work standing up. In general, many may underestimate it, you need to try it. And plus, when you sit for a long time, then

It's physically uncomfortable for you to sit, and sometimes you want to work on the computer longer, and you realize you need to get up, but I haven't finished here yet. That's it. And so you're kind of standing. Some people also buy these, uh, like treadmills, but simple ones, I don't know, stepper machines, where you just walk all the time. I think I'll buy one, but my hands haven't gotten to it yet. Well, in general, okay, let's summarize here. In general, regarding our unplanned part, about how your involvement often affects learning, well, not often, it greatly affects it. And when you like it, it's pleasant, it makes you happy, there's enthusiasm, then learning goes much better, it's remembered better. It's literally, I won't, to avoid deceiving, but I've heard that our brain is structured in such a way that it remembers better when it considers something important and interesting. And if not, then you can force yourself to read it, uh, even practice it, but it will evaporate faster. That's it. And, well, actually, I don't think that if you don't like something, it's a verdict, because in my life it often happened that I might not like something because either I didn't delve into it enough, well, when I entered physics, for example, I thought that quantum mechanics would be the most interesting to me, because I had read Feynman and various other things, and it seemed like something exciting, but reality showed that it wasn't that exciting there, well, maybe it just didn't click with me, there's a lot of linear algebra, all these matrices, operators, I didn't really get into it. But what's funny is that when I entered, I thought that the most boring thing you could imagine in physics was statistical physics. Well, like, just some boring nonsense. But when I delved into it again, I thought it was the most interesting thing you could imagine in physics. And in the end, I went to the statistical physics department. This is to say that at first you might ignore some things because you don't understand how they work very well, and you don't see the mechanisms that will make you love them. That's the first thing. And secondly, sometimes you can just use your imagination. I also heard a quote somewhere, I think I read it on Habr from some guy. It stuck in my head quite firmly, that if you don't like something, you just have too little imagination. And it happened to me that sometimes some process I don't really like, I just sit down and try to think, what could hook me in it? For example, I always disliked biology in school, as it seemed super boring. Then you try to dig up something interesting, to find it, and you find some mechanisms in your head and in biology itself that will make you love it. And now, for example, well, if I had a second life or infinite time, I would sit down and dive into biology as much as I have into programming now. That's it. So you can try them. That is, you need to learn something. It seems like boring, uninteresting nonsense. And fortunately, we now have very cool things. You write, like, listen, I need to learn this, but it seems incredibly boring to me. Tell me something like that, try to interest me, so that my eyes light up. And then I might learn it. I think that could work. Okay, let's get back to practice. Here again, I remembered something about reading a book and the practice itself. What I've already told this story a couple of times. That when I read the book about Go for the first time, I had a not-so-correct approach. Here, maybe I fell into a trap, that I needed to learn Go quickly, because I was applying for a job at Gaidin then, and GP said that during some one-month break or something like that, I don't remember why. But in general, he said that I needed to learn Go in this month. It was a condition. And I thought, damn, I don't have time to write anything, experiment with programs. I'll just read the book in a month and sort of dive in. But, well, in the end, I still wrote some programs. But then I was mistaken in terms of learning. I thought it would be more effective. Well, firstly, yes, almost everything evaporated from my head that I had read. And the peak, perhaps, was that we somehow encountered an error with Gleb, where the interface, well, which is not Nil, is actually Nil. Well, damn, I won't describe it in detail now. In general, I think those who understood, understood, and those who didn't, just imagine, there's some complex mechanism that isn't always obvious. And I couldn't understand at all why this was happening. I thought it was a bug in Go. And when I finally went to Stack Overflow, I asked this question, and I was sort of downvoted and showered with criticism, but they still sent me the correct link, because, well, they showered me with criticism because I was probably the thousandth or millionth person to ask about it. I suddenly remembered that I had read this in the book, because in the book there was a small section dedicated to this, not a whole chapter, but a small section. And I had read it, and I remembered that I had read it. And here's a dual situation. On the one hand, reading was useless, because I read it, well, I completely forgot about it in reality. On the other hand, if I hadn't read it, I would have taken longer to figure it out. And the guys who sent me links, I might have thought they were sending nonsense, but here it immediately triggered me. And seemingly forgotten knowledge surfaced in my head. At least I remembered where to look. I got that book at that moment, reread that whole section, and remembered. So at least it was useful in the sense that you build a kind of map of the terrain in your head, which, well, might come in handy someday. That is, if you've read a lot, you'll know where to dig, and roughly what it looks like, some outlines. Here's another example. I read a book about No SQL. I thought Robert Martin wrote it, but it turned out, I checked later, it says Robert Martin recommends it. The author was different, but that's not the point. It was still a good and very thin book. And I learned a lot of concepts in it then. For example, about CAP theorem, about the principles of operation of different databases, which are not SQL, like, well, document-based, vector-based, graph-based. And when I encountered this in life later, this book showed me this map of the terrain, so I roughly understood what it was about and where to dig. But on the other hand, maybe it's not very optimal, like reading the Talmud just to get a map of the terrain in your head, which might not be useful. What do you think about that? We are >> closely, we are closely approaching, you know, what? We are approaching the concepts of general education and literacy and learning. These are slightly different things. What you are talking about now is breadth of knowledge, literacy, and education. That is, the more you have read, touched, seen, the better, the more chances that either, as you are describing now, it floats in your head, you read it, but you didn't assign it importance outside of context. Your data was stored somewhere very far away, you didn't build practical connections when you encountered this problem. But still, it helps, because when you were told which direction to dig, you remembered, it was remembered. >> you remembered where you read it somewhere, possibly how the interface in Go is structured and understood why it's happening like that, and so on. And this is precisely about the question, I want to be a good programmer, what do I need to read? Read everything you can get your hands on, read everything. Will it be useful in your work? No, it won't be useful. Will it help you in your work? Yes, it will help. But it's not directly related to learning. That is, if you are learning, studying the Go language, or studying, I don't know, advanced mathematics, or studying some new topic, then learning should only happen through practice. Otherwise, it's all useless. Therefore, you need to be aware of why you are reading this. Will I use it in my work or because I am interested? So when you read the Go book, you should have read it because it made sense to read it. Well, if you were interested, just read it, because it will lie somewhere in your memory, not entirely useless, but still as baggage. More precisely, almost useless, but almost useless baggage. And it helps to build connections. It helps you to come up with some solution later. It helps you to learn other languages. That is, you will read some other topic later, and you will start to recall: "Ah, it's structured like this there, and why didn't they do it this way here, or how did they solve this problem here?" Otherwise, it's funny. I'll have to see, which of these two solutions is better or what it leads to. How is it done in another language? And this allows you to be flexible enough when choosing solutions, and to maintain interest in life, because you regularly stumble upon interesting crumbs scattered around the world that allow you to move forward. They allow your consciousness to wander in different directions. You're just going through this book like a tunnel. If you have nothing else, well, you're moving through the tunnel as written. If you have scattered various treats for yourself in life, then moving forward is much more interesting, because there are always turns, ideas, detours, unexpected intersections, and so on. Well. And learning, yes, when you started writing code, you started learning. I mean, not you, anyone. That is, you need to do something practical yourself. And this applies to absolutely any job. Any. >> Well, yes, regarding such things, I would also say that you need to create a certain hunger for theory within yourself. Because when you read a book for the first time, it seems to you that you are reading it because you have to. And it's not always interesting. And not always from everything you read, do you understand why it will be useful. But if, on the other hand, again, to this book, who read Progo, it's Kernighan and, I think, someone else, I don't remember who else was their co-author, well, probably everyone knows it. The main, one might say, book on Go. And when you return to it, after you've written a lot of code in Go, you have many questions, you realize that you don't understand how some mechanisms work, and you return to it again. And you even take the same chapter on interfaces. I read it with bated breath. Very interesting, because I returned to read not some abstract theory, but to read an explanation of the mechanisms I had encountered. And you think: "Ah, so that's how it works, that's why it's structured like that, that's why it broke." And you read it like fiction, because it's as interesting to you as fiction. And again, the same Zorich, whom I mentioned at the beginning with mathematical analysis. That is, you read a chapter, well, not super interesting, although he writes quite interestingly, in my opinion. But when you return after doing exercises, when something hurts and you are hungry for this theory, you read it with burning eyes and remember it better. And if you take the same case with interfaces, I now remember it for life. And maybe not all Go developers will remember or understand it immediately, even experienced ones. But I remember, at some conference, questions were asked, a similar situation was described, and I was the first to react. I even won something for the first time because I immediately raised my hand and answered, and there, well, it was a competition, whoever answered first got a prize. Because I got burned like that, and the explanation immediately clicked in my head. And, well, well, yes, it turns out that when you get burned, stumble, and just accumulate questions, then returning to the book is much more interesting. I even heard such a radical approach. I had a friend at the physics department. She ended up having a very good career as a theoretical physicist, so to speak. Well, in general, a very smart girl. And she said that she has such a radical approach. She first starts solving problems. Well, she studied physics, mathematics. She first solved problems, and then read the theory. That is, she would open a problem, even when she had no idea what it was about, how to solve it, how to approach it, and tried to, well, come up with something. Even if it was some stupid nonsense, but at least the brain, uh, creates this need. And after that, it's much more interesting to read the book. And I probably realized this approach years later, that it makes sense. Back then, it seemed like nonsense. Why solve a problem you don't even know what it's about? That is, you solve a math analysis problem without reading math analysis. It seemed useless. But now I realize why she advised doing that. What do you think about this? >> It's hard to say, well, meaning, as a practice, it often happens that way. You take on a task, because you misjudged it, you start solving it, and you realize that something is not working out. Either it's too complicated, or the results are unimpressive. And you go to see what's available on this topic? Maybe I'm reinventing the wheel? Maybe I don't need to write anything? Maybe it's all already written. Well, I usually always do that. I usually immediately check: "Maybe someone has already done all the work for me? Maybe I shouldn't be doing nonsense?" Lesh, what do you think about reading a book, hunger for theory, practice? >> Okay, your microphone is off, >> yes? Sorry, sorry. Ah, I first remembered the story when you said that first you try to solve, then, like, yes, you read a little theory on this topic. In school, we were given a task. We had to solve some task, I don't remember which one anymore. I solve it, I came up with a proof of the Pythagorean theorem in some way, I don't remember, there are several of them, yes. I think, wow, we haven't covered this proof method yet. I just went to it, I solve another task. Because I tried to approach the task in different ways, and one of the ways led me to the Pythagorean theorem and I solved the task. So I think, yeah, tomorrow in class I'll tell them how great I am. The next task in the same textbook. So, Pythagorean theorem, damn, there it is. Well, yes, meaning, you don't know the tool, it solves another task, you come, essentially, to this, yes, or you don't come, if it doesn't work out. Well, for these, it just worked out, but it might not work out, yes, I believe it was a simple task, and when we talk about more advanced university tasks, there, when the level is something like systems of differential equations, I wouldn't have solved it if I didn't know the theory of these, how to deal with them at all, yes, in these higher orders. >> Well, yes. Well, like, if you took those differential equations and tried to solve them, you naturally, most likely, wouldn't solve anything, but you would come up with some, maybe, stupid methods that are doomed to failure. But at least some simple, some simple systems, you would still have a chance to solve, yes, but a complex system, above, no chance, I don't know. >> But then, when you read about the solution, you would think: "Wow, how ingeniously they came up with how to solve it." And I didn't figure it out. >> Yes, yes. That's it. And regarding books, I don't know, I generally, both before and now. Well, it was easier before. I try to read, before you could still buy them when it was, yes, reasonable. And anything that was even remotely interesting to me, I just read, put it on the shelf, and it stood there, maybe for years. This was precisely a way to broaden my horizons, to gain some experience. And this allows you in the future, when faced with a task, to remember that you read this. There was such a little book, I remember, or I still remember it. And this interests me and expands. Yes, let's rephrase it. There is, it's impossible to learn everything, it's impossible to understand everything. But if you have literacy, then when you encounter a new problem, you know how to find information to solve it. If you don't know how to search for information, how to solve a problem, if you can't find it. Well, yes, now we have search engines and others that will help find a link, read, but it wasn't like that before. The only option was either to ask for help from the audience, help from a friend, yes, call a friend, that's how it was. Or you had to have your own personal experience, literacy, so that you could understand at least what keywords to use to then find a solution to the problem, yes, so. Therefore, read books, articles, materials, and continue to actively read all sorts of groups, listen to podcasts, what my friends send me, acquaintances. It's just not a fact that I'll remember it, but I'll read it. Maybe it's a cool topic, I'll put it aside, but then I'll delve deeper into it again, yes, it's like digging into it, trying it myself, that it's just, oh, cool, okay, like, closed. That's it. But it's stored in your head and can be used in the future, like, oh, I read something similar 5 years ago. And then another problem arises, which, I think, Kolya, you understand much better than me, how to systematize information, all sorts of Obsidian, other things. We can talk about it further. I have this problem. I just trust myself, I rely either on remembering keywords at least, and then I google them again. In short, I don't have a system for systematizing knowledge, what I've read. >> Well, yes, I'll say about that. Actually, I haven't used it much lately. Regarding proving theorems, I also remembered that the same girl advised me how to read math textbooks. She advised reading only the definitions of axioms, because you can't do without them. But proofs, she said to skip them altogether, because you had to prove them yourself. You read a theorem and try to prove it. Until you prove it, don't move on. That's also a hardcore approach, and it worked for her. It didn't work for me. I told her, like, well, maybe, after proving it, not proving it, but at least reading, like, the proof, as in the textbook, she said: "No, why do you need it? If you've proven it, you don't care about the proof that was there." >> But that's radical advice, right? >> You can prove it in another way. >> Well, yes, yes, >> that's >> how it is. >> You can start reading like: "It looks like I'm white, and that's fine." Yes, but I think if you come up with a different solution, it's even better. >> I just don't recommend anyone to do that. Well, you should try, but if it doesn't work, then don't torture yourself. It's a method, maybe for those whose brains work differently, I don't know, it somehow works out. It didn't work for me. I, uh, it was incredibly slow. That is, if I proved some complex theorem, it might take me a month, and in a month I would have read the whole book. >> Well. But somehow like that. Regarding how to apply this in real life. Well, that is, we've talked a lot about mathematics now. If we talk about programming, then, well, you probably need to try to write code not before you've read anything, because it's impossible here. You won't be writing, please run. You read some basic rules at least and try, well, when you have a small baggage, you know how conditional operators work, you try to write a program, even if it's crooked, incorrect, and maybe doesn't even compile, but you're already creating interest for further reading. And then, when you get a little more, you try to apply it. That's how an optimal route forms in my head. You keep talking about me for some reason. Can you hear me now? No. Yes. >> There, uh-huh. Because I was touching the microphone. >> You keep talking about how to deceive yourself. I don't quite understand that. You say, "Do this so that there's some incentive, but before there wasn't." Well, it's like, I don't quite understand. You're like: "Start writing, you'll get an incentive to continue." But before there wasn't. So you're like, a global incentive. No, I'm not talking about a global incentive, like I have an incentive, like, I don't know, the ultimate goal is to learn to program or use such a technology. But on the one hand, you need to practice, on the other hand, you need to know the theory of this thing, how it works, why so, some mechanisms. But when you just read a large amount of theory, which you will eventually need anyway, it's not very interesting, because you don't yet understand what it is, what it's for. Well, that is, when I read about interfaces in GO, well, for example, I'm poorly familiar with the concept of interfaces. I, well, yes, there's such a thing, there's an interface, but why should it be interesting to me? I don't understand why it's applied. Well, maybe they gave some examples, but still. But when it's needed in my life, that is, when these interfaces solve my personal pain, I'm more interested in reading about them, because I'm not reading about some abstract entity, but about an entity that solves my problem. And I needed it all this time, and finally I got it. Reading becomes more interesting. >> That's a very good question. It, strangely enough, directly relates to what we were just talking about, about some literacy, breadth of knowledge, and breadth of outlook. I remember in the sixth grade, I found a textbook, we were turning in waste paper. I found an inorganic chemistry textbook for the tenth grade. I brought it home and read it all. This was before we started studying chemistry in school. I read it completely from cover to cover. I was terribly interested. I can't say that I understood much about organic chemistry, but it's obvious. It obviously served as an interesting hook for my further interest in chemistry. The same thing happens here, when you just read some book about how Go is structured. When you read about interfaces, if you haven't read a lot of other things before, it won't be very interesting to you. But if you've read various other things, I don't know, you learned Java before, you think: "Oh, and interfaces in Java are structured differently." You immediately start thinking about what duck typing is. You haven't written it even once in your life, but you've had other tasks that you solved using interfaces. you're already aware of the problems with multiple inheritance, that like, there's inheritance, there's multiple inheritance, it leads to problems, they can be solved using interfaces. You used these interfaces in Java, and here's how interfaces are structured. So, not even how they are structured internally, but just the Go interfaces themselves, do they somehow relate to interfaces in another world? And if you've ever figured out how inheritance works in C++, know what a virtual method table is, how the compiler does it, then again, it becomes interesting to see how interfaces are structured in GO. You see that there's a reference to a type, a reference to data. If you also understand how a computer works,

how everything is arranged inside, how the processor works with this, how the compiler works, how all this will be presented inside, an example, at least an example of general features, then again everything becomes even clearer to you. And as a result, completely different levels of reading a book are obtained. If you simply do not know, well, figuratively speaking, without any offense, yes, if you have been writing CRUDs all your life and believed that programming is an exceptional way to earn money by correctly arranging fields in JSONs, and implementing APIs according to a paper, then it is understandable, yes, if you start reading a book in Go about Go, the benefit will not be very much. But if you have a sufficiently extensive baggage, such reading will be interesting in itself precisely because you have things for comparison. You gain much greater awareness when reading, because you stop just reading. So, what is reading? It can be that we simply read facts and stack them up. This is the worst way to read. It is practically completely useless, because, well, nothing will be retained in your head. Not completely useless, but practically useless. Not completely, because if, well, at some point you only had one stack in your head, yes, this first stack must come from somewhere, seemingly useless information, but if you already have a bunch of stacks, if there is a whole forest and connections and so on, then when you read this book, it does not hang in a vacuum, it is integrated into this tree of connections and dependencies, into this panaceic cloud that is in your head. You understand not only what people wrote, but also begin to understand or guess why they wrote it, that is, why they did it this way, what problem they were likely solving, even just from some hints and other things. In general, the most important part of learning Go is, for example, to read why the language was written in the first place, which answers many questions. >> That is, they tried to create, >> by the way, this is where the thoughts converge very much. I'm currently thinking about writing a book. I have a chapter about this, I don't know if you've read the posts or not. I have some testers who came with this and said: "Well, write a book someday in the distant future, I plan to do it." But it's funny that I'm already sketching out the structure. And I really want to start with why Go was invented. That is, and I wrote a post like that, figuratively in an artistic style, that these guys got together, who invented it, and they discussed why, well, that we want to create a new language and why they came to this at all. That is, it seems to me that this is almost the key part of the book to ignite the reader. >> Well, generally, of course, it doesn't start with "we want to create a new language," but with "I'm tired of this." >> Yes, yes, exactly, exactly that's what I'm talking about, that they sit, they first complain that they have long compilation times, some other problems, I don't know, memory problems, allocation problems, what other pains were there. And then they come to the conclusion that maybe we should make another language that will solve all these problems. I'll send you that post later, you can read it. I've already read it, I think. >> I read it, I think. >> Right. Well, about what you're saying about experience and Well, yes, that's also there. I completely agree with that, but it's a bit different. Experience and the need to read are slightly different things. It's one thing when you simply know the interfaces in other languages and you're just really interested to see how it's done in Go. It's much more interesting, of course, than studying an abstract interface from scratch. But there's also the point that even if you don't have much experience, for example, because you don't use interfaces, your code becomes bad, scary, you have to, I don't know, a lot of different implementations, your compatibility suffers, and you think: "Damn, how can I live with this?" And you don't understand how to solve the problem? Then someone tells you: "Look into interfaces." I actually had a similar situation, not about interfaces. I'll remember a specific example right away. When I was just learning to program in Visual Basic, I wrote some games, like Sea Battle, Tic-Tac-Toe, I sent them to guys on the forum, like, look, everything has gotten out of hand, it's scary, I can't deal with it. I reached a dead end. And they told me: "Why don't you use arrays?" I thought, what are arrays? And, when I read about it and understood what arrays were, I had an epiphany, I realized that everything, finally, everything would move forward from a standstill. And, you know, what was my code like if there were no arrays, in the style of Indians who write without ifs. >> Listen, I still think these are different things, completely different things. And we're mixing them up. Yes, I'm saying they are different things. >> Learning programming and learning a language. studying a language. You don't even need to teach a language, you need to study it, yes? We need to teach programming, and a language needs to be studied. And in this sense, when you learn programming, you study practices, approaches, various options, algorithms, problem-solving methods, and so on. And when you study a language, if you already have baggage and you already know how to program, then there is no such problem. You are no longer looking for arrays, yes? You know that such a problem exists and you are looking for how it is solved using the tools of this language. You are already doing a targeted search for a specific solution to a problem using this tool. Completely different things. That is why, I say that if you are studying programming, learning programming, then you need to take a book, move through it sequentially, study, try, experiment, get hands-on, and so on. And if you are studying a language, then you don't need to read any books. Sit down, start writing, because you will start writing, you will open the editor. So, how do I start a program here? You open the manual, look at how "Hello World" looks, write, so, the starting code. Okay. All right. So, I need to do this. So. Well, okay. This seems obvious. Here, we have prints, arrays. Like this. No, well, I'm exaggerating a little, of course. It's clear that you'll probably first read the basic syntax: the list of operators, ways of declaring variables, ways of declaring functions, procedures, basic data structures. This is completely obvious. So, you understand that without this, you won't be able to write anything. Therefore, you will read the first 10 pages. In this sense, by the way, Go. I really like it. I always emphasize this and praise it for it. They have OFGO, which takes about 4 hours. Now, probably more, when I was there, it was about 4 hours. You spend 4 hours, and I know kung fu. You sit down, and you can start writing, because you have touched all the basic constructs, absolutely all of them, and after an hour you can stop altogether and start writing immediately. Well, it's better to finish if you already know how to program. So. And then everything is elementary. You start writing, you almost immediately run into a problem, because everything seemed obvious, but it's not obvious at all, but the book, the documentation, you open it, look at it immediately, and move on. Therefore, your example with not knowing what arrays are, being told, and so on, is probably not the case to consider if we are talking about how to dive into some new language. You still need to be a programmer to dive into a new language. >> You need to break it down, yes, I agree, people who are learning something from scratch and those who are experienced experts learning some new technology. But, well, about books, I also wanted to say that, first of all, the choice of source is very important. >> Yes, yes, okay, >> before we run away. As for the option of reading the first pages for syntax. Personally, I used the site "Learn X in Y minutes" in my time. Well, like X Y minutes, where if you know one or two languages, you open the site, and in 20-30 minutes you can learn a new language. Well, at a basic level, how arrays are declared, how functions are passed, you understand, right? It's all this. I studied several languages this way in my time, starting with this. And so, after reading this page, one page per language, you open the editor and start transferring some constructions to the syntax of the new language. Well. And if we are talking about Go, we had a case precisely about the speed of learning Go for a candidate who wrote in Go, but was a good C++ programmer. We gave them tasks, homework, well, to good candidates. Well, it was normal for a C++ developer. Well. And there was a guy who learned Go and brought us a ready, quite decent solution in Go. The task was something like making a simple RS. That is, take a file locally and distribute it to several other machines, well, instances, yes, and put them on disk. Such a task in 2 days, over the weekend. That is, he learned the language, he more or less figured out how to do things, goroutines, channels, networking, and after 2 days he brought us a solution. So if you already have experience, you already know other similar languages, yes, then, for example, from Haskell to Go will be difficult to switch, but from C to Go, well, in 2 days the person switched successfully. That's great, yes? The code was, of course, requiring review. Understandable. You can't learn Go in 2 days, right? But it was working code, correct, using constructs that are not in, say, goroutines, for example, channels, but they were there. So, yes, learning the syntax of a language quickly, like X for Y minutes, and then sitting and writing code, trying it yourself. We skipped the topic, but when I was learning Pascal, learning some first languages, yes, there were first ones and so on, I took the code from the textbook and tried to change it. I didn't go further to the next chapter, but I took the code and added a loop, changed numbers, changed a variable. What happens? Does it compile, or if it's a translator, an interpreter. Right. Right. And what will happen? What if I do this? This is also, I think, a very good way to expand understanding. Not the path, as I said about the tunnel, yes, about books, yes, but you go to the side and try to change something in the task that you already understand, to learn something new. >> Well, yes, I agree. In my videos, which are practical, where I just, well, essentially, it's probably similar to these books, where I just write code, show how to write it, and explain. I always say there, try to vary it, write it differently, rework it. Well, specific examples often arise, for example, here I'm using PostgreSQL, and you try, I don't know, to connect MongoDB or Redis. You'll have to use your brain, not just blindly copy what I'm writing. Because if you just copy, something might remain in your head, but less than if you do it yourself. Well. Or, for example, there's a book, you know it well too. It's writing an interpreter in Go by Thorsten Ball, right? The author. Msal, well, I didn't really like his code, to be honest. I don't know if you've read it? >> Yes, I think I even have it here. Look, I bought it not to read, but just to have it on the shelf. >> I understand. There is such a thing. I read it in electronic form too. And his code is not very beautiful, I didn't like it very much. And in places I understood that it could have been done better, more optimally. So I did that, I also wrote the same interpreter, but I wrote it my own way, more beautifully, as I liked it more. Well. This is also, I think, a good way to immerse yourself better in this book. In general, about what Gleb said and what we are discussing now, I'm more about this: if you pick up a book and you have a desire to read it, you have a desire to gain the knowledge it contains. And if you just pick it up and read it from cover to cover, it might happen that your brain doesn't really absorb it, even if you were interested in reading it to some extent. Hmm, you're just reading a set of abstract information, which you don't yet know how to apply. But it's another matter if you have real pain points and needs that the book addresses, then it becomes more interesting to read, and it's better remembered, and you understand a lot better. So, if you don't have these pain points yet, then, well, maybe this book isn't very necessary for you. That's one conversation. But it's another matter that you can create these pain points, at least artificially, or even not artificially, but simply by changing priorities. That is, you first try to get burned in this technology, something. Well, you read, yes, there are such books even about Kafka, for example. Figuratively, you want to read about Kafka, but you don't know what Kafka is. You can try to set it up, understand why it's needed, stumble a couple of times, and then it will be more interesting to read. Possibly. Well, that's my approach. Usually, I try to do that and, well, yes, practice in the process. There's also the point that books can be. Sorry, just a quick question to you. Will you let me go? about Kafka, you don't know what it is. You just tried it, moved on, right? And wasn't there an idea not just to try Kafka, well, as an example, yes, but to apply it somewhere in your own life? >> Well, I, yes, that's what I'm talking about. >> Not just somehow, but to add it somewhere existing instead of what? >> At work. >> Well, at work, it's unlikely, yes, they won't give you an unknown project. Well, that is, not just to take a course, yes, which there, but to do something for yourself. No, I'm talking about that, I meant, >> yes, that before you read a book, try to apply it somewhere, understand why it's used, maybe in some pet projects it will work. A pet project can generally be "owned," that's probably the only place where you can and should "own" it, to play with it. Well. And, well, about books, they can be different in principle. And if you take the same one, when we talk about how to read a book, and whether to read it is still a question of what kind of book? For example, take Petzold. He has a very strange title in Russian, called "Code: The Hidden Language of Computer Hardware and Software." The title is off-putting. It seems like some, I don't know, like I bought it from a kiosk to read at the train station, something like that. And visualizing my desires, I immediately remember quantum mechanics, wormholes. Well, okay. No, the book is not about that. The book is great, one of, probably the best, about low-level things, about computer structure. And you can honestly read it from cover to cover, because it throws all these problems at you itself. That is, well, figuratively speaking, that my friend and I lived in neighboring houses, and we, I don't know, to prevent us from calling each other on the phone, we communicated with flashlights using Morse code, and then he was somewhere around the corner, I don't remember how the structure was, like he lived around the corner, we, figuratively, put up a mirror to reflect. Then they moved apart somewhere, and they figured out how to transmit signals over a telephone wire at a distance. And he, well, not a telephone wire, but a wire. And so the book progresses step by step. And it first presents you with a problem, and since it's written in a somewhat artistic style to some extent, you associate yourself with these characters, and it becomes interesting to you how he will solve this problem. Such books can be read without any formal preparation for them. Well, essentially, the course that Gleb and I often talk about, "From Nand to Tetris," is essentially about the same thing as this book, that is, only there you, well, maybe the structure is even a little worse than in the book, because there they first tell you the theory, then they advise you to write something, and you write it. Well, this is also a purely practical approach. And, well, we'll get back to this too. Books can also be different in that they can be too complex and useless for you. For example, my career started with a couple of people recommending books to me. I often mention this too, "Structure and Interpretation of Computer Programs," SICP. Essentially, that "butcher" recommended it to me when I was just learning to program. I didn't pass the programming interview the first time. And he said: "Read this book, come back, and I'll hire you." By the way, I just remembered now, he also lied to me. That is, I read it later, well, not entirely, okay, but I didn't mention it. I called him, said, like, I read it, like, what, quite a lot of time has passed and formally I could have managed. He said, like, no, I have to refuse. Of course, it's an insult to make a person go through such a path and not fulfill his promise. But another book, which was recommended, is "Java Philosophy" by Bruce Eckel. Well, by the way, it's a good book, but also not at the right level. I read it almost to the end, but it all evaporated. And essentially, I wouldn't recommend it to any beginner, because it's for those who have been programming in Java for a long time, and not just for those who write in Java, but have written a lot in other languages and are now reorienting. If there were a book "Go Philosophy" in the same style by Bruce Eckel, I would read it with pleasure now. But you need to choose books according to your level, because they can only scare you away more, confuse you, and at best, just waste your time, and at worst, completely discourage you from the profession. >> I had a similar experience with Go, not Go itself, but when I was fascinated by compilers. I had a period of several years, I tried everything about compilation, interpretation. Well. One of the first books recommended was the Dragon Book. There was the first edition, but I wouldn't recommend anyone to read it without knowing anything, even now, to start with the first edition of this book, because it's a very academic book. If you at least start, start with the second edition, where there were at least examples closer to reality, code examples, yes? And it's better to start with some more human-friendly options, for example, I don't know, there were books by Niklaus Wirth, I don't remember the title, about compilers, there was a book, "Let's Write a Compiler" by Levy or something like that, Levy, I don't remember. These books are much simpler than that. And then, when you understand that the topic is yours, you already remember what unfolding, descent, and so on are, you can return to the Dragon Book and there you will find out that you can also make compilers differently. Then all sorts of beasts, yaks, and so on will come. Well, that is, the fact that you were recommended this book "Structure and Interpretation of Computer Programs" is a very harsh, in my opinion, "thrown into the water, learn to swim" approach. That's roughly how it looked. Of course, if the person gave you something simpler, and if you had read it, you would have liked it, they would have given you something more complex, it would have been more useful and wouldn't have scared you away from compilers immediately. In many areas, there are introductory books. >> Well, it's better to read them, not immediately with some whip, for example, yes. Go ahead. >> I think we need to distinguish between textbooks and books dedicated to a particular problem. That is, a textbook can be completely incomprehensible, yes? That is, when we pick up a textbook, we may know nothing about this problem. The main thing is that the first page is understandable. Theoretically, after reading the first page, the second will be understandable. And so on until the end of the textbook. And presumably, by the end, we will have delved into a problem that was previously unknown to us. It is clear that a textbook, I don't know, any university textbook, is an ideal example of such an order. There are similar books in the field of programming. And you should read such a book only if it is necessary, because such reading, as a rule, does not bring any pleasure. It's work. It's quite hard work to learn. We work, we get new information, which is difficult for us, previously unknown. We do practical assignments that are given there. Every textbook has practical assignments. And by the end, we will have learned something. It is assumed that by the end, there should be more and more practice, but the important thing is that it is a textbook. It is a completely special structure, a way of presenting information. And there are books dedicated to a particular problem. Well, I don't know, "Philosophy of Go" was mentioned, excellent. Oh, "Philosophy of Java" could be such a book, "Philosophy of Go." There's a book on "Clean Code," and so on. These are books dedicated to a particular problem. If you read "Code" by McConnell, >> well, yes, if you read this book and about 90% of this book does not bore you, then you are reading this book in vain. If you open it, start reading, and everything is new, then you simply haven't grown up to it. It's not for you. You won't understand anything. You'll read it, it will be terribly interesting, but there will be almost no benefit. There will be 10% benefit from this book. Normally, you should already know almost everything that is written in this book in advance. And this book should be, you read it like this: "Well, I've always done it this way. This is obvious, this is also: "Oh, cool, I didn't think of it that way. And this is something new. Uh-huh. And this is also possible. Not a bad idea. And here the author is mistaken. Here he's writing nonsense. Don't do it this way. Don't do it for anyone, I don't recommend it." Then you are reading the book that you should be reading now. And if everything is new, it's better not to read books about a particular problem. >> Interesting thought. I've never really thought about it. I've sometimes filtered out books that seemed to me, well, I already know almost everything. Now I don't read any books about Go, because, well, it seems, why? I seem to know a lot about Go already. Well, maybe not everything, but, well, what I need, I know. For example, cloud Go, errors in Go. Well, maybe it's worth reading, it seems so. But I'm postponing it, because there are more important things. And you need to skim it. You need to read it quickly, as if diagonally, and you will regularly stumble upon things. Which >> There's also such a personal quirk. I don't know if it's common for many people. When I read a book or, I don't know, watch something, I somehow want to finish it from cover to cover, and if I skip something, my brain says: "Damn, I'm starting to worry that I might have missed something important." I even read prefaces often, because what if the author reveals something important? I don't know how to deal with this, but do you have that? >> No, >> I skip the preface, but there's a book where I read it after reading the book. And it was a translated book, and the translator took a very creative approach to translating English terms and tried to find terms that are used in Russian, but he considered them more correct. I read it, grab my hair, and say, what's going on? Then I read the preface and understood. But usually, I just skip the preface, all sorts of thanks to everyone, my family, friends. I say, "Page fifteen, let's keep reading." I >> had a book only because of the translation. Just because of the translation. >> I understand that this is a bad habit, but somehow it builds itself in my head. It seems like, damn, well, the author designed these rails for you. If you go all the way along these rails, then you will understand it.

But I am gradually learning to fight them. And so I agree that it, possibly, greatly hinders me from learning, that I do not try to read some books, like Gleb says, selectively or diagonally. Well, possibly, this is good advice. Here. Well, I need to think about it more and try. By the way, it's all individual. When you start reading a book, tell yourself a mantra. So, firstly, I am smarter than the author, because I would have written better. I'm just lazy. And the author can do nothing else, because whoever can work, works, and whoever cannot, teaches. Therefore, I am still smarter. But now we will see what he has scribbled there, and everything will immediately become easy to skip. >> Well, there are different levels of learning. It just, while you were saying that, I remembered a phrase from one of my teachers at the Faculty of Physics, a mathematics teacher. He said that there are different, well, it's a bit off-topic, it just came to mind, there are different degrees of understanding. Like the first is I understand, I can repeat. The second is I understand, I can prove. And the third is I understand, I can refute. I liked that phrase so much that I still remember it verbatim. And, well, yes, what you are saying, that this is already the highest degree of understanding, when you read a book and you can argue with the author. This is exactly understanding, I can refute. >> I quite often ask people in interviews >> to tell me why Go is a bad language. You shouldn't write in it. And what do you want to hear, if it's an interview? That the person thinks about this topic, >> that it seems to them, well, look, if you don't know the language, you can't criticize it, you just won't be able to, you'll have nothing to present to it. In order to present anything to the language, you need to actually write in it. And what the language is good for, you can read in the preface to any book. But what it's bad for, they usually don't write. Well, you need to read other books, yes, there, I don't know, Gover, there, not something like that to read. Here. >> Well, and if a person if a person, for example, well, it just seems to me that our viewers might have a mistaken opinion that this is a question from the category of, like, where do you see yourself in 10 years, name your top work fails. And and you need to correctly, ah, even no, not correctly, a fail. A very good question. name like your top personal shortcomings, like that. And for them, there is simply a correct answer, there are incorrect ones, and are there any? So, firstly, what if a person has never thought about whether Go has shortcomings at all, and he will rack his brains here and may not say anything coherent to you, or may say something. >> I'm in a hurry. >> Well, you won't answer anything. This won't be a stop signal for you. >> Well, it will be, of course. I, well, I mean, if I'm not taking a person who, uh, a junior, who comes and claims that he has a good background in Go, that he's a lead, or something like that, there, I don't know, a senior or something, right? >> And he has no complaints about the language. >> I don't know, he hasn't passed arrays anywhere, right, there, like in a loop in a forum, he hasn't cited it. Well, yes, I agree. Here you can tell some pains. It seems to me, next level, to criticize, at least to start by explaining to another person. This is already a check of knowledge. >> Well, yes, this depends on the developer's level. >> If you can't explain to another, you don't understand yourself yet. And in general, if you can criticize yourself, you are already >> this is not always the case, >> because the best way to learn is to tell someone else. >> Well, to explain, right? >> So if you want to learn a language, teach another person this language, >> write a book about it and speak at conferences. Yes. >> Not always no. The funniest thing is no, because the most important part of learning is feedback from a person. When you write a book, you don't know what readers think about it. When you speak at a conference, well, at best, the reaction of the audience, right? So you usually feel if the audience is listening with interest or everyone is asleep, and you're mumbling into the void in front of the microphone. When you teach someone, it's a dialogue. You tell the person, you immediately see what they are doing, and you understand whether what you told them is clear to them or not, whether they are doing it correctly or not, and as a result, you immediately start to understand, uh, what you yourself don't understand. In this sense, there is a wonderful anecdote that children laugh at, but there is nothing to laugh at. It's when the math teacher comes into the teachers' room and says: "Imagine what a great class I got!" I told them the theorem for the first time, they don't understand. I explained it the second time, they don't understand. I explain it the third time: I understood myself, but they still don't understand. This is funny in school, >> but in reality, no, because if you want to teach someone, meaning, if you want to learn yourself, teach someone. This is without any jokes. This is a perfectly working recipe. And in the process of teaching another person, a language or technology that you own, you will encounter the fact that you will understand some things yourself, that you cannot explain them. You do it this way, but why? Why does this lead to this? Why not otherwise? Even if they don't ask you these questions, these questions will still arise in your head and require you to study. Well, what Gleb is talking about is not just some seven-minute insight. This is, well, a long-known technique called the Feynman method. Feynman himself promoted this thing, that the most powerful way to learn is when you teach someone else. And in general, one of the reasons why he taught at all, well, and by the way, he taught very coolly. He was probably one of the best teachers, I don't know, in history or something like that. Here. Well, here Gleb is talking about, as I understand it, you are talking about teaching a person directly with quick feedback. That is, you sit next to him, live or online, and explain, of course, ideally. It is clear that if you just make a course or write a book or make a video, as you do, right, it is clear that the process is similar. You yourself act as the interlocutor. You compose the script, read it, try to read it through the eyes of the viewer, the listener, you see some logical gaps, inconsistencies, you try to fill them, trying to explain something, questions also arise, but in the case of direct teaching, the feedback is much faster. This is, of course, much cooler and more effective. >> Well, yes, I agree. I, well, my wife, for example, she often asks me a question. She is a tester, well, that is, she is well versed in technologies, but worse than a developer, obviously. Sometimes she has questions that seem, well, very simple, but I catch myself: "Damn, I need to Google it myself to read the exact definition." Or ask ChatGPT, because I seem to understand, but I can't explain it. And recently she asked me about the portfolio. To my surprise, I couldn't explain it to her offhand in a clear language, what it is, well, it seemed like nothing could be simpler. Well. >> And yes, I often catch myself that sometimes, well, this is still a simple example, sometimes when it's worse, you try to explain more complex things, you realize that you don't understand them at all. And it seems to me, what we have been talking about all this time, it is all more or less related to the fact that the information you have read, you need to play with it, transform it in different ways. And and everything, everything we are talking about, can be generalized, that this is the transformation of information. Something like that. That is, you read some article or book, and it is stored somewhere in your brain, but maybe not very firmly, but then you can do something with it. For example, you practice exercises, solve problems. You return to this information, try to break it down into specific points, how to say, decompose it, extract something from it, then reread it, it may be organized differently. You can also say about a person's question, that you, they ask you a question, and you also find holes or some incorrect inconsistencies in this piece of information in your head and close these holes. And about here, Lesha was talking, we can return to this now. About Zettelkasten, yes, it's pronounced, well, the note-taking method. So there was a guy who >> m and there was a guy who wrote a lot of scientific articles, and he explained that it was because he worked with notes, right? So he takes, reads some book, article, and he decomposes it into notes, which are structured according to certain rules. That is, each note should be atomic. That is, it should contain minimal information, ah, and you need to break down information into such notes. And it is important to link them together. Well, he did it hardcore on paper, then. Now we have better electronic methods, where it is much easier. In essence, this is also a way of working with information. You take and try to transform everything you have read in your head, play with it. And all this, well, probably affects some neural connections. And again, when I teach someone, even without quick feedback, I am essentially trying to deform this information. That is, for example, I want to tell someone about the same Garbage Collector. And if I just read about it, oh, Garsh, what I recently told about the scheduler in videos, if I just read about it, well, that's one thing. But when I try to explain, questions immediately arise for me. That is, well, yes, as Gleb also said, this person asking the question, I imagine my virtual subscriber who will not understand and imagining myself in his role, and I ask, I write some complex phrase and I realize that, damn, it's not obvious why, what it is, why it's needed, and I try to explain it. And this is also working with this information. Can this be generalized somehow? >> I have a similar experience. As a member of this conference program committee, we curate our speakers, conduct their rehearsals, prepare presentations. And one part of the preparation is a rehearsal of the report by the curator with, well, the speaker. And during it, we ask questions, as if we are sitting in the audience. Stupid, on-topic, off-topic. It often helps the speaker improve the presentation. Including he understands: "Ah, I didn't think about this, we haven't checked this, I don't know." This also gives him immediate feedback, and he can do something, improve it, I think, as an example of quick feedback in the process of improvement. >> No, you finished, you're like >> I finished, I got distracted, yes, that the microphone wasn't purring with code, right? >> Ah, yes, it's not audible. And one more point that I remembered, that I often heard good advice, and I've tested it myself, although I'm too lazy to do it, is that when you read a book, it's also good advice to underline important thoughts, literally with a pencil. And it's better when you read a PDF, underline with a stylus, highlight with color, you also make your brain work and perceive this information differently, that you didn't just read it, but tried to extract key thoughts from it, understand what is new, what is not new, what is interesting, what is worth returning to. I really, when I read with a pencil, even if you just don't want to spoil the book, at least mentally with this pencil or not mentally, just move it like this and pretend to underline, you actually don't write anything, I don't know, you move with a stick, you pretend to underline, you already start to understand better, remember better. M. And, I lost my train of thought. Ah, well, yes, there are also these, this is also one of those important areas that can probably be put here, it's learning speed reading, not infociganism and marketing, but good advice. For example, when they advise you not to go back, not to reread a sentence several times, all that. But one of the pieces of advice is that you build a mental model in your head. He advised, for example, the author of one of the books, to imagine a little man, let's say. Well, it works for him. For someone else, it might be different. Like the head is a person, what you have newly learned is somewhere in the hands of the person - this is the data of the article, the author of the article. And when you read, like, you can train yourself so that you automatically arrange all the read information into such shelves. And, well, I haven't forced myself, I haven't taught myself to do it, but the idea is also interesting, when you try to do it. It seems like you really remember and assimilate information better. Well, this can be compared to that underlining. >> In essence, everything that happens here, everything that happens here, is repetition. This is a banal technique that makes you repeat again, return to what you just read. When you underline text, or arrange it in certain places, repetition occurs. Uh, the mind is structured in such a way that information that enters it and is not used is forgotten quite quickly. Any attempt to read from long-term memory, unlike a computer, does not place this information into a fast-access cache. It's already there in fast access, but it places this information into the "inchester" when you access it. And the more often you access it, the more its TT, the longer it needs to be stored. Therefore, if you read something five times, it will be stored, well, not five times longer, but, I think, the dependence is exponential, right? That is, the information that you access, that is, the information that you access a sufficient number of times, will be stored for life. Well, >> I think that's very simplified. That is, if you, >> of course, simplified, it's a model, >> if you just reread the same book five times, it won't be as useful as following the advice we gave above. >> No, if you reread it five times, the same thing will happen. It's just that memory is limited, and other mechanisms will start to work. You will run out of space, and it will be thrown out due to volume. That is, it will no longer be thrown out by time, but simply because your volume is exceeded. >> You just need to reread not the book five times, but also read the notes from the book. >> Of course, of course, that's right. That's why notes are made. That is, normally, what do you do in college? You make notes. You reread these notes, because the book won't fit, but the notes will fit. Well, in essence, this Zettelkasten method is an extended version of your notes. It's just that you write it, well, like, notes are still a repetition of the same material, the same structure of this book, and you reread it. In essence, you are reading the same book, just shortened, and notes, you build a mental map from them, and you reread them, well, you constantly replenish it, and you are no longer going through one book, but through, I don't know, ten books that you have read, and they intersect somewhere. That is, a specific thought became interesting to you, for example, garbage collector in GO, and you read and look. Aha, here I have a link to, if you linked it correctly, to something else, to a memory model, for example, you read it and so on, like on Wikipedia, you go deeper and deeper and maybe find some new connections in the process. >> That's right. Only not exactly as you say. That is, when you read a book and take notes, uh, it's exactly the same notes. But since technology has advanced and we now make notes not on paper, we get additional profit from this. Because if we categorize the information in some other way, not just record it, but also categorize it, assign tags, keywords, and so on, then we can easily find everything related to this topic. And this gives additional profit, because it is much easier for us to repeat the same processes on paper that happen in memory. Because in memory, as we discussed today, right, when we talked about learning, you read a book and you remember, there was something like this, how is it connected? These connections are formed in your brain on their own. It's clear that this is all very simplified, and we still don't really know how everything is arranged in the head, but judging by the observed effects of this black box, information also contains some labels and tags. And it is linked within by these labels and tags, because it is quite easy to recall things connected to something, united by some criteria. The same thing happens when we keep such notes either in a wiki or like cards in some Obsidian, right, we form such a map. But when we study a book, we essentially make its notes, but this gives us additional bonus features. >> No, I agree. Yes, in a sense, it can even be said that it is notes. Well, firstly, yes, it will be easier to read. And secondly, there is another bonus, that you are not just silently rewriting some thoughts, but you are also trying to categorize them. And the process, uh, this very process also allows you to delve into it better at the moment of reading. >> And you also rephrase, because writing it down as you read it takes a very long time. Therefore, you have to express it in other words. And in order to express something in other words, you need to understand what you want to express. Yes, this is one of the main pieces of advice for introducing this Zettelkasten, that when you read a book electronically, you also take notes electronically, you have the temptation to Ctrl C, Ctrl V. And as a result, you can reduce it to simply copying the entire book, transferring it to Obsidian. And there is very little sense in this. By the way, I have another approach when I read complex articles, especially when I need to dive very deeply into it, not just to figure out how something works and use it at work, but when I need to explain it. That is, well, by the way, returning to learning, when I study some technology, just to understand how it works and apply it, I dive, well, quite deeply. But when my goal is also to teach others, understanding that some questions may arise, or something else, then I dive even deeper. And in such a case, I need to process more. And it happens that I take some long article about the Garbage Collector, let's say, or the scheduler, I move it to my Obsidian to break it down there. To cut something out of it, because it wasn't interesting to me, to rewrite something in my own way, to ask some questions, that is, well, how to do it, like drawing in a book, only much more flexibly. And I just came to the conclusion that when I read an article, it's faster for me to take it for myself and modify it there. And then, when it comes to something like this, sometimes I start to break it down into notes, and in that case, it works faster. Something like that. Well, I think we've managed to summarize it quite well here. I didn't have such a complete picture in my head, it only comes in conversation. I really like this process. Okay, well, let's. We've already spent quite a lot of time. The timing shows 2 hours, but we started a little later after the launch. Well, almost 2 hours, in short, we've been discussing. We can move on to the next part about discussing the golden fund of resources, books, and so on. Well, for example, mm, the overused Nantu Tetris. I don't know, Gleb, let's start with you, because I already know what you're going to talk about. Can you list the resources that absolutely must be read, tried, and explain why. Deadlock Empire again everything even. >> Listen, well, it's a very difficult question, unfortunately. I have a very short list of resources. I, as a big proponent of practical learning, so with the help of which book you will do it, it doesn't really matter. There are resources, well, I can only repeat, right, that hooked me because they turned out to be extremely useful in learning and touching upon a topic that no one, no one, from my point of view, explains so well. Firstly, the Nantu Tetris, which has already been mentioned, I think, for the third or fourth time, as from my point of view, a perfectly structured course for studying how a computer works. That is, it is learning, starting from how the simplest logic element is structured, and how, starting from the simplest logic element, from NAND, the only element that is sufficient to build any logic circuit, how, starting from it, you can end up, essentially, with a game running on a computer created right on the computer, a virtual computer with an architecture that is built, again, with your own hands from beginning to end. It is quite short, quite interesting, and, consequently, after it, you will have a complete understanding. Well, we are not considering completely modern schemes. Of course, modern computers are much more complex, but there are no fundamental differences. Here. That is, you will understand everything about how memory works, how a compiler works, how a processor works, why calculations in registers are so fast and why any indirect addressing is so slow. You will see all these cycles, touch them, feel them, write a simple compiler yourself, a linker, run a program, that is, you will start to finish with a primitive operating system if you reach the end. >> I missed it, you said what is Nantn at all? A person will read it in a book. Well, generally Nantn, it seemed obvious to me. end, that is, a logical operation that >> combines and end. Well, that is, it's some kind of trickery, right? That is, when we say that a single logical operation is sufficient, in fact, any two logical operations are sufficient, as Boolean algebra tells us, and NAND combines two operations. It performs notend. And that's enough, obviously. You can restore OR, and assemble AND. Well, and all the others from this too. The first thing. The second similar thing is Deadlock Empire. This is also something like a computer game course, which everyone who encounters multitasking, working with parallel processes, multitasking primitives, in one way or another, should go through. Because, firstly, again, it will become clear how they are structured, it will become clear that it is fundamentally impossible to write an absolutely safe program using multitasking primitives, because no multitasking primitive is absolutely atomic. And, therefore, situations are always possible when the program will behave incorrectly. Only the compiler saves us from this, which adds additional restrictions and writes code correctly so that our programs work. But in general, since the compiler can also make mistakes, it is obvious that a multitasking program cannot work correctly in principle. It cannot work absolutely correctly, in principle. Well, it can work correctly enough. What else? Well, obviously, if we are talking about books, you must read something about algorithms and data structures. This is a matter of general education, which is not so important. You can take algorithms from Grok, or you can take something ancient like >> Wirth's Algorithms and Data Structures. It's not fundamental. Nothing has changed. since the seventies-sixties in this area. Well, almost nothing. Okay, the same, I don't know, sort, I think, was written in seventy-something, so I'm probably exaggerating about the seventies. Here. Here. But if we take the two-thousands and don't delve into things like cryptography and so on, that is, into mathematics, curves, I think they appeared after two thousand, right? Because everything else was before, >> then again, as it were, this will be more than enough. Regarding the frequently asked question about all sorts of LeetCode and so on. I don't like it, I don't like it. >> Let's elaborate a bit, >> yes? Firstly, explain why. And secondly, you often emphasize practice. That is, well, how to learn algorithms without practice, and even without LeetCode. Well, for example, it's clear that you might encounter them at work, but if you read about, I don't know, red-black trees, binary reversal

Trees, you need to practice, in short, tell me how you read. Is it necessary? I think, I think, it's not necessary. I think, there's no point. You need to know about algorithms. Well >> you mean you don't need to read specifically about trees or something? >> No, no, no, no. You need to read about trees. But you don't need to practice. Why? Because, firstly, they are already written and you just need to know that they exist, these algorithms. And you need to practice on simple tasks. That is, what I don't like about LeetCode? The fact that these are competitive programming problems. They are simply, >> well, not all of them are simple. Okay. Simple tasks. Yes. >> And you mean that they are isolated? Yes. Abstractly isolated. Yes, they are isolated. You solve this little problem. If you take some trivial, God, what is it called, Abby? Damn, I forgot the link. Well, we'll find it later, like, even I understood, yes, there is a very simple course, uh, which is structured as follows. The same simple tasks as on LeetCode. They are quite simple, there are not very many of them, but, unlike LeetCode, they do not contain an editor, nothing. Your task is to write a program, a completely ready program, upload the file, it will be executed there and it will be checked whether the task is solved correctly or not. Why should it be done this way, and not like on LeetCode? Because when you do this, you write the entire program along with all the boilerplate, with type declarations, with working with these types. And as you complete these tasks, we are talking about learning programming, not a language in this case, as you do these tasks, you realize that I'm doing this damn thing for the fifth time. I'm writing a function to read, uh, and parse a string with data for the umpteenth time. And you have to do all this. This is not LeetCode, where you already have a ready-made array at the input, you need a ready-made array at the output, and you just need to write a function that works with this data. You need to write a complete program, and you start to realize that I'm tired of it, I want to create some kind of library, I'll extract this into some classes. I read about this here, and it worked out for me. And as a result, by the time you finish this course, you will not only have tried the basic programming algorithms, solved some basic tasks, but you will also have accumulated a codebase with your own standard methods, functions, or at least problems that have started to bother you. And in the case of LeetCode, it's just code, it's just a piece of code. But it's meaningless. We don't, as a rule, engage in complex algorithmic tasks. Such things happen rarely. Is it necessary to learn this? Well, you can, you can learn. Is it necessary to focus on it? From my point of view, no. And in this sense, reading algorithms is understanding how this algorithm works, figuring it out. If you like it, you can try to write it yourself. But it's important to know that it exists. It's important to know its properties, it's important to know the principle of how this algorithm is structured, because you will use these same ideas in other places later, because any algorithm, uh, is built around some idea, quite often some mathematical concept, which you will get acquainted with along the way, while reading about this algorithm, because programming, in fact, is inextricably linked with mathematics. However strange it may seem. Well, the algorithmic part. That's why I would approach all these courses and other things like this. Books dedicated to programming problems, like clean code and so on. Well, I already said, yes, you need to read. Well, but still, >> if you read about some complex algorithms and data structures, then, what we talked about in the first part of this podcast, that reading a book from cover to cover is not very optimal, that you need to combine it with practice, but it's unlikely that you will well understand some complex trees, like red-black trees, for example, if you don't practice. And how to practice? Uh, does anyone have anything on this topic? Well, that is, you might understand the concept, >> yes? But you need more. And you need more. >> You understood the concept? >> Well, and then you come to an interview at Yandex, and they ask you, >> and I'll ask, why does he need this? >> Well, it's clear that Yandex is a somewhat exaggerated case. You just won't pass, I won't pass. But that is, you think, if the company asks about complex algorithms in an interview, again, dynamic programming often occurs, there are some tasks that, well, they don't tell you that it's dynamic programming, but they boil down to it. Here. But I don't know dynamic algorithms, I've tried to solve them with varying success, but I've never used dynamic algorithms in real life. >> No way. >> Well, it's complicated. Well, this is just one example, that, in general, you think that if they ask you something in an interview that you haven't grasped well and you didn't need to grasp it, it's a complex concept, then maybe it wasn't necessary to ask it, maybe this company isn't for you either. >> Yes, I'm sure it's just not necessary to ask. Well, no, probably, there are positions, probably, there are such positions where it is needed. Well, then it's a special case, it shouldn't be considered. Again, well, you can't explain how, approximately, the idea of red-black trees works, how it differs from a regular one. >> Well, I can't do that now. >> I've read about it several times and always forgot. >> Well, then, perhaps, it's not necessary. Uh, it's important that, you know, that is, the main thing is what? The main thing is that you understand that such an algorithm exists, that with the help of this algorithm, you can solve quite complex problems related to, like, balancing a tree. Well, essentially, balancing, essentially, yes. So, all that we are achieving is optimal tree balancing in a reasonable time. >> I thought about it, that perhaps it depends on what stage you are reading it at, because when I was reading about all these concepts, I was, well, maybe at the junior level or something like that. And if I were to reread it now, even just rereading it, I would automatically map it to some of my life experiences or at least be able to come up with some stories when it could have been useful. And maybe it would be much more useful that way. Well, what you said about experience, about being well-read, that you, the concepts already overlap in places, and, uh, and plus you understand how to apply it. >> You don't reread. >> Well, I haven't reread algorithms for a long time. Yes, I reread, yes, some. But I haven't revisited algorithms for a long time. >> I skim through it about once every 10 years, >> maybe five times. >> And on what book? I don't know what's lying there now, probably you >> have books lying around. They are written in big letters, Algorithms. I don't remember, >> like red >> there are two red ones. One is red, the second is still still blue. >> Well, the red one is probably Skiena. And sometimes it happens that my eye falls on them. You pick it up, flip through it. Oh, let me quickly skim through this again. Interesting. >> Well, agreed, right? >> Or, oh, I missed this last time. Let me read it. I got lazy somehow, I stopped at this point. Let me look through it again. Well, look, what's important to understand? You don't need the specific algorithm that is solved using dynamic programming methods. You need to understand that there is a concept of dynamic programming, where, as you move through the algorithm, you use the results of calculations from the previous step. That's the whole concept, right? And surely, if you think about it, you have similar things in your regular work without any such algorithms. Some algorithms that are extremely complex are optimized in this way. Well, okay, great. It's important that you know that it exists, and you can come up with it and apply it when it arises. That is, the concept itself, the idea itself, should be in your head. And the fact that this particular algorithm is solved this way, well, okay, if I need this particular algorithm, I'll take it and read it. Moreover, I think that you, by the way, often >> you have rediscovered many algorithms. independently. >> What do you mean rediscovered? Invented or what? Well, >> reinvented, yes. >> Yes, it's hard to say. Well, perhaps there were some moments that I unconsciously invented at work, but didn't think that such an algorithm existed. >> Some kind of search, maybe? No, >> no, I'm just moving the bricks. Yes >> come on. Well, even moving the bricks. Now tasks arise. Well, I don't know, I suddenly recently, damn, years ago, wrote a Bloom filter. That is, I first wrote the filtering, and then I looked and thought, God, this is a Bloom filter. No, unfortunately, such situations don't arise for me. We just, well, in FinTech, especially when it's not super-loaded, if it's a startup, the business load is primary. Ah, well, like the complexity challenge is to understand >> what the analyst wrote there. Uh, this is, by the way, about what when Daniil was talking and they laughed at him at the debates and so on, that like, or he said it before the debates, that like, reading Jira might be harder than Tanenbaum. Like, if a person hasn't read Tanenbaum, then they won't understand Jira. A, but he didn't misspeak that it depends on the company. Well, in our case, it can be said that way, yes, reading our Jira, Confluence, what's more important for us, because there are more specs in Confluence, well, it might be harder than Tanenbaum, because the scheme of how a new type of payment will work and integrate with all partners, all our systems, with our teams, with other teams, you need to understand that. And it wasn't Tanenbaum who wrote it, a simple analyst who hasn't been doing this his whole life, possibly, wrote it. Well, so we have more business load, but less technical. You are describing problems of a different kind. This is a communication problem. This is the ability to solve communication problems. Because where does the problem arise for you? Did the analyst want something complicated? No, he just expressed it as best he could. Well, wait, wait. Just as soon as you figured it out and did it, the task was technically not difficult and logically not difficult. It was difficult to understand what needed to be done. Yes. Yes. Yes. Well, so it's a communication problem. It has nothing to do with programming. It has to do with the ability of leather bags to communicate with each other. >> Well, I'm not saying it's a problem. I mean, in some areas, you have, technically, well, the essence of the task is business-oriented, well, very short. That is, you don't need to understand much there, that is, the concept itself that you are implementing is not complicated, but sometimes you need to learn a lot of terms, how the banking system works, how exactly this particular part of the banking system works, and in the end, it results in, well, not a lot of code, maybe, I don't know, two lines. Well, of course, not that much, but. And sometimes, if you work with high load, the business load can depend on the business load. It's literally, we have, I don't know, 1,000 payments processed, we want to process 5,000 payments. That's all you need to know. And how to do it? Here you will technically sit and invent and optimize all this. Well. >> Are there any interesting tasks outside of work for Kolya? Well, well, not interesting, but more relevant to this example. I have some kind of pain that I suffer from. I'm just explaining that I'm rephrasing, yes, >> not everyone encounters this at work. And yes, here, I understand what you're getting at, that this is exactly what I mentioned, you can and should over-engineer your pet projects. Uh, I don't know, like, you, uh, want to make something simple. I have an idea, like, to create a language learning service, well, not exactly like Duolingo, but one that just helps you learn words using SRS, like a repetition system, that one. Well, you can make it simple on the fly, and it will work, or you can take and add microservices, and Kafka, and put it in Kubernetes. Uh, well, like, why not? I'm writing it for myself for fun. At the same time, I'll also figure out how all this works. I look at it that way. And then you can also try to create artificial load on it. Now, tools have probably advanced a lot, that they can make it quite similar to organic, and try to deal with it. >> I'm against this approach, by the way. >> We I know, we discussed this with you back in guiding when I was trying to create load testing for us. You said that >> no, no, I'm not talking about load testing, I'm talking about I'm writing a pet project, so let's put everything in there, from Kafka to Kuber. That is, let my page with five visitors and three links be automatically scaled in an Amazon cluster, monitored by all possible monitoring tools, and so on. >> For one simple reason. Most likely, you just won't do it. As a result, it will turn out to be too complex, you won't have enough time, and there will be no benefit. >> You don't depend on Kuber, it depends on why you are doing it. Maybe, if you are doing something that you really want, and you want this service to work, and you really want to use it, then yes, it's easier, of course, to do it minimally so that it launches. But if one of your goals is also to practice raising Kubernetes, then, well, it's a good way. That is, you are not raising something abstract in Kubernetes to practice and, I don't know, some to-do list, but you are combining an interesting project and also Kubernetes training. It's either a goal or a process. It's completely unclear. >> Well, somehow it doesn't fit in my head. And why do you need to practice Kubernetes? Do you need it for work? Practice at work. >> Well, and if you don't need it at work, but you want to learn it? Well, I don't know, you'll go for an interview next time, well, and you want to go to a company where it exists, and they will ask you about it. >> So you're going to deceive the company? You'll come and say: "I have experience, I launched a home page on Kuber." >> But >> many haven't done that. Well, you'll get the same amount of knowledge as just by reading about Kuber, I don't know, and taking some free Amazon course, they have all sorts of training courses, practical ones, where you can raise something, touch it, and it will launch, it will be more beneficial, it will be done correctly, it will be done according to standards, and the effect will be greater, it will take less time. Well, I agree, yes, you can, but then you are launching something artificial. Here you are launching a project that you won't need at all, and maybe it won't be so interesting to do. And here you have a project that you will launch with interest, because you want to launch it. Well, the question, again, depends on how much you want. If you are really burning with desire, you want to launch it as quickly as possible, then you can do it that way. But if you just have something that you, well, in principle, are interested in doing, and it will probably be useful to me, or maybe not, then this is a good candidate for launching it in Kuber, because, plus, this thing, unlike the course, you don't just launch and then drop everything, it can continue to work. You might have some real users. You are not just launching Kuber, you are monitoring it, you are looking at how the logs are written, maybe you want to connect Grafana to all this. It will live longer. >> Counter-argument. I want to do that, of course. It's very difficult to argue. It's completely obvious. If you just want to launch Kuber, you should go, as I said, do what you want. You want to launch Kuber, well, launch it. But I'm arguing specifically against the approach. I'm writing a home page, it has no business value, so let's over-engineer it. Let's make 10 pages instead. This is all to what you are saying, that algorithms and so on, it appears at your work. And if it doesn't appear, well, you have come to the understanding that much in algorithms needs to be known, even if you haven't encountered it yet. But how to practice it? And load handling, maybe high load work also needs to be practiced to some extent. >> You can practice. It's always different, unfortunately. That is, the basic methods of reading about high load handling, yes, that might be useful. And just trying to create a high load for yourself, yes, yes, no, of course not. Well, because when a problem arises in high load, when you encounter a bottleneck somewhere, it always arises in different places. If you knew in advance where it would arise, it wouldn't have arisen. And therefore, each new high load problem will be new, because someone somewhere in some place didn't think about something. >> Gleb, how can you learn to find bottlenecks and fix them if you don't do it somewhere before the first real problem in production? This is the first problem. That is, you want to learn everything at once. Well, at work, at work you will. Well, that is, you can create high load for yourself with your own clumsy hands on a task. No, no, I'm saying that, look, in real life, we have all encountered on trivial tasks that a task suddenly turned into a high load. We wrote some quadratic algorithm or exponential, and it worked perfectly on tests and suddenly stopped working under real load, which is ridiculous. And we went to look for it and fix it. That is, we have all made these mistakes. And the problem is of the same order. We also sat down and tried to figure out what exactly was slowing down, why this algorithm suddenly started working so slowly, what are the ways to find the slowing down places. And when we start doing it, >> look, you have a contradiction here, because on the one hand, you say that artificial high load won't fully recreate a real situation, but on the other hand, you say, like, the goal isn't to study all of this. Well, that is, and you say that high load arises where someone didn't account for something, for example. So that's all it is. Even if it's your artificial pet project, for example, you created it and even loaded it stupidly, just without any tricky loads, just sent a stable large RPS to it, and you understand, possibly, if you are a beginner, that you haven't accounted for something, for example, you are going to the database too often, and you crashed your database, and you started to figure it out and realized that, damn, maybe I shouldn't have made this request every time, I'll just make this request less often, or you'll understand that you need to cache something. And of course, you won't cover all the gaps in your understanding with such artificial high load, but you will cover some of the most basic ones and you will understand. And then at work, maybe you'll encounter a situation where your database is slowing down somewhere, you understand that you need to solve it with caching, and how to understand and track it. So, what task do we have in front of us? Who are we talking about? Are we talking about a person who is a programmer and is doing their pet project? Or are we talking about a person who is learning programming, but unfortunately, cannot find a job, and is learning with the help of pet projects? These are different situations. >> Well, it happens that he works for a long time, but he doesn't have high load at work, simply because he has an external project there. >> Well, not loaded. Well, >> well, maybe for that, or >> well, yes, yes, at least just >> counter-argument, just interesting. I already said, yes, if you just want to, go and do it. >> But if we are talking about benefit, well, that is, look, that is, we are talking, that is, let's look again, I want, please, well, I want to, let's not force, go and do it. Or we are telling our viewers: uh, do it this way, because it's useful. I am against doing it this way. If you want to, do it, but specifically, take your pet projects, over-engineer them in the hope of gaining some experience. I wouldn't count on it. >> Well, our opinions diverge here. Well, Lesha, what story did you want to tell from life? And stories about why overcoming problems outside of work is useful? Maybe, and I have enough of such tasks at work, there are different ones, yes, but I always try to go to hackathons, game jams, contests, and so on. I participate in them not only because it's cool, because I want to, yes, but also because tasks arise in them that I haven't encountered in life before, and I don't know how to solve them. But after I participate, I learn something new. It's like reading a book. I read it, I solved it, well done, it stayed in my head that such a task existed. Sometimes in the future I have to solve a similar task, and I already know how to solve it. At least I remember how to solve it. Yes, there are completely strange things that I will probably never use in my life. I'm remembering now there was a contest about, like, you have binary satellite signals at the input, and based on them, you have to triangulate your location. I've never used this in my life before and won't use it in the future, but it was cool. There are more practical tasks there, yes. For optimization, algorithms, loads, there, for some new algorithms. It's useful to know. Plus, after returning to algorithms, and not talking about Kubernetes, yes, I have a question. So I read a book, let's talk. >> Lesha, wait a second. Can, Lesha, can I interrupt you, because you are clearly going further. And I would like to stop at one very important thing. >> You mentioned hackathons. >> That's great. Why? Because at a hackathon, you won't over-engineer. You are given a specific task. >> Your solution will be evaluated. You can compare your solution with others. This is an awesome way to learn something quickly. This is the ability to solve a task quickly and instant feedback is very fast. A hackathon is short, and you quickly get an evaluation of your solution, and you look at other solutions. You gain huge experience. This is completely different from raising a pet project and digging into it, creating artificial obstacles for yourself and jumping over them. These are different things. >> Can I clarify here too? Here I completely agree. It's just that at a hackathon, you have a real need for certain things, and if you don't have a hackathon, then you artificially create this need. That is, maybe at a hackathon you needed some K-value cache, well, in the sense, some Redis, something like that. And you solved the problem with it. And it was even a minimalistic solution. But in real life, you created a need for yourself. Well, not in real, but in an artificial example, you over-engineer in the sense that you might not need a cache here. You don't need Redis, but you've attached it because you want to learn, like, and there's Redis there, but there's a need, and here's like an artificial need. And again, remembering over-engineering, I had only one hackathon that I participated in when I was still working at Fotostrana. And as you said, you won't over-engineer. And one guy, the only front-end developer in our team, decided to over-engineer. Or rather, not quite so, he decided to learn to use one of these frameworks, like not Angular, but what was there, the third one like Angular and the third one on R, probably, something like that from Facebook. M, well, in general, one of these frameworks, yes, React. He decided to use React and learn in it. None of us knew it. And he got stuck. And we had two back-end developers, and we were doing the back-end, and he was doing the front-end, but he was really slowing down in the front-end. As a result, our project didn't take off because nothing worked on the front-end. And we took last place, literally. This is a good example of why over-engineering at a hackathon.

You will not and you should not. That's it, we can move on. >> Sh. Let's move on. Yes, I just remembered something about the Hackathon fundamentally. At the hackathon, we used Go in the frontend. It turned out to be a bad decision in fact, >> because we should have used existing technologies, yes, like JavaScript or something, but not try, without prior experience in Go frontend or in Assembly, yes, to try to get into it in a day or two, not only to create and invent a game, but also to solve problems that you haven't encountered before. It was a useful experience, but a useless bad one. We are doing it at the wrong time, at the wrong time, yes. So. And now, returning to what I was saying, let's say I'm a beginner, I don't know an algorithm, I've read some book, something more human, yes, something like that, well, more like, ah, ah, Dijkstra's, for example, yes, his book is quite understandable, but in my opinion, it's understandable, simple, human. I read it, there are some algorithms, I don't know, like trees, for example, yes. Do I need to try to implement a B-tree myself? any of the variants, some kind of multi-way trees, yes, like wide trees, there are many options, or should I go for iterative algorithms and move on? That's the question. Or, for example, there are such red-black trees, they are also a bunch, well, narrow ones, yes, there are many different variants. Should I implement them or should I just, well, they exist, and if I need them in 17 years at work, I'll remember that there's a book and reread it. Well, just to the point, is it worth doing what has already been implemented a million times to understand it better, or to move on? I don't see much point in it. Well, you've already read the algorithm. By rewriting it in another language, you will remember the algorithm itself better. That's a fact. Ah, but will you forget the concept of the algorithm if you understood it? Doubtful, because you'll likely remember the basic idea. I still think you'll forget. >> Let's say you have Go, I even have an example, yes, how I forgot an algorithm. So. Or, well, I'll show you quickly. I interviewed at Yandex twice, passed the interviews, but that's not important. So, I had a case where I was asked to implement some algorithm, a task, yes, and I reduced it to a heap. Well, that's a heap, a min-heap or a max-heap, I don't remember exactly. So, I say: "Well, I have a general idea of how we add an element here, then raise it, then lower it." But I don't remember the details, I've never used it in my life, yes, I know it exists, but I've never had to. And so, yes, in real life, I would open the documentation, I would read it, yes, I would remember how these elements move there, yes, new ones, deleted ones, I would remember, but within, say, 20 minutes, I didn't remember then. Well, I explained it in words, and it was okay, as if, yes, they accepted it, as if plus other algorithms were successfully solved. Well, although a heap is just an algorithm. It's very simple, well, it's not trees, actually, you just need to understand. If you, like Gleb, don't reread sections of a book for several years, yes, it's forgotten. Because the brain forgets unnecessary information. I remember that a heap exists. So. But it's not there. That's the thing. >> Well, if it's not used at work, then yes, then >> just doing it for the sake of doing it is unclear. Okay, that's all. >> Well, here, in general, we don't necessarily all have to reach a common opinion. Our opinions diverge in places. And probably, if we sit for a couple more hours and dig deeper, we'll eventually realize that we were talking about the same thing, just understanding it differently. But here, it's more for the viewer, who will listen to us, someone will find something closer, will gain some new ideas. In these cases, I recommend, even if, for example, someone is on Gleb's side and listens to us, or vice versa, leans more towards my opinion, but Gleb's ideas are alien to him, still listen to them, even to these alien ideas, and try to understand why the person is saying it that way. Maybe he's right, maybe I don't understand something, or he didn't understand me correctly, or I didn't understand him correctly. So in such discussions, well, as they say, truth is born. It's useful to listen to all sides, but it's not necessary to ultimately agree, because it will take us about 9 hours, probably, in the end. So. But in any case, it's interesting. I still adhere to the idea that, yes, probably, you need to try to implement it in practice, that it will solidify it better in your head and you will understand it better. Again, remembering Zorich, I read these concepts and then when I tried to prove them in an exercise or use them somehow, I didn't so much remember them better, although that also happened, but rather I understood them better. That is, it seemed to me that I understood them, but in reality, I realized that I didn't understand them. And when you implement an algorithm, you will probably also realize in the process that you are completely overlooking some nuances, and you will only notice them when you use it. Either you use the algorithm to solve something, or you implement it yourself on some simple example. >> I have a small remark on this topic. The question is, what do you want to achieve? If you want to achieve a state where you can implement this algorithm later, then of course, you need to implement it yourself. Preferably not immediately after reading the book. That is, you need to read the book, close it, get up tomorrow, and try to implement it. If it works, great, if not, you need to read it again, close the book, and try the day after tomorrow. Because if you try to implement it right after reading the book, there's a chance you'll just repeat it from memory. Not because you understood the algorithm, but because you memorized the sequence of operators, so to speak, by seeing the pseudocode in the book or the code, if it's written in some real language. Pseudocode is better, by the way. So. And if the task is to get acquainted, then there's no need. Therefore, both answers are correct here. The question is, what task are you setting for yourself? >> Well, yes, and here again, it's important to understand how to set these goals correctly for yourself and not confuse what you need with what you want. So. Well, Lesha, what else can I add here? >> We can talk a little about understanding the area of applicability of some solutions you've learned about, i.e., algorithms or technologies. Can you, after reading, I don't know, about Kafka or red-black trees, understand where they can be applied or not? >> Well, and I would return to the enumeration for now. We've slightly deviated from the topic of enumeration. Well, meaning, if you want to add something briefly, then okay. But if you're starting a new large block, then we started discussing these >> your favorite resources and why they are cool. Can I, after all, Alexei made a very good point, I would highlight it separately somewhere, maybe write it down in the margins, because it's an extremely important and correct observation, and it completely resonates with my concept. Try everything, so to speak, on real tasks. Read something? Think about where you can apply it in your current work? Write it down on paper. Maybe, as it were, an opportunity will arise and you can insert it there and try it. This happens quite often. And this is precisely the ideal way to practically learn what you've just read. That's all. Thank you very much. >> Well, you also wanted to add something, Lesha? >> Mmm, no, no. Well, I mean, yes, just reading, studying without application, without even thinking about where it can be used or where it could have been applied earlier. It's, in my opinion, useless. But it strengthens some connection in the brain, you connect something learned with something from your personal experience, and in the future, this connection, well, the brain, it can work again, and you will reach the correct solution faster. >> Well, yes. And again, returning to what I said about information transformation and so on, there are probably many ways to solidify it. This is both implementing it and teaching someone about it. I don't know, you learned a new algorithm, you told a colleague how it works in your own words. That's also a kind of practice. And so, >> well, the question is about investing your time and effort. You can't tell everyone absolutely everything, you won't have time. >> Yes. >> Well, okay, let's continue now about resources. Gleb, do you have anything else to say here? We started talking about algorithms. Well, by the way, it's interesting what you'll say about different books. Well, we, with Kien, for example, about Knuth. Everyone has heard of Knuth, but no one has read him, except maybe you. What can you say about him? Is it worth reading and for whom and how? Well, it's a textbook. It should be treated as a textbook. If you want to delve into the theory of programming, algorithms, and so on, well, you need to take Knuth and read it sequentially like a textbook. If you treat it as entertainment literature, well, I don't know, now it's published in five volumes or four, so it used to be simple, I had a Soviet three-volume edition, and the third volume was about sorting. Everyone skipped the first two volumes and read the third one because it was practical, interesting, and well-written. But the first two are absolute boredom. Therefore, Knuth is twofold. If you just want to be entertained, well, take the last third and read about interesting things. If you treat it as a textbook, it's a good textbook. You need to take it and read it sequentially. But it's work, hard, heavy work, for half a year, a year. >> For those who don't know what we're talking about, it's not about Knuth and the gingerbread man, it's about Donald Donald Knuth, who wrote, what is it called, the art of programming, yes, >> the art of programming, the art of programming. Yes, >> it's a three-volume set and I heard something, maybe there's a fourth one. >> It's four or five volumes now. >> At least, I suspect that maybe the publishers cut it up so that there are more volumes and more money. So before >> I'll explain why it scares many people and many shy away, it seems like, well, you're learning, you want to, well, you think that to become a cool programmer, you need to know all the basics of algorithms. Especially since there's a simple way. So, here's Knuth. You'll read everything and probably there will be nothing left that you don't know about algorithms. But this will result in you, first of all, spending a ton of time, and if you're also a beginner, you won't understand anything about it. Well, I'm just explaining why there's such reverence around Knuth and why he's talked about so often, but no one reads him or finishes him. >> The Art of Programming, it's still not the theory of programming, it's the art of programming. If we talk about talmuds on algorithms, I liked Cormen more. It's also a thick book, but it's one. And although it's thick, and at first it seems like it will be something very complex, it's surprisingly well-written, meaning it reads like fiction in places. So he explains well why an algorithm is needed, how to apply it. And in general, if someone wants to delve deeply, then maybe, but at the same time, they've read Grokking Algorithms, because Grokking Algorithms is like a top-one start for beginners. It's very simple, it reads, well, literally in 1-2 evenings, like the Go tour, and it's explained very simply. There are even funny pictures drawn. I even remember the author, Aditya Bhargava, if that's an unusual name for us, but it still stuck in my head very well. So. But then you can read Cormen, if you really have the desire and time to do it. He also has some good exercises, I think. So. Okay. Do you have anything else to tell us about this, Gleb? About resources to list? >> No, because, as I said, learning programming is not so important what you take as a basis and what language. It's work. And what's more important is this. In learning and programming, the book you read is not important, the work you do is important. Is there a teacher, is there code review, is there real verification of the effectiveness of your work? If there is, then learning will be effective. If not, then, well, well, it's probably possible, but it will be much less, much less effective. And everything else is applied books that you can read because you like them, because they relate to the topic, because they simply bring pleasure, because they broaden your horizons. And there are tons of these books, and I'm not ready to recommend any specific one. Read this one. Don't touch that one, it's so-so. Even in a book that's so-so, >> so-so. If you've reached a level where you've grown to the book and can read it diagonally, even in a so-so book, you'll find something useful for yourself. You'll just more often say: "No, the author is writing nonsense here." But still, something will be found. Oh, and this is interesting. I've never encountered a book that was completely nonsense. >> Well, let's move on to Lesha. Now you can tell us your list of resources, the golden fund. I'll go do something very important for a couple of minutes. I'll hear everything you say. So >> Yes, I'll be done in less than 2 minutes. >> Well, I think you can keep the conversation going for a couple of minutes without me. >> Yes, yes, while you were gone. I don't know, Gleb, how about you. Just because you started programming earlier, you probably had even less information and sources than I did for studying, but I didn't have any specific textbooks, books, or materials when I was learning myself. Usually, it was about encountering a problem and trying to solve it. And usually, it was some documentation, some scattered fragments, some things like Pythagorean started appearing over time, then later, in our time. So. >> Wait, but you did read some books. with the basics of programming, algorithms of some kind. Well, the same banal one I mentioned, like, Virta's algorithms and structures. >> No, I read Wirth, yes, but I've mentioned Wirth several times, because I even had a paper copy of that book in my time. So. And things about some algorithms like Wirth, you know, then you can talk about specific areas, like compilers, computer graphics, cryptography, compression, and so on. That's a separate thing, not a book about everything. These are specific things, for example, I have a huge number of books on graphics, and so on, yes, just handmade graphics, if we do it manually, yes, bypassing these APIs, if we're talking about cryptography, there was a website a-a compression.ru, I think it still exists. They had their own book at the time, you can still download it. It's also about compressing files, graphics, video, sound, and so on. For compilers, I also mentioned Kranshaw, ah, Wirth, the dragon. Well, these are specific areas, yes? I didn't have a comprehensive book on algorithms. I studied how computers work using disassemblers. First, I had Turbo Assembler, and it had a debugger. So. Then at university, we had this Electronic Workbench. I don't know if you've encountered it. It's an environment for developing electronic circuits. And there, I think, over a year or a year and a half, like three semesters, we went from implementing some half-adders, yes, to algorithms at the level of dividing two floats. So you implement it on an electronic circuit, with a clock generator, and then it goes. That's how it works with registers. All sorts of debuggers and debugging tools and other things like cheat manuals, you understand, right? You don't use them. So, it was a spontaneous study of all the problems I encountered. I read everything I found, everything I understood. Well, and it was mainly websites, forums, some first paper editions. But from modern things that I can recommend, maybe it's the Lipes blog. Well, Go in general, I like it. They have quite a lot of interesting things. And recently, the Victoria MatriX blog, they've really started investing, apparently, in their own brand as a Go blog. They also have cool materials. And for general high-load stuff. So, highload has, in fact, a junior section at their conferences, they post a huge amount of learning materials on YouTube, but these are mainly videos, which I don't really like, as I said. That is, I'm more for those who like videos, it's a pleasure to listen or watch on the go. I don't like that kind of presentation. I prefer to look at texts. Therefore, for me, the most convenient are texts, websites, like compression, Alcalists, Ardon Laps, and so on. So. >> Good, yes. >> For studying, >> yes, for studying algorithms. You've talked about Codewars many times. I didn't like it. I liked HackerRank more, but it's six of one, half a dozen of the other, I think, it's just that HackerRank appealed to me more. >> Codewars has tasks that are more interesting. There's also a website, Codewars, where tasks are formulated more interestingly. >> Yes, there are. Well, yes, there were some fun ones. Yes, yes. I tried it for years, I didn't like it, I like Codewars more. I don't remember why. Different tasks, different interface, something. So I participated. But not to pass it myself, or something else. I was interested in solving tasks. There were really cool ones. That is, you solve a task, you understand how it's solved, you take another one, and it's the same, I won't even do it. That is, I didn't have the goal of getting some rank or some points, yes, it was just interesting. Plus, I think it's cool that in VK, back in the old days, there was a whole team of C programmers, who were olympiad participants, we had guys there, world champions, all of them, yes, and you're in the same environment, you communicate with them, you look at their code. Plus, I introduced Go into the company, VK, which was C and PHP, yes, and I had to implement all these protocols in Go, all the interactions of Go with the outside world, as if it were written in C. And therefore, I had to communicate a lot with our olympiad guys and understand what they were doing, why it worked that way, why. That was also real practical experience of learning. So. But it was, as I said, spontaneous problem-solving. I didn't sit there reading a book, then maybe about something on a pillow. No, very rarely did I get some basis in university, I learned about trees, red-black trees, yes, I think we didn't even have B-trees, we didn't even have wide trees at university, I don't know why. I found out about this later when we were understanding why we need B-trees, why page sizes, why we allocate a bunch of these. Well, only because, why don't they use, for example, a database, they use B-trees, they store them on disk as red-black trees, why? That's a practical task, but you just encounter a problem, you solve it. That is, I have more of that approach, so I can recommend, I say, I can send you the website. They have a cool book. You missed it, right? Kols >> I've heard of it. Yes. >> Ah, you've heard of it. Yes, yes. Yes. So these things. >> Yes. >> Yes. And now the current source for me is not books, but a bunch of various Telegram chats with blogs, posts, links, some research from friends, acquaintances in chats. Now, this is enough for me to develop further. Or some problems I encounter at work, some contests and so on. I just tinker with this task outside of work and learn something new. Well, how here, >> for example, Docker. I remembered trying Kubernetes. Now, after Docker, I started studying it not because I needed it, but because I was interested, and it wasn't used anywhere I worked. I just started tinkering because I found it cool, what it is. So I learned about cgroups, I learned about Docker Swarm, all these things, because it was cool. It came in handy in the future, yes. >> Well, you also mentioned Victoria MatriX, that their blog is good. >> Well, they've started recently, yes, as if they hadn't before. Maybe a few months ago they started posting really cool materials that were really interesting to read. Some of which I would have liked to write myself, but they've already posted them. Okay. >> I don't often see companies writing about their product, do you mean they write about their product or something related? >> No, no, they generally have several cool articles about Go, yes. >> Not about >> I would just recommend, if we're talking about more modern things like LLMs, then Anthropic, who make Claude and Claude, they surprisingly have a cool corporate blog too. They often post guides on how to use Claude, how they use it. In general, it's very pleasant to read their documentation and blogs. And especially since many people need Claude and LLMs now. They're doing well with this. Well, okay. Regarding resources, there are still some things we've passed by but haven't discussed. For example, Effective Go. Go. And Gleb often recommended reading it in some cases, in some contexts. What can you say about it? Is it necessary to read it? And why? >> From my point of view, Effective Go, I'll explain it too. Now I'll explain what it is. It's just a long article, you can just Google "Effective Go", and the language authors, well, how to put it better, write about how to use the language correctly and how to use it effectively. So, from my point of view, it's just, well, you should treat it like the Bible. That is, everything that is written there should be used. Why? Because one of Go's strengths is that there are few ways to solve the same problem. The language is standard, with a standard formatter, and so on. And if people who write code also use the same approaches when solving problems, when naming objects, when choosing solutions, then the code becomes much simpler and clearer for everyone. That is, you should read Go, especially if you are not working alone, but in a team. Well, usually you write the homepage. So, actually, there is >> just for fun, I want to recommend reading this specification, Effective Go, to all developers of popular Go projects, like 500 projects, so Java developers, near-Java developers, many others come. That is, people write in Go but apparently haven't read it, maybe I don't know, like >> No, that's a given. That is, if a person comes to write in Go in a company, you must start by giving them the standards to read. We don't write our own standards, we use Effective Go. And we also use Google's standards. Google has a beautifully written document, which consists of several parts, which describes, I forgot what it's called, it's also easy to find. Either it's Go Google Code Standards, or something like that. I can find it later and, I don't know, Kolya can put a link under the video if you want it ready. >> Yes, I'll write a separate post with all the links we talked about. A wonderful separate document that analyzes a lot of important and serious problems. Moreover, it analyzes them correctly, it states the problem, describes the solution, says: "Do this, don't do this." This document is also mandatory for us. That is, most of the rules we use. >> Uber's codestyle, how do you like it? >> Uber's codestyle, how do you like it? >> Ah. >> Uber also has a similar document. >> Well.

It is not allowed to use two at once, so we use Google's. >> Well, yes, >> well, I don't think they differ much, to be honest. >> Well, most likely, yes. Well, it's not a fact that Uber also explains in detail, as you say, why and how to do it, how not to do it. And this is important precisely, yes, this is important precisely from the point of view, that is, it is important for two reasons, because, firstly, it allows you to bypass many bottlenecks in Go simply and to step where you shouldn't, because it might not be implemented very well in the language. If you do as the documentation says, you will never get there. And secondly, you will be made to do the same thing, which greatly simplifies life, because the most important part of writing code is code review. And, by the way, this is also the most important part of learning a language. And if everyone writes more or less the same, code review is easy, fast, and pleasant, because everyone speaks the same language, everyone reads the same way, there are no disagreements. Uh, and again, in this case, disputes also decrease. This "I see it this way" decreases. We have it written down, we use this document. You give a direct link, it says so here. Everything, the question is settled. This also saves a lot of time. Again, the army approach, let it be ugly, but uniform, is also extremely important in corporate programming. It's better for everyone to do it wrong, but uniformly wrong, than for everyone to do it their own way. The result will be worse. >> In the case of Go, these code styles and others are good because they are minimalist, because Go itself removes a significant part from you. That is, these disputes about tabs or spaces, Go removes them from you, because the formats, yes, I think, always convert them to tabs themselves. And some simply won't compile. This is like an eternal dispute, like curly braces, whether they should be placed on the same line or the next line. In some languages, you can do both, but in Go, well, only on the same line. And in the end, only a small part remains, like how to name a variable and things like that. whether you put spaces or not, there >> cool lines. There's actually a lot of different stuff. >> Yes. But this is always solved, by the way, it's funny. I just remembered now that when I was retrained a long time ago, they told me that when writing, for example, x = 1, you need to put spaces to the left and right of the equals sign, and then it will be more beautiful. I thought, what's the difference, it seems more compact this way, but even this Go solves for you with auto-formatting. >> I, by the way, wanted to say something, you know? maybe not related to resources. That is, if we are talking about learning a language, then I thought about it and realized that it's not about the language itself, but about programming. That is, if we are talking about learning, how to grow into a good programmer, I suddenly realized that I learned to program in a ridiculously short time, right? So, how much? In 90 minutes. Uh, we had a programming course in our first year, a full semester. Around the middle, I stopped going because I, well, it was pointless. It's better to sleep in the corridor than in the auditorium. I fell asleep after about 20 minutes. I didn't understand anything. I perceived the approach of the exam session with horror, because all my other subjects were normal, but here I understood that I wouldn't be able to answer anything, absolutely nothing. And this is completely uncharacteristic for me. That is, there will be an exam, and I just don't know what to say. I don't understand a word of what this woman is saying in the auditorium. She says words, but they just slide off me like water. I just don't understand anything. And then we had a colloquium for 2 hours and they explained, the associate professor of the department came out, I don't remember his name, I think it was Andrey, I forgot his last name. That was enough. By the end, I understood everything. I understood completely, I was ready to take a piece of paper and write a program of any complexity. It would be clumsy, but it would be a program. That is, if we are talking about programming, to learn to program, to understand what programming is and how to do it at all, 90 minutes of clear explanation is enough, and not endless and long lectures, but to become a programmer, this is a craft. It's like an artist. You come to the Mukhina School, and no one gives you long lectures on how to paint a picture. They give you a brush, paper, draw. All this is interspersed with practice, showing the works of other artists, evaluation, tips, trials, stories about technique. But all this is given on top. Here's a pencil, here's a drawing board. Go ahead. Programming is the same. How to program can be understood in an hour, >> learn to program. >> Well, so you're leaning towards the fact that it also depends on the quality of teaching. That is, someone won't teach you in 20 lectures, but someone will teach you in one, because it also depends on the person as a teacher. No, no, teachers can be good or bad, but I mean that you can't learn to draw, no matter how good the teacher is, if you don't pick up paints, brushes, pencils and start drawing. No good. >> You gave an example that one teacher taught you, another didn't. What was the difference? >> The difference is very simple. They taught me programming in the courses, I didn't understand what it was and why. They taught it to me as a series of lectures, which hung in the air, they were not accompanied by practice or anything. And if, perhaps, I still understood something in the first lecture, well, I could remember some words, like, well, this is a variable, here, like, some theses, we put something into it, but yes, until you start doing something, it remains words. These lectures were held two to four times a week. I don't remember how often we had programming lectures. And from the second or third lecture, it turns into torture, because it's some kind of meaningless, some kind of meaningless words. They were probably correct. Well, that's when lectures on OOP, I know, when, for example, they tell you about some kind of polymorphism, and for you it's just a new word, and you don't even understand the problem, why polymorphism is needed, what inheritance, encapsulation are, you still don't know how to write if else and x = 2, you still don't know how to do it and haven't tried, but they are already telling you about polymorphism and encapsulation. Of course, the chances of understanding are approximately zero. This is a completely degenerate case, yes. Unfortunately, I can't remember what they told me for obvious reasons, because it all went past me. It all flowed away. These academic hours, they all flowed into the great nothing. From the middle of the semester, as I said, I honestly just stopped going, because I saw no point in it. It was better to walk in the Polytechnic courtyard. Uh, practice, this is the most important part of learning - practice. And in this sense, uh, if you have someone to work with, and preferably a more experienced person who will immediately provide code review, this is simply the best thing you can come up with, because the code you will write will be terrible. Uh, and how to understand if a programmer is good or bad? You should really like what you are writing. You should write and think: "How good I am, what an excellent code I am getting, how awesome this is." Well, and the code you read, which you wrote six months ago, you should read: "My God, who wrote this? I would tear off their hands. Who does this?" And it should be like this throughout your life. >> Well, that's in the ideal case, if you've learned a lot in these six months. >> It always turns out that way. I just don't remember it being otherwise. Well, okay, maybe not six months, but a year for sure. That is, code written a year ago should not be liked. Okay. Well, about lectures and so on, it's also funny to remember. I didn't study to be a programmer, well, I studied programming in college, but it's even better not to remember. Uh, I studied physics, then in a normal university. And programming, if they taught it to us, then you can also not talk about it. It went as a side thing. But it's funny that the same can be said about mathematics, that sometimes, well, just for understanding physics, mathematics is not an end in itself, it's a tool that is needed for implementation. That is, if you were studying, I don't know, programming something specific, then programming is theory for you, but this specific thing is practice. And here too, you need mathematics to solve physics problems. And what was interesting is that some mathematical aspects were explained much better by the seminar leaders in physics than by the mathematicians themselves. We just had mathematicians teaching mathematics, and physicists teaching physics. And there was always this dispute, that physicists came to the mathematicians and said that, damn it, students need this right now, and you're going a little off track, not doing it right, because our main program is physics, and we need to keep up, and everything is very compressed there, you need to keep up with the tools so that you absorb them much faster. And they didn't always cope with this. And therefore, some gaps had to be filled by the seminar leaders, and they did it better, because they have a compressed seminar, their goal is to teach you to solve a specific physics problem, not a math problem. But you don't know, uh, I don't know, some thing related to an integral of some kind. Well, of course, they won't explain all the theory of integrals in one session, but something specific, how to take a specific integral or something else, they can explain. And it often happened that it was better, because practice followed immediately. You apply it right away. We had something similar in school. Our physics was taught by a university lecturer. Well, it happened that way in school. And he helped us with explanations and got ahead of the math program, because he needed it to explain the topics he was covering. He could also introduce new topics that we hadn't covered yet, but were important for his lectures, well, classes, lessons back then, yes, it wasn't called a lecture. And topics that we didn't understand, but they were already explained to us. He wrote them in his own words, and we understood because he had rich experience teaching at the university and explaining. So he explained better than the school teacher. I think it doesn't even just depend on the teacher himself, but on his goals and the situation, because the mathematician understands that he has a lot of time, he needs to tell you something until the end of the semester, and he can go into some very detailed specifics and philosophy. But here, if this guy doesn't explain a concept in the first third of the session, then, well, he simply won't be able to conduct the remaining two-thirds of the session. He'll just be teaching you math instead of physics. And whether you like it or not, he'll have to explain well, otherwise why is he needed at all. That's how it is. Okay. Well, regarding the remaining resources, I think we need to wrap up gradually. We've been sitting for 3 hours already. Have you heard of Go Proverbs, such a site? It's like a >> it's excerpts of phrases from videos. >> You remember that? Yes. >> And there, each phrase is a link to its part of the video. >> Yes, it's all, I think, from Rob Pike. That is, well, roughly speaking, it's a collection of concepts, principles related to Go, for understanding the philosophy of the language. Something, well, yes, and there, as it were, proverbs, it looks like a set of such phrases. Each phrase is clickable, leads to his lecture with a specific timing, well, a conference. >> And can any of you tell us something about it? How useful do you consider it? And, well, if you don't know, then how important is it to understand the philosophy of the language to write something well in it? >> I haven't watched that. >> I haven't watched that. I don't know. To understand the philosophy of the language, yes, why not, I would start with that. Yes, I've already said that it's best to experience it than to learn a language. Uh, if you already know other languages, get acquainted with why this language was created and what the authors were thinking. >> Because it imposes >> click on the link now. Uh, I think you'll click, look, and immediately understand quickly what it is and why. >> I'll take a look now. There's also, by the way, a site that we haven't mentioned. It's 100 Go Mistakes, quite useful if we're talking about Go, >> yes, >> command go mistakes, it's called. 100 Go Mistakes How to Avoid. >> Well, I think, >> it's called 100 stories. >> Ah, I see what you mean. Listen, well, yes, essentially all of this was in their blogs. Well, why not? Like, in general, yes, like, I haven't clicked on the links, but - >> well, how is it again, not a bad criterion to understand how well you know the language and the philosophy of this language, as the authors understand it. Just open this goverbs, read it in order, and without clicking, can you say what it will be about or not? If you can, then >> how important do you think it is, how important is it to know these concepts at all? I've also posted a link to this site in the description of the post, so whoever is listening can take a look. But >> it's at least useful. It's at least useful, yes? >> So, for each line here, you can have a whole blog post. Yes, you can talk about this for 3 hours. >> channels orchestrate mute serializ. Generically, you can talk about this all day. >> Do you think you can conduct interviews based on this list? >> Selectively. >> You can. Absolutely no problem. You can. I'm telling you, it's a great way to conduct an interview. You give a person this list, and say: "Take any item you like here, and tell us about it, >> like exam tickets." >> Yes. >> No, like, whatever you like. The person might not know something. Well, the person hasn't used Cgo. They can't say anything about Cgo from Go. It's okay, let them tell us. >> But if they can't explain a single item, then probably >> yes. Here, here's why a person can talk about why the more interfaces, the weaker the abstraction. There's something to talk about, both about how to use interfaces and decomposition, and where to declare interfaces and what to pass, and the general concept of duck typing. You can talk and talk. Error values, yes, there's also something to talk about. And about the fact that you can pass data in errors, like, about the fact that it's not just a fact of an error occurring, but information about it, that we can supplement errors, like, there's something to talk about too, well, and so on. >> So, Lesha, do you have anything to say about this? I regularly use this site when communicating and reviewing. I directly send, look, here, this line, directly, take a look. >> That was also the case. Yes. >> Regarding general sources in principle, I don't know, intentionally or not, besides the tour and effective, there's also at least the language specification. It's also useful to read. Specification, a large document similar to Effective Go, where the peculiarities of syntax are explained. And the Memory Model, but that's more of a next step. That's for those who are already, uh, making mistakes in large projects and encountering problems. >> Well, that's if you mean specifications, if you want to look into the internals of the language, then >> yes, for me, learning Go is like this: Go, then Effective Go, then, well, or the language specification. You can, you can do it in parallel, you can do it in any order. And the fourth is the Memory Model. And then you can go further, look into the sources. >> Well, you've certainly dug deep into the Memory Model, >> because mo >> Well, that's the last point, yes, to understand, yes. >> I mean, >> I send it right away, it's important, I think. >> So, in general, about the concept of memory models, 90% of ordinary programmers are simply not ready for it, so you're taking it so seriously. Are you talking about the article about N? No. They have a large material similar to the specification, to Effective. Well, now they, they start with the physical memory model, then with the representation of the physical model, the logical model, and then the implementation in the language. There are three parts, like, a good material, quite deep, >> with the concept of not before, which for many is just a revelation. I had an idea, by the way, that a book that could be called, the one I'm thinking of writing, which could be called Go Under the Hood, conditionally, there's an idea to start it precisely with the Memory Model. Well, maybe not as detailed, not in the same language as it's written there, but simpler. And, well, I think it's a good way to start a conversation about the language under the hood, so that then you can layer variables, structures, alignments, and so on, because otherwise it's hard to talk about it. I'm still thinking about it. >> The first introductory chapter of the Memory Model is exactly what I would read, what will happen next. >> I also think so, because, well, let's start. It can be strange. >> We laughed. >> It can start, of course. Well >> it's already a good hook, yes. >> Well, that's the approach, like, >> it's important to figure out how, how to do it. Yes, yes. >> Just start >> exactly like that. >> With supports. >> Another processor mode. Yes, and let's go. >> Okay, let's smoothly transition to the next topic. You mentioned that all of this is from the developers' blogs. Well, not necessarily all of it, because the links are not all to blogs, I think everything is linked to presentations. But since we're talking about it, what about the blog? Well, it's the blog of the language authors. In general, what do you think about it? Do you need to read it? From beginning to end? Just take it and read it. There's nothing to think about. You just need to take it and read it. It's not large, about a dozen articles. Well, how, why? Because it explains all the basic concepts of the language. Well, I might explain here. Gleb explained very briefly. That is, when they introduce some new concept, change the garbage collector type, maps, that these Swedish maps were recently brought to Go, they, well, not always on time, often with a delay. Well, in the sense that after it's released, they explain how they did it, what the problem was, why they decided to switch to some new type of map, and so on. >> You mean from this perspective, to understand what and why was done, or something else there? >> I mean, it's a great addition to the language specification, and you should read them in chronological order. Read them as they were written, because, again, the first articles are dedicated to how to handle errors, what an interface is, and so on. That is, the authors' view of the problem. Contexts appeared there, as the language developed and became more complex, it became more complex, new descriptions appeared there. Well, some can probably be skipped, yes, if you are not interested in how the system works internally. >> They moved on, they moved on. Okay, you can skip it in general, but the things that describe language approaches, this is actually from there too, this is from goblogs, that don't communicate by sharing memory, share memory by communication. This is from there. All of this is quite useful to read, because it's concisely stated, there's no rambling, there are no long articles, it's literally a 5-10 minute read at most. And at the same time, it's valuable because it's written by the language authors who, in general, solved a specific problem when creating the language. Therefore, the problem, the approach to its solution, and the features of the resulting solution will be described there. >> Lesha, do you have anything to add here about goblog? >> I was just trying to recall in the background. I think lately not all articles are as good as they used to be, but it's still a must-have, yes. I just can't remember, there was an article that just got me, like, why was this here, but I won't remember it now. But in general, yes. Everything else is from the very first issues. I also forgot, unfortunately. >> Well, there are some articles like, we're celebrating some anniversary of Go or some results, questions. >> Still about it, >> well, yes, >> you should treat it as a blog. A blog is like a kind of excerpt of sources. That is, if you don't have a lot of time to sit on GitHub and read what issues, discussions are there, the blog is a good excerpt. See what the authors have finally formulated their thoughts compactly. >> And also about the specification, you were in a hurry to turn off the microphone. Can you tell us about the specification in general, well, why look into it, why is it needed for an ordinary mortal, how to read it correctly, about such things. Because I don't think many of our viewers have even looked into it or understand why they should. Listen, I think I don't know what other sources you can use to learn all the corner cases of the language syntax. That is, some obvious examples are explained, and you will reach others yourself, possibly without falling into production. It happened before, like, using append incorrectly, yes, adding to the end. Can you give some examples, well, besides slices, they've already been discussed to death, what corner cases can be found there and which might be useful. Well, I understand that it's not always possible to recall quickly, >> but there's an open one, yes, with at least a section. Oh, >> well, okay, if something comes to mind, about problems, yes, it turns out. >> Well, yes, from what might be useful from there. While you're looking, I'll just, okay, yes, I'll take a look. Yes, >> while Lesha is looking, I can also say, but it's for a short while, that I find reading the specification very boring, I can't force myself, but I'm interested in reading the source code. And this is, of course, less optimal, it's not quite the same, but when I work with GO, well, at least the STD source code, it's convenient that in the IDE you can always click on go to definition and see how the function is structured. And in the case of GO, you can, well, it's not always possible with all languages. You can dive in, like, I'm looking at my functions in the project, dive into how the function is implemented, and then dive into the STD level, and sometimes I look at how something is structured there. If I'm not sure that the function works as I need it to, I look and understand, yes, this argument is for this, this is for that. And sometimes it's even faster than looking at the documentation. I mean God, when you can see God directly in the IDE and there's a description of the function, sometimes it's faster for me to look at its source code. So, so, >> where is the language specification needed, obviously, because the language specification is needed when you start doubting the behavior of a particular construct. Where will you look for something? In a book, perhaps? That is, to look for which book it is described in. Books are a huge amount of water and little information. The specification is 100% information. If you start to doubt what will happen if I read from an uninitialized map. Well, I don't know, can I read from a nil map or not? Well, open the specification, it's written there. I remembered a couple of examples, by the way. Yes, well, the map is also an example, yes, other examples from life. For example,iota, it can work quite non-obviously if you haven't figured out the examples. If you haven't specified it at this point, you called it twice in this loop, yes, what it leads to, it's hard to understand from the specification, I think. Another example was recently. This is why when we iterate over a string with Unicode characters, we read bytes, right? And when we slice, we get a character, I think, because the string is an alias for a byte slice. This is written in the specification, probably nowhere else. >> So, the younger brother is just like that, >> yes. If you don't know the specification, you can step on another set of pitfalls in the form of iterating over a string incorrectly. Something there, well, what Lesha says, that we don't extract characters from there, but bytes, and they are not always the same. That is, in the case of English letters.

This, probably, this, this will work, but in the case of kilitsa, it won't. You'll get half of the letters from some iteration. Slicing works differently. That's why, that's why it's written that they processed slices and arrays for strings differently, it turned out that way. >> In short, there were some, I just don't remember. I'll remember append and then I'll remember falsification. Where else can I learn this compactly? I don't know. >> Well, I generally tried not to delve into the topic of whether it's needed and why it's needed, but rather to talk about how to study, not why to study. But here, nevertheless, there is no. Yes, I just wanted to, right here, yes, an important point, that >> I will still say about why some things are important to understand. Again, like the famous "do you need a database" and all that. If you don't know the specification or some low-level things, like how a computer works, then there's this smart thought. I'm reading Kirill Makevnin from Hexy. I think I picked up an important thought from his blog, that it often happens that when we study applied things without delving into the specifics of the operating system, for example, devices, then a lot of problems arise, which we fight with them as if they were tentacles, and you might have a thousand problems, and you'll learn to solve each one and simply know that you can't open too many connections, or something else. Or what you're saying, you can't iterate over characters in a string. And sometimes you can, and sometimes you can't, but these problems don't arise for you when you know this very foundation. That is, if you know the specification, you won't have the thought, can I iterate over a string, or if you know how an operating system is structured, you won't think about how many connections you can open or why you can't open too many or how to do it correctly. And here's an example I came up with the other day. I don't know how good it is. Why, for example, imagine a situation where there is, yes, some trash can built into the floor, and you just don't know what it looks like inside, and you just throw something into it. Well, why do you need to know how it's arranged if you can just throw trash in it and that's it? But at some point you try to throw, I don't know, a long pipe into it, and it doesn't fit. You think: "Aha, so you can't shove a long pipe into this bin." Remember that? Then you try to pour a thousand golf balls into it, and they don't fit. You think: "Aha, only 10 fit, and let's move on." And so on, a million things, like you pour water, and it disappears somewhere. You think: "Aha, you can't pour water because it disappears, but sugar disappears slower." Then at some point you take it out, >> as is, right? At some point you take out this bin, you realize that it's of this shape and that it's also mesh, so water spills out of it, and sugar spills out of it slower, it also spills out, and the pipe won't fit in there at all. And only 10 golf balls will fit in there, not 100, for example, not 1000. That is, knowing what this bin looks like, you automatically won't even think if you can shove a pipe into it. You already understand that you can't shove a pipe in there and it's better not to pour water into it. And if you don't know the internal structure, you'll spend longer studying a list of problems that you can't, as it were, reproduce. And where is the list of pitfalls? It's kind of like that. And this applies to IT, when you have a basic understanding of how an operating system is structured. This is the understanding of that very bin, and you simply understand what you can shove into it and what you can't, and how to shove it correctly. >> Well, Gleb said, you can rephrase it, that you can understand something better if you understand the level below, what it is based on. That level, and then another level below. Yes. >> Yes. >> Starting from NDA, how it works, to microservices. >> Here, yes, you can give many examples. Also, the structure of the stack and heap, for example, in memory. you won't understand why it's convenient for you to declare a local variable there, and again about escape analysis, well, it's too long, it can drag on. Simply when you are on Antretris, you also build the stack and heap yourself, as far as I remember. I haven't finished it myself yet, but I think there's something like that. Okay, we need to wrap up slowly. We haven't covered everything on my list that I wanted, but it still turned out very interesting. Well, most of it, I think, we've covered. Some very unpopular, little-popular things came up. Ah, well, okay. Ah, well, this is how we can finish. So, how do I, I thought about this plan with Gemini, and he advised asking a good question. Yes, yes. >> You weren't heard just now? >> I have to leave anyway, because we're already 40 minutes over our planned time, and I have guests, a bathhouse, and so on. >> I'll ask you one quick question right now. >> Go ahead. >> Right now, do you have any open book or browser tab from what you're reading or studying? Can you share something like that? I usually close everything immediately. I have a generic interface from a Go blog open right now. I looked at what was there, realized I hadn't read it. It's open for me. I'll read it. >> I don't know, maybe you're reading some book right now. >> No, I'm not reading anything like that. I very rarely read books right now, especially about programming or about >> Well, so right now I'm not learning any new languages right now, as it were, and otherwise, from what's at hand, there's nothing else. >> Well, okay. Okay. Alright, then >> you should have told me, I would have prepared, I would have opened some book. I specifically didn't tell you so that you would be honest, I'm telling you, I'm honestly not reading anything. >> Okay, >> alright, then we can let you go. Thank you very much for not running away. >> I have documentation open. >> now. Can you filter? Just a second. >> Game engine. Yes, >> game engine. Yes, we covered it. >> Yes, yes, it's possible. Yes, I don't have a button. How do I remove this filter? Just type. >> Just a second. I'm not in the first. Well, it's possible, yes. Maybe you know it, maybe you don't. Yes >> no, I don't know. >> Yes, I'll find out everything. We found out, at least. >> Well, yes, it just props up my camera sometimes. This book is always on my desk. >> Yes, I sent it to Gleb once. We discussed it. He said it wasn't very useful, so to speak. No, it's a book about regular expressions. Even though it's thick, Gleb said it probably only goes over the surface, and you won't be able to delve deep enough into any of these topics. So, is it worth reading? >> All to my theme. You just need to write games. >> Beresh. So, Go engine. >> So, well, Lesha, let's let Gleb go. >> I know where. Yes, probably, I. Yes, I'm also running now, 4 hours. Yes, well, I'll ask you the same question. >> Alright, colleagues, >> let me run away after all, because they are really waiting for me. It was extremely pleasant to chat. >> Yes, thank you very much for coming. >> Yes, thank you all very much. >> Likewise. >> Yes, a bathhouse is sacred. Bye-bye. >> Thank you. Bye. >> Let me ask you the same thing, and we'll disperse. >> And I looked, I have something here from the stash that relates to something. This is Jin - it's a very bad software, damn it, what article are you reading? >> Yes, yes, yes. Can I send it to some chat, to a chat? Yes, let's do it in the studio. >> By the way, why is Jin bad? And I, it seems, >> yes. Yes, well, this is from recent. Well, no, I don't know. Here, maybe I don't know. This is what I want to read right now, from this very fresh stuff. >> I generally like to read podcasts. >> And I have several Go books, quite good ones, small softcover ones. Ah, but they are at the level, like, you know, crap, crap, crap, crap, but it will be okay, crap, crap. I read them in 2-3 days, put them away, and in that sense, I want to reread them. Something that I can recommend? No, unfortunately, nothing right now, it's all quite boring. And I'm saying, my main source of new information now is links in Telegram in various chats, channels, and so on. I don't even have time to read them, so books. >> Damn, Gleb, he closed the tab, it loaded for him, I wonder if it did, or not? Damn, I need to write to him to come back and before his browser loses it. >> Ah, well, okay. I'll just say that I'm also not reading programming books right now. I'm currently reading Volkov by Maria Semenova. It's a fiction book. I'm on the third or fourth in the series now. And, uh, technically, the last thing I read, but I've put it aside, is the same Nantntris. They also have a book, and I decided to reread it. It's even in Russian, which is cool. And, uh, I also have a couple of books on photography, so it might not be very relevant. Ah, and I'm also reading a couple of books on the history of Japan. >> So, I wrote that his tab is open and everything is loaded. Well, great, it won't be lost, otherwise we'll have to reshoot for 2 hours from scratch. >> Yes, no, unlikely. So, well, then, did our only viewer leave somewhere? Yes, imagine, our only viewer, who, well, I don't know, who heard, who didn't hear, I don't remember where I said it. In general, we are no longer broadcasting on YouTube, we are broadcasting on Riverside, and a few people joined us. And in the end, only one lasted until the end, but even he left. I thought maybe I should invite him to speak, since he stayed almost until the end. Well, thank you for coming. It was great to chat. These 3 hours, even 3 hours and 40 minutes, flew by unnoticed. I think I won't do much editing. I won't even look into the center. I'll leave it as is. I'll just process the sound, add some effects, and minimally, because re-listening during editing takes so much time, it's death. LM will make the timings for me. >> Yes. >> So, well, then we say goodbye to you too. Thank you again to everyone who watched us until the end in recording, >> yes? Okay. Everything, thank you all. Now there will be links from me, probably when you make a post. When you form it, >> yes? You'll send them to me, I'll post it and in the description to the video. >> Yes, agreed. Everything, bye-bye. >> Let's go, bye.