Analysis of common mistakes made by novice programmers, pt. 2

Hello again, everyone! We'll continue to consider problems that a young and immature programmer may face in his or her first job. The first part can be found here.Let's continue.

13. Failure to comply with coding style guidelines.

Development teams usually stick to a single coding style. That is, individual developers follow certain written or unwritten rules to ensure that their coding style doesn't differ from others. Don't try to set yourself apart with a distinctive coding style: this doesn't make you look good. If you are new to the project, you should immediately find out if there is any documentation defining general coding style guidelines. There might be some style files for your specific project that you need to ask for and import into your IDE (for example, IntelliJ IDEA), so the IDE can provide the correct coding style hints. For example, the style might require the use of the final modifier wherever possible. The style file lets IntelliJ IDEA highlight in yellow any variables where this is not respected.

14. Becoming discouraged by mistakes

Mistakes are something you have to get used to. They have been, are, and will be. It doesn't matter if you are a beginner or a serious architect, you're always going to make mistakes. The number and severity of your mistakes may change, but they will accompany you throughout your career. Sometimes you struggle to get something to work all week, you make a mistake, and then it's Friday evening and you slink home like a beaten dog, without being able to fix that damn mistake. It's an indescribable feeling, but not something that should discourage you. After all, another important difference between an experienced developer and a novice is how he or she handles mistakes. Experienced developers do not take them to heart, but instead regard them as experience. No one will scold you for making a mistake. This is normal — everyone steps into a mess at times. Again, you can ask colleagues for help. And don't forget about people like project managers (PM). If you're stuck on something, you should immediately reach out to the PM. He or she can help you find someone who is an expert in the problematic area. In any event, the PM needs to be kept informed about any problems you encounter on the project. It is the PM's job to help solve all sorts of problems, including communication and interactions between team members. To summarize: Mistakes happen, don't let them kill you. Instead, accept them as a challenge to you and your skills. In the end, it's only part of the job.

15. Failure to implement thread safety.

Nothing good is created easily. Every developer needs to understand that writing specific functionality, whether it be a module or just a method, requires a plan regarding what will be done and how. As a rule, when developing functionality of any complexity, you need to stick to the following procedure:Many errors that arise in code written by novice programmers relate to the steps in this procedure. Of course, you can't rule out that there are moments when you need to rapidly write code without hesitation as soon as you see the task. But this generally only works for certain minor tasks and methods whose implementation is obvious and does not require much thought. The development procedure mentioned above is more suitable for complex and large tasks that can be divided into subtasks. It's not a good idea to start writing code without clearly understanding what you want to write. First, you need to carefully think about and plan everything. It can also be helpful to grab a sheet of paper and a pencil and try to sketch out your implementation ideas. I always do this when planning complex functionality. A programmer spends most of his or her time not writing code, but rather thinking about how to structure of the required functionality. Indeed, once you've planned and thought about everything, writing code becomes a hassle-free purely mechanical process.

16. Overworking

from the movie "Fight club" (1999) Perhaps every beginner thinks that by working into the night, he or she will begin to complete more tasks and will be entrusted with more responsibility. I used to think so too, but not anymore. I noticed that there comes a point when you hit your limit, when you cease to be able to think adequately. You start to get pretty dull and experience mental fog. It takes an hour to do things that you could do in 10 minutes if your mind were fresh. Almost without exception, after you cross this line of fatigue, you encounter some problem that seems insurmountable. But when you come to work the next morning, you solve it in the blink of an eye. So when you feel that you have reached this point, don't stay up late. Just go home and have a good rest. After all, if you stay at your desk until late at night, not only will you not achieve particularly outstanding results during these hours of torment, but at the same time you risk poor (insufficient) rest before the next work day, when you'll screw up once again. Think about your health: is it worth undermining it like this at the beginning of your career? I think not. It's an expensive time to be sick. And think about your employer. By overworking yourself, you make things worse not only for yourself, but also for your employer. Who needs an employee who is perpetually sleepy, who, due to exhaustion, can't implement the simplest sorting algorithm? Yes, there are undoubtedly times when you have a hot deadline, times when everything has gone wrong, and times when — and this is my personal favorite — "we need this yesterday". But these situations are generally rare, and once you get through them, you need to sit down and carefully consider how they could have even happened and how to avoid them in the future.

