Analysis of typical mistakes of novice programmers: part 2

Hello everyone again! We continue to consider the problems that a young and fledgling programmer may face in his first job. The first part can be found here . We continue:

13. Wrong coding style

On projects, as a rule, one style of writing code is supported. That is, different developers follow certain written or unwritten rules so that their code does not differ from others. No need to try to somehow stand out with the help of a peculiar style of writing code: this will not add pluses to your account. If you are new to the project, you should immediately find out if there is any documentation that describes the general approach to the style of writing code. Perhaps there are some style files specific to your project that you need to ask to drop and import into the environment in which you are working (for example, IntelliJ IDEA), so that it can in turn make hints according to the style specified by the file. For example, the style will specify the use of the final modifier wherever possible, and IntelliJ IDEA will highlight variables in yellow,

14. Get discouraged by mistakes

Mistakes are something you have to get used to. They were, are and will be. Whether you are a beginner or a serious architect, mistakes will always be with you. Perhaps their levels and numbers will change, but they will accompany you throughout your subsequent career. It happens that something doesn’t work out for you all week, some kind of error falls, and now it’s Friday evening, and you’re crawling home like a beaten dog without fixing that damn mistake. An inexpressible feeling (But this is not something that should be discouraged. After all, another important difference between an experienced developer and a beginner is the attitude towards mistakes. Experienced specialists do not take them to heart, but rather regard them as experience. And no one will scolding for a mistake: this is normal, everyone goes through moments of plugging.Again, you can ask colleagues for help. Also, don't forget about guys like project managers (PMs). If you are hung up on something, you should immediately write to the project. He can help with the search for a person who is special in this area. And in general, he needs to be kept informed of your problems on the project. It is his job to help solve all kinds of problems, in addition to communications and interactions between team members. Summarizing:Mistakes are okay , don't kill yourself over them, take them as a challenge to you and your skills, because after all, it's just part of the job.

15. Lack of a clear plan

Nothing good comes easy. Any developer should understand: in order to write a certain functionality, whether it be a module or just a method, you need to plan what will be done and how. As a rule, in the development of functionality of any complexity, you must adhere to the following procedure: Many errors that occur in the code of novice programmers relate to one of the points in this procedure. Of course, you should not exclude that there are times when you need to rush to write code without hesitation, only after seeing a task. But as a rule, this only works for some minor tasks and methods, the solution of which is obvious and does not require much thought. The above development rule is more suitable for complex and large tasks that can be divided into subtasks. Starting to write code without a clear understanding of what you want to write is not a good idea. First, you need to think carefully, plan everything. It is also helpful to take a sheet of paper and a pencil.and try to visually display my implementation ideas (I do this all the time when planning complex functionality). Most of the programmer's time is taken not by writing code, but by thinking about the structure of the necessary functionality . After all, when you have already planned and thought everything over, writing code is a purely mechanical action without any difficulties.

16. Recycling

Perhaps every newcomer thinks that if he works until night, he will begin to cope better with his tasks and quickly, so to speak, will enter everything. I used to think that too, but now it's not. I noticed such a moment: there comes some time, what is the limit, beyond which you already cease to think adequately. You start to get pretty stupid, sticky and do things for an hour that you could do in 10 minutes with a fresh head. And as a rule, after crossing this line of fatigue, you run into some kind of problem that seems insurmountable. But when you come to work in the morning, you solve it in the blink of an eye. So, when you feel like you've reached this point, don't stay up late, just go home and have a good rest. After all, if you sit until late at night, you will not achieve particularly outstanding results during these hours of torment, but at the same time, you run the risk of having a bad (little) rest before the next working day and ruining it too. Think about your health: is it worth undermining it like this at the beginning of your career? I think not. It's expensive to get sick. Also think about the employer. By overworking, you make worse not only for yourself, but also for him. Who needs an eternally sleepy employee who, due to fatigue, cannot implement the simplest sorting? Yes, of course, there are moments when the deadline is on fire, everything went wrong and this is my favorite - “it should have been yesterday”. But as a rule, such situations are rare, and after them you need to sit down and carefully consider how this could have happened at all and how to avoid this in your future. what is not. It's expensive to get sick. Also think about the employer. By overworking, you make worse not only for yourself, but also for him. Who needs an eternally sleepy employee who, due to fatigue, cannot implement the simplest sorting? Yes, of course, there are moments when the deadline is on fire, everything went wrong and this is my favorite - “it should have been yesterday”. But as a rule, such situations are rare, and after them you need to sit down and carefully consider how this could have happened at all and how to avoid this in your future. what is not. It's expensive to get sick. Also think about the employer. By overworking, you make worse not only for yourself, but also for him. Who needs an eternally sleepy employee who, due to fatigue, cannot implement the simplest sorting? Yes, of course, there are moments when the deadline is on fire, everything went wrong and this is my favorite - “it should have been yesterday”. But as a rule, such situations are rare, and after them you need to sit down and carefully consider how this could have happened at all and how to avoid this in your future.

17. Neglect of English

Many novice developers put the study of technology in the first place, and English somehow for later. This is a serious mistake, since quite often a programmer is ideally suited for the position of a junior (or intern), but he is not taken because of poor English. Yes, of course, there are cases when you can go without English. As a rule, such people are taken for projects in the domestic market. But local companies do not pay the same money for developers as foreign ones. And it will be very, very difficult to knock out a decent rate even over time. Therefore, the English language should not be missed in order to immediately focus on English-language projects, and not put them on the back burner. After all, if you think for a moment, now English is the language of international communication. What country would you go to you will be able to find a common language with people if you know English. Same with projects. It doesn't matter what kind of project it will be: German, Australian, French or some other, anyway, all communication, all tasks, documentation, etc. will be in English. Well, if you think about it for a second, it's very convenient, isn't it?

18. Pursuit of fashionable technologies

Starting their journey, developers often try to keep up with the development of the latest technologies. Is it correct? On the one hand, yes: the latest technologies, projects… But is it worth making this a top priority? Perhaps it's better to push on the "classic set" of a specialist in your field? After all, new is certainly good, but you must not forget about the fundamental technologies of your direction. And only then, after you have gained a little experience and deep knowledge of the basics, you can try something new. Keep in mind that new technologies are superior in some nuances, but lose in others. And until a novice developer has an understanding of these features, it is better to use 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 just because it's in vogue. Most likely, a regular SQL database (MySQL, PostrgreSQL ..) is also suitable, which has long been tested by time, has detailed documentation and solutions to all problems on StackOverFlow :)

