Transcription
If I could change just one thing during the time I was actively learning to program, it wouldn't be switching languages or watching different tutorials. It would definitely be a change in my approach to learning and my entire mindset regarding programming in general.
Hello everyone, for those I haven't seen, in this video, I will talk about how to change your approach to learning programming. This isn't just about learning languages and technologies; it's about developing the right mindset that distinguishes great programmers.
We'll discuss why practice is much more important than theory, how to overcome your ego, and what it means to get used to discomfort. If you want to embark on the path to becoming a truly quality programmer and, first and foremost, a professional, stay tuned until the end. There will be many useful insights, not just from me but also from many others who have been in the profession for several years.
So, first, practice should outweigh theory. You've probably heard of the 10,000-hour rule, which suggests that to become a professional in any field, you need to dedicate 10,000 hours to it. At that time, I interpreted this as needing to read more books, watch more educational videos, learn more languages, and so on, all for 10,000 hours. The faster I did this, the faster I would become a more professional programmer.
Now, my philosophy is radically different from what it was back then. It sounds like this: I need to write every project and every line of code better than I did before. Do you feel the difference? Yes, programming is primarily a skill that can and should be developed. The more mistakes you make, the more you learn, and the faster and better you will learn new things.
Programming is more like playing a musical instrument or painting. No matter how many videos you watch, you won't learn to play the guitar until you try it yourself. You can watch videos on how to draw a PHP logo for 10,000 hours, but until you open Illustrator and start drawing it yourself, you won't succeed.
Learning should always be tied to practice. Delaying the moment when you turn off another guide on technology X and finally start writing code will only lead to effective information retention, not quality learning. This point is closely related to how to learn programming in general.
So, if this video gets some feedback through comments and likes, I will immediately start preparing material on this topic.
Pride is your enemy. No one wants to do routine and boring work, like creating a tedious page or parsing the same data. After all, I'm a programmer; I only want interesting and cool tasks. I want to write my clones of YouTube or Telegram, create my service using artificial intelligence. I don't want to work with legacy code, bugs, and errors.
When such thoughts come to you, know that your ego is speaking. If you don't fight it and refuse to adopt such a position, you won't be able to work in a team, be useful, or learn and develop effectively. Such thoughts will always arise. Even I, after several years of working in IT, still experience them, and I try to fight them in every way possible. When I manage to do this, my productivity increases significantly, and I can extract a lot of benefits from such moments.
Also, your mindset improves. In this point, I should mention another important thing: don't get attached to your code. Code is primarily just code. Someone else, or even you, will change it sooner or later. Code is an ephemeral concept; there's no need to defend it with all your might and lash out at those who dare to touch your sacred grail and edit it.
Getting used to discomfort as a programmer, you are not obliged to be a walking encyclopedia and know absolutely everything. Your task as a programmer is not to provide answers on demand or even to write code. Your job is to successfully solve business problems and quickly adapt to the surrounding conditions.
You may always receive a new task that goes beyond your stack or something new that you haven't encountered before. This task can be described at a very high level without technical details, and that is super uncomfortable. If we had our way, we would always do only what we have already encountered, and that's normal because our brains are wired that way.
So, when we face something new and unclear, it is always stressful. If we don't keep such emotions and thoughts in check, we will unintentionally avoid direct confrontation with such situations. But as a programmer, you should understand and get used to the fact that you will constantly encounter something new, unclear, and uncomfortable.
If you don't know something and can't solve a problem immediately, it doesn't mean you're a bad programmer. A bad programmer is someone who doesn't want to step out of their comfort zone. A bad programmer is someone who isn't ready to change.
"I don't know; I can't do this, but I will study and figure it out." The most effective development, as we know, happens when people step out of their comfort zones. And this isn't just the words of another internet flop; numerous studies confirm this.
For example, a person maximally develops when they move to another country because everything there is new and unfamiliar. You constantly have to step out of your comfort zone by learning the language, making new acquaintances, and adapting in general.
A good programmer accepts and studies uncomfortable tasks and technologies, which only adds to their expertise. And I repeat, "I can't do this, but I will study." Just approach unfamiliar tasks differently. In a sense, this should bring you joy.
"Okay, I shouldn't be afraid of something new. Now I will learn something cool and become better than I was before completing this task."
So, what conclusion can we draw from everything I've said? You will never be able to learn programming. All beginners have the eternal question: "Which language should I learn first? How much time should I dedicate to learning? Which courses should I take? What's better, frontend or backend? How quickly will I learn language X or language N? What's currently relevant? Will I lose out if I take on technology N?"
Of course, in some sense, all these questions are valid and deserve attention, and they can even be answered depending on the context. But by focusing on such questions, you miss the essence of programming.
For beginners, you don't need to master languages and directions perfectly at the beginning of your journey. You should take and try to create your applications using the language, constantly implementing and studying its features.
A language, library, or framework is primarily a tool. When you have a task to drive a nail, you need to learn the process of hammering nails into a wall or any other object without smashing your fingers or ruining the wall.
How you do this—whether with a hammer or your head—is a secondary question that doesn't hold any distinguishing significance. Similarly, you don't need to memorize and fully understand various concepts of a language or other tools at a basic level. You are already trying to understand them while reading documentation, books, or watching tutorials.
After that, you go and repeatedly implement them in your projects, which leads you to better understand their purpose and how to use them.
Let me illustrate with an example. Suppose you are working on a project based on a guide and encounter concepts or tools that pose some difficulties, like ORM models and queries. What do you want to do? You pause the video and start adding functionality to your code. Errors start popping up, everything breaks, and nothing works.
You continuously Google, read articles, and forums to solve the problem that has arisen. Even if everything works after your efforts, you don't think about how it works, and nothing sticks in your mind.
You and I both understand that by tomorrow morning, at best, you will retain about 20% of all the information you received.
So how do you do it right?
"Okay, I don't understand what I just did, but I will finish the logical section of the tutorial or guide, and then I will go and do small projects related to this functionality."
You might immediately counter, "Okay, how will I find a job if I don't master all the techniques, tools, and concepts at the required level for the job?"
And here you again miss the essence. When you are hired for an intern or junior position, they do not expect you to have a good command of the necessary tools. What is expected of you is knowledge of a certain part of the stack for which the company is hiring you, say, frontend development in React.
What is even more important is that you are expected to have patience, persistence in continuous learning, and a willingness to absorb new things. This is how you become a truly great programmer. They know and understand the basics very well, not because they read many books or watched a huge number of tutorials, but because of the countless projects they created and their strong desire to learn something new.
Through their own experience, they bury their ego. They strive to step out of their comfort zone because they want to learn something new, and their continuous learning transforms into an ongoing pursuit of mastery in programming.