17. Neglecting English skills

Many aspiring developers prioritize learning technology and put off learning English. This is a serious mistake, since quite often a programmer is a perfect fit for a junior position (or internship), but doesn't get the job due to weak English skills. Yes, of course, there are cases when you can get by without English. As a rule, such people are hired locally for projects in non-English-speaking countries. But local companies do not pay the same wages as foreign companies. And it will be very, very difficult to get a decent salary, even over time. That's why you should not ignore English. Rather than putting English on the back burner, you need to learn it in order to immediately focus on English-language projects. Indeed, think about it for a minute — English is currently the language of international business. Whichever country you go to, you can find a common language with others if you know English. The same is true in development projects. It doesn't matter where the project it based: Germany, Australia, France, or elsewhere — all the communication, all the tasks, documentation, etc. will be in English. And if you think about it for a second, you'll agree that this is very convenient, right?

18. Pursuit of trendy technology

As developers begin on their path, they often try to keep up with the latest technologies. Is that the right thing to do? On the one hand, yes: the latest technologies, projects ... But is it worth it to make this a top priority? Perhaps it is better to pursue the "classic toolkit" for a specialist in your field? New is certainly good, but you must not forget about the fundamental technologies of your field. And only then, after you have gained a little experience with and deep knowledge of the basics, you can try something new. Consider also that new technologies may be superior in some subtle ways, but they may lose advantages in others. Until a novice developer understands these tradeoffs, it is better to stick with the time-tested solutions. For example, if a programmer is developing an application that interacts with some data, then don't rush to use the latest NoSQL solution simply because it is in fashion. An ordinary tried-and-true SQL database (MySQL, PostrgreSQL, etc.) most likely has detailed documentation and solutions on StackOverFlow for any potential problems :)

19. Learning several different technologies and/or languages at once

We talked above about beginners trying to learn fashionable technologies. Well, what about simultaneously studying many technologies or languages? Obviously, you've heard of programmers who know more than one programming language and have mastered many technologies. But I'll quickly point out that these people are far from new to programming. These are people with many years of experience behind them. They have mastered their original technology and then gone further and further. Beginners trying to master everything at once should remember the excellent proverb: "chase two hares and you won't catch either one." The consequence may be that you will not master any topic well, but only learn subjects superficially. There will be more demand for a specialist who knows a single language deeply than for one who knows a little bit about everything. So if you want to know many languages and technologies, you need to approach them wisely. To get started, you need to choose a basic, core language that you must learn deeply. And only then should you begin to study other areas. For example, become a Java guru, then learn Python as a second language. After that, you might learn something about react/angular for the frontend. In this case, we're talking about technologies that are not interchangeable, such as C# and Java, but rather complementary, expanding your career opportunities. But again I repeat: you shouldn't try to learn everything at once. You need to go sequentially. Catch one hare at a time, so to speak.

20. Incorrectly formulated goals

How do you set goals for yourself? Become a cool developer? Remember this once and for all: you need to set concrete goals, or in other words — achievable goals. What am I talking about? For example, you set yourself the goal: "I want to become rich". But how would you know whether you have achieved this goal? Or how do you measure how close you are to achieving it? Well, if you set the goal "I want to make a million dollars", that's a little clearer, isn't it? Once you've earned $10,000, you are $10,000 closer to your goal — just $990,000 left to go. There is still a lot left to achieve, but you can feel your progress and understand where the finish line is, so you will be motivated to keep going. In terms of your career, how about setting yourself a more tangible goal? For example: I want to become a team lead. Or a senior dev. Or ultimately an architect. Well, every big task needs to be divided into small subtasks. You don't become a team lead at the start of your career. Set deadlines if possible and appropriate, and focus on the current stage.

1. If we're talking about becoming a senior developer, then the first small goal would be to find an internship or a job as a junior developer at a company.
2. Next, you can set goals to deepen your knowledge of certain technologies. In regards to Java, you could prepare for Oracle's Level 1 certification. We establish a time frame for our preparation and tackle the goal.
3. Then, for example, you might set a goal to improve your English by one level (say, from B1 to B2). We draw up a learning plan, schedule the time, and move towards the goal.

This is how we can achieve our ultimate goal step by step (while gaining software development experience).