19. Learn multiple technologies or multiple languages ​​at once

Above, we talked about the development of fashion technologies by beginners. What about learning multiple technologies or multiple languages ​​at once? You have obviously heard of programmers who know more than one programming language and master many technologies. But I will hasten to point out that these people are far from being new to programming. These are people with a lot of years of experience behind them. They have already become masters in their original technology, and have gone further and further. As for beginners trying to master everything at once, the proverb is perfect here: “chasing two hares, you won’t catch one.” The consequence may be that you will not master any direction well, but only go over the tops. A specialist who knows one language deeply will be more in demand than everyone else, but a little bit. So if you want to know a lot of languages ​​and technologies, you need to be smart about it. To begin with, you should have a basic, main language that needs to be studied in depth. And only then, starting from it, to study additional directions. For example, become a Java guru, then learn Python as an auxiliary language, and then you can learn something from the react/angular front end. In this case, these technologies are not interchangeable, such as C # and Java, but complement each other, expanding your career opportunities. But again, I repeat: you should not try to learn everything at once, you need to sequentially. So to speak, to catch hares one by one. explore additional areas. For example, become a Java guru, then learn Python as an auxiliary language, and then you can learn something from the react/angular front end. In this case, these technologies are not interchangeable, such as C # and Java, but complement each other, expanding your career opportunities. But again, I repeat: you should not try to learn everything at once, you need to sequentially. So to speak, to catch hares one by one. explore additional areas. For example, become a Java guru, then learn Python as an auxiliary language, and then you can learn something from the react/angular front end. In this case, these technologies are not interchangeable, such as C # and Java, but complement each other, expanding your career opportunities. But again, I repeat: you should not try to learn everything at once, you need to sequentially. So to speak, to catch hares one by one.

20. Wrongly set goals

How do you set goals for yourself? Become a cool developer? Remember once and for all: goals must be set physical, or in other words, achievable. What am I talking about? For example, you set a goal for yourself: I want to become rich. And how will you know that you have already achieved this goal? Or how do you measure how close you are to her? Well, if you set the goal “I want to earn a million” - this is already a little clearer, isn't it? By earning 10k, you'll be 10k closer to your goal, leaving you with 990k. There is a lot ahead, but you can feel your progress and understand where the finish line of your goal is, and this will not let you give up. In terms of career, how about setting yourself a more tangible goal? For example: I want to become a team leader. Or senor. Well, or an architect, after all. Well, a big task needs to be divided into small subtasks. You will not become a team leader like this from the threshold of a career. Set deadlines if possible and appropriate, and focus on the current stage.

