Transcription
Hello, my dear friends!
On this channel, there are quite a few videos discussing the mistakes that beginners make while learning programming. However, time moves on, and we discover new mistakes that become quite common, possibly because we haven't recorded videos about them yet.
So, here’s a new video featuring a list of new mistakes in learning to become a programmer. My name is still Sergey Nemchinsky. [music] Let's get started!
The first new, yet very common mistake is searching for the perfect time to start studying. Guys, there will never be a perfect time to start. In fact, the perfect time to start was yesterday, or even better, a couple of years ago. If that were the case, you would already be working as a programmer now.
That's just how it works. As they say, in two years, you will regret not starting now. Right now, you regret not starting back then, and so on. This is how it always works. There will always be excuses: "Oh, I had a baby," "Oh, there’s a war in the country," "Oh, my back hurts," or something else. You will always come up with a reason to procrastinate.
Just don’t procrastinate—start now! If you want to be a programmer, start being one now.
Okay, there will never be a perfect time when astrologers declare a week for learning programming. Sorry, that only happens in video games.
The next mistake, which shocked me with how common it is, is when a person writes code, learns something, and even learns it correctly, but memorizes the theory verbatim. They take a book and memorize everything from it, then come to me with questions like, "Sergey, I tried to memorize this, but I just can't remember the wording. It's not very convenient."
Guys, I have news for you: no one knows the theory by heart. Moreover, if you do know it by heart, it will shock the interviewer because, first of all, they don’t know it by heart either. Secondly, it will raise suspicion: are you really a programmer, or did you just memorize the theory and actually can’t program at all?
So, you need to understand the theory and then explain it in your own words. That’s the only way to impress the interviewer. If you try to rattle off the theory verbatim, you will come across as a school student, not a programmer. Please don’t do that!
I never thought this could even cross someone’s mind, but I’ve already seen several cases.
September is the perfect time to start learning and begin your journey in IT. Moreover, right now, you can get an incredible 50% discount on all introductory programming courses, specifically Java, C#, JS, and Python. Choose your programming language and take a step closer to your dream profession.
For experienced developers, we offer a 50% discount on the Algorithms and Data Structures course, after which you will be better prepared for interviews. Register for the courses using the links in the description below this video.
It’s time for big changes!
The next mistake is trying to learn everything at once or learning everything randomly without having any roadmap. This is a very strange mistake, but it often happens with those who build their learning from theory.
For example, "I’m learning Java. What’s included in Java? Oh, Hibernate is part of it." After learning the basics of Java, they rush to learn Hibernate without first understanding where it is used.
It’s better to try to integrate it into your project. When you try to integrate it, you will understand what you actually need to know. Instead, you might dive into complexities with foreign keys or complex structures like trees, which is quite a non-trivial task.
You might learn all this, but it won’t help you write code because you should only learn the theory that you need to write the program you are currently working on. The only way to remember something in programming is to start using it right away—sit down and start coding.
Ideally, you should first encounter a problem, then Google it, learn the theory, and immediately apply it. In this case, you will remember it 100% because that’s how our brain works.
If you just randomly poke around, like, "Oh, there’s a word in the job listing, SOA, I’ll go learn SOA," without understanding where it’s used or why, you will end up with random pieces of knowledge that don’t relate to each other. This won’t bring you closer to understanding or being able to work as a programmer.
So, write the program you need, and then go study what you need for it. Naturally, you should have a general roadmap of what should be included in your project and what you will study to integrate them into the project.
In fact, having a roadmap is essential. Without a roadmap, there’s no learning.
The next common mistake is giving up too early. This is a very widespread issue.
You see, a programmer is someone who never gives up. This is a very complex concept, and it’s hard to execute. I know this myself.
Even as a senior developer, I regularly encounter situations where a problem seems unsolvable, and your subconscious says, "Let’s just give up." But a programmer is not someone who can just give up.
The only way to give up is to quit your job and go to another one. In all other cases, you keep fighting the problem that needs to be solved. If the client needs the problem solved, then it must be solved.
Moreover, if there’s a programming problem, it can be solved. There are no unsolvable problems. You are the one who constructs the airplane; if it can be constructed, then you can construct it.
The same goes for a program. If the program can be understood in terms of what needs to be done, then it can be done. Period.
How much time you spend on it doesn’t matter, but you must understand that there is always a solution, and you cannot give up. You just have to keep pushing through.
Now, a few more mistakes, but they are not as critical. However, they can still affect your learning significantly.
The first and most important technical mistake in learning is not using a version control system.
At this point, it’s practically essential. I understand that to a beginner, using Git seems like something only professional programmers do. "When I get a job, then I’ll use it." No, guys, this is the very tool you should start mastering from the moment you write your first application.
If you don’t use Git for your first application, you are not really learning programming. Why? Because learning programming involves a huge process of trial and error.
If you try something, realize you went the wrong way, and need to revert to a previous state, how are you going to do that? Theoretically, if you don’t have Git, you’ll end up creating 150 backup folders every half hour, and then you’ll have to figure out which version to revert to.
Let’s be honest, no one does that. Maybe for the first couple of hours, you’ll do it, but then you’ll end up with a mess where nothing compiles.
The best way to handle this is to save your current state in Git and try something unusual. If it doesn’t work out, you can revert to the previous state and try again. That’s how programmers learn.
So, if you’re not using Git, I’m sorry, but your learning process will likely be filled with pain and suffering. Please don’t do that!
Moreover, you will probably be afraid to try something new, which will slow down your learning significantly.
Next mistake, which almost all self-taught students fall into, is ignoring code style.
There are even courses that ignore code style, but in my opinion, that’s a significant red flag. If your course ignores code style, believe me, that’s a very bad sign.
Even if they ignore it, don’t ignore it yourself. The thing is, you might think, "I’ll get a job and write properly then." But that doesn’t work. It’s a habit.
It’s like saying, "I’ll get married and start washing dishes." No, you won’t start washing dishes. You either wash the dishes after eating or you don’t. It doesn’t depend on how many people live in your house or how it all looks.
You need to get used to using proper code style from the very beginning.
To write professionally, you need to start from the beginning. Read your language’s code style document. There’s one for every programming language.
Look at how professional code should look in your language. What names should be capitalized? What should be lowercase? For example, classes, methods, etc.
Is CamelCase used, or is it underscores? How are long lines wrapped? In programming, long lines often occur. How is that typically done?
Are single-line if statements used or not? How is that done? Check all the code style guidelines and try to stick to them.
From my experience, almost any decent IDE supports automatic formatting according to the code style of the language. Use that feature!
In Eclipse, it’s Ctrl + Shift + F. I still remember that! Format your code according to the rules of your language. This will help you a lot.
Also, in most IDEs, you can add plugins or simply enable a setting to highlight code style issues in your code, showing you what not to do.
Otherwise, you will get used to writing poorly, and believe me, writing good educational code is much easier than writing good production code.
In production, you will be under pressure, and you’ll need it done yesterday. If you’re not used to writing good code beforehand, your code will just be a mess.
Next technical mistake is not testing your code.
If you are the only programmer on a project, or if you’re writing your own project, which is usually the case, even if there are several programmers, it often happens that testing is neglected.
It often turns out that the programmer only checks the main execution flow or doesn’t check anything at all. They just compile and say, "That’s fine, let’s move on."
This is a very bad approach. In fact, you learn much more from fixing bugs than from adding new features.
As they say, writing new code is easy; fixing old code is hard. If you don’t do what’s hard, you will never learn anything.
So, get up and start checking all the possible paths through your code.
And last but not least, the absence of error handling is a widespread issue among most self-taught beginners. They think, "Why should I handle errors? I just put a try-catch block, and everything is fine."
No, guys, that’s not how it works. This is a habit. If you get used to not handling errors, it will significantly slow down your development.
When you have proper error handling, your errors are meaningful, and you know what went wrong and where. You get a decent stack trace or some dump information.
If you prepare to provide meaningful error messages, I can honestly tell you that I’ve had many cases where I worked with my team on existing code and added error handling. It was immediately clear that it was done by inexperienced developers.
So, learn to handle errors from the very beginning. This will always be useful.
In general, error handling is one of those signs that clearly indicates whether you are a beginner who has never worked in industry or someone ready to sit down and start writing production code.
So, learn this from the start.
I hope this set of tips will be very useful to you. I’m quite sure it will help you significantly.
If you know of any additional mistakes we haven’t covered here, please write them in the comments. We’ll record another version of this video with new programming mistakes.
So, I’m reaching out to you, experienced developers. Let’s add more mistakes!
Colleagues, I also wanted to add that it seems our channel has fallen under a shadow ban. Maybe we stepped on someone’s toes.
If you like what we’re sharing, please watch our videos, like them if you enjoyed them, subscribe, and leave comments with more than four words so that YouTube knows this content was interesting to you.
Overall, support our channel! We would really appreciate it, and it will help us create more content for you with various interesting stories.
As Brian Kernighan said, "The only way to learn a new programming language is to write programs in it." I completely agree. Mastery comes only with [music] practice.