21. Theory without practice

It is an indisputable fact that we become better professionals by studying new technologies and going deeper into topics we already know. But at the beginning of the journey, developers rarely realize that devouring technical books one after another does not bring huge benefits if the new knowledge is not tried out in practice. I have personally come across this more than once. If you devote a lot of time to a book but you do not practice anything from it, then almost all the newly acquired knowledge is forgotten: you're left with only a general vague memory of how everything works. The result is a lot of wasted time with no tangible result. Why should we waste our time? Life doesn't last forever. The takeaway is that when you are learning a new technology, you shouldn't get hung up on the theory: write out the given examples in parallel with your reading, experiment with the new technology. This is the only way to get your brain to retain the information. Yes, you will consume new materials must more slowly, but you will assimilate significantly more of what you read. What's more, if you master one technology well, then the next will be even easier to master (just as with learning languages).

22. Excessive perfectionism

Most developers are perfectionists: people who strive for perfection. This means that their code must also be perfect. So your code has been written, tested, finetuned, and it seems like it's time to submit it to the main branch. But you still aren't satisfied with the code, so you start twisting it this way and that, spending a lot of time on this effort. And in this case, time is your client's money. Novice programmers are more susceptible to this quest for perfection. Experienced developers are accustomed to the feeling that the code will never be perfect and that they should try to write it better. But at the same time they don't go to extremes in an effort to get closer to "the ideal". So, remember to learn how to achieve a happy medium: not in a slipshod fashion and not trying to recreate the Mona Lisa in code.

23. Failure to think about architecture

Let me say it again: you should not write messy code. In addition to readability and performance, you also need to think about how your code might affect the rest of your application as a whole. For example, how difficult will it be to extend your code, and so on. The problem is that novice developers, due to their lack of experience, may not immediately realize how their new functionality will affect the application in the future. This foresight certainly takes a lot of practice to develop. But what then are novices to do? Not write code? In these situations, various programming paradigms come to our aid. For example, S.O.L.I.D. principles or various design patterns that can convey useful practices to you. These paradigms should also be treated with caution and not taken too far. But how do you determine the point when you're overdoing it? This is where a code review by a more experienced colleague will help you. By bringing in fresh and objective eyes, your colleague can point you in the right direction.

24. Impostor syndrome

Impostor syndrome is a psychological phenomenon in which a person is unable to attribute his or her achievements to personal qualities, abilities and efforts. Despite the external evidence of their consistent performance, people susceptible to this syndrome continue to believe that they are frauds and do not deserve the success they have achieved. Many developers have this syndrome. Perhaps it gives us the persistence that drives us forward to new knowledge and technologies. You look at more experienced and accomplished colleagues and you feel uneasy, like you aren't worth your salary. Believe me, this is not true. There are and always will be developers who are better or worse than you. Someone else looks at you and feels uneasy, thinking that he or she will never become like you. And this is normal. Feedback from your team, code reviews, and discussions help combat this feeling a little. Believe me, an outsider's opinion will pleasantly surprise you, but only if you genuinely don't neglect your work and professional development. If you neglect those things, then you have chosen the wrong profession. In this profession, you need to always be learning something new and striving for the best. But I think the people gather here are far from being lazy. Instead, the people here are steadfastly moving towards their cherished goal. If that describes you, then you have nothing to fear.

25. Rarely making commits

Remember to perform commits often! Not every half hour, mind you. If you spend a week implementing some functionality, then you should not perform one commit on Friday night, but, say, five commits. Almost any large task can be broken down into smaller tasks for convenience. So you complete these smaller tasks and commit. And don't forget to send these commits to the remote server right away. Otherwise, you might make commits all week and then your computer has a hardware failure on Friday at lunchtime, and then you've lost a whole week for nothing! But if you uploaded your commits to a remote server, then you would just pull the branch with your last commit onto another computer and continue working. One more thing: don't submit new functionality to a live production server on Friday night. Just trust me. You don't need that. It is highly likely that unexpected errors will come to light, and you will spend your weekend fixing them. And that is not fun. You need to rest on the weekend. I guess that's all for today. P. S. One last tip: write a lot of code. P. P. S. Write an INSANELY large amount of code, because that is the only way to gain much needed experience.