1. If we are talking about becoming a senior , then the first small goal would be to find a job as a junior or an internship in a company.
2. Further, as goals, you can set the deepening of knowledge in certain technologies. In Java, preparation for Oracle Level 1 Certification. We set ourselves a deadline for preparation and go to the goal.
3. After, for example, you can set a goal to bring English up to one level (say, from B1 to B2). We make a preparation plan, plan the time and move towards the goal.

And so, step by step (in parallel gaining experience in development) we can achieve our final goal.

21. Theory without practice

It is an undeniable fact that the study of new technologies, deepening into those already studied is what makes us better as professionals in our field. But developers rarely realize at the start of their journey that consuming technical books one by one is not of great benefit if new knowledge is not tested in practice. I myself have come across this many times. It used to happen that you kill a lot of time on a book, but at the same time you do not practice anything from it, and almost all the newly acquired knowledge is forgotten: only a general vague memory of how everything works approximately remains. The result is a lot of wasted time with no tangible result. Why should we waste time? Life is not endless. Therefore, when studying a new technology, do not get hung up on theory: write examples in parallel, experiment with new technology, And that's the only way you'll get something stuck in your head. Yes, the rate of consumption of new materials will drop considerably, but at the same time, the quality of assimilation will increase significantly. Well, if you master one technology well, the next ones will be easier to assimilate (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. And now the code has already been written, tested, edited, and it seems like it's time to upload it to the general branch. But the creator still doesn’t like the code, and he starts twisting it this way and that, spending a lot of time on it. Well, time in this case is the client's money. Beginning programmers are more susceptible to this pursuit of excellence. Experienced developers have become accustomed to the feeling that code will never be perfect, and that you need to try to write it better, but at the same time not go too far in an effort to get closer to the ideal. So, remember: you need to learn how to keep the middle ground, and not just in a hurry, but try to recreate the Mona Lisa in code.

23. Don't think about architecture

Again, I will say: you should not do everything just to how. In addition to readability and performance, you need to think about how your code can affect the rest of the application as a whole. How difficult it will be to expand your code, and so on. The fact is that newbies, due to lack of experience, may not immediately notice how their new functionality will affect the application in the future. This certainly takes a lot of practice. But then what do newbies do? Don't code? In such cases, different programming paradigms come to our aid. Like for example SOLID or various patternsprogramming that can bring you useful practices. These paradigms should also be treated with caution and not overdone. And how to determine the degree of inflection? This is where the review code from a more experienced colleague will help you, who, looking from the outside, will be able to direct you in the right direction.

24. Imposter Syndrome

Imposter syndrome is a psychological phenomenon in which a person is unable to attribute his achievements to his own qualities, abilities and efforts. Despite external evidence of their worth, people affected by the syndrome continue to believe that they are liars and do not deserve the success they have achieved. Many developers have this syndrome. Perhaps, he gives us the perseverance that drives us forward for new knowledge and technologies. You look at more experienced and accomplished colleagues and it seems to you that you are not at ease, that you are not worth the money that you are paid. Believe me, it's not. There will always be developers who are better or worse than you. With the same eyes, someone will look at you and think that he will not become like that, and that he is not at ease. And that's okay. Feedback from the team, code reviews and interviews helps to cool this feeling a little. Believe me, the opinion from the outside will pleasantly surprise you, but only if you really don’t give a damn about work and your professional development. If you score, then you have chosen the wrong profession. In this profession, you need to learn something new and always strive for the best. Well, I think that far from lazy people have gathered here, but people who are unshakably moving towards their cherished goal. If so, then you have nothing to fear. Read more about impostor syndrome here.here and here .

25. Rarely commit

Remember: you need to commit often! Well, not every half an hour, but if you have a task to implement the functionality that you write for a week, then it should not be one commit on Friday evening, but, for example, five commits. Almost any large task can be conditionally divided into smaller tasks. And here is the execution of these smaller tasks and you commit. Yes, and do not forget to immediately upload these commits to a remote server. Otherwise, you can commit all week, and for example, on Friday afternoon, something happens to your computer, and that's a whole week down the drain! And if you made commits to a remote server, just pull the branch with the last commit from another computer and continue working. And one more thing: don't upload new features to a live production server on a Friday night. Just believe. You don't need it. This is fraught with that unexpected errors may come out, fixing which you will spend your weekend. And it's not fun. You need to rest on weekends. That, perhaps, is all for today. PS Last advice: write a lot of code. PSS Write CRAZY a lot of code, because this is the only way to gain much-needed experience.