Analysis of typical mistakes of novice programmers: part 1

Hello, world! After you've learned everything you need and finally get hired as an intern or junior, you can probably relax, right? No matter how it is! Everything is just beginning... There is a lot of new and incomprehensible things around you, and how not to screw up like this right out of the gate? That's what we'll talk about today. In this article, I want to look at common mistakes made by beginners and give some tips from my own experience on how to avoid them. So, let's begin without further ado:

1. Fear of asking more experienced colleagues for help

We are all human, and we are all afraid of looking stupid, especially in the eyes of our newly minted, more experienced colleagues. Once they get their first job, developers often give in to this fear and inconsolably withdraw into themselves, trying to figure everything out on their own. At the same time, a person can be surrounded by more experienced colleagues, who, in turn, will be able to initially guide him along the most correct path, which will help to avoid more mistakes and unnecessary “bumps”. Therefore, remember: do not be afraid to ask questions: you are a beginner, and everyone understands this perfectly. When you ask, no one will beat you with sticks. Perhaps it’s even the other way around: you’ll make friends with your colleagues faster and begin to communicate more actively with them. I will say more: the more you ask and discuss various technical issues, the faster you can get out of the shoes of a green beginner and grow into an expert in your field. And one more piece of advice. Don't neglect StackOverFlow . In this context, I mean asking questions on this resource. On the one hand, it takes some time to get an answer to your question. But on the other hand, you may immediately learn about several approaches to solving the current problem and look at it from a slightly different perspective. I would also like to note that writing comments-answers, clarifying questions to questions on StackOverFlow from other developers, in addition to a plus in karma, has a practical benefit: you have the opportunity to discuss and understand this issue more deeply.

2. Don’t try to look for information on your own

Perhaps this error is the reverse side of the previous one. I mean when you start pulling at your colleagues and acquaintances with every problem or problem. Asking is good, but you shouldn’t go too far with questions, otherwise you might just get bored. The first thing to do if some incomprehensible point comes up is to apply your search skills in the best search engine - Google. Someone has already encountered the vast majority of incomprehensible errors and other issues. And you will be pretty surprised if you Google it and see the number of people who are familiar with a similar problem, and who have already received comprehensive answers suitable for use in their work. Based on this, you can often hear a colleague answer a question - “Google it.” You shouldn’t be offended by this answer, because after all, your colleague is not a personal teacher who should convey all the intricacies of your field of work. The endless expanses of the Internet will help you with such mentoring. Sometimes a programmer is also called a person with a black belt in Google search . Therefore, when we get stuck, we first Google the problem, and if no solution was found (rarely, but it happens), then we start asking our colleagues. It is worth asking them right away, not when there is some kind of glitch or incomprehensible error, but when choosing an approach to solve a problem. After all, they can see beyond yours and immediately tell how this or that approach may turn out in the long run.

3. Blind copy-paste

But Googling the problem and, accordingly, its solution has its pitfalls. For example, blind copy-paste . This usually happens when you find a similar problem (but perhaps not exactly the same) and underneath it, for example, on StackOverFlow there is a solution. You take this solution, copy and paste it yourself, without going into too much detail. And then you or your project colleagues discover some strange bugs or incorrect behavior of your functionality. And right away no one has any idea where the legs come from. Then, of course, a place with this code will be found, and you will definitely not be praised for this decision. Therefore, when you find a ready-made solution on StackOverFlow (or somewhere else), first of all you must analyze it in detail, what it is, how and why. Perhaps google this functionality and look at the documentation for it. And only after that implement it into your project.

4. Throwing the wrong solution

When writing a solution, it sometimes happens that it becomes increasingly complex and eventually reaches a dead end. And you are trying to complicate it more and more in order to somehow solve this problem using this approach instead of trying to look for another, more workable alternative. Maybe you simply feel sorry for the energy and time you spent, and so you decide: no matter what, don’t give up, but solve the problem this way. This is not entirely the right approach. At least in programming. The sooner you try a different approach, the more time you'll end up saving. So don't be afraid to experiment and try other approaches, despite the amount of time you've invested in this one. Moreover, these will be points for your experience, since you will try several approaches and better study this area.

5. Fear of asking questions about the current task

Work on a project usually comes down to completing some tasks (Tasks). For example, in Jira . And these tasks are not always described in detail and clearly. They are usually written by team leads, and these are also people, if that happens. They may also forget to add something or not take into account that you are not very familiar with this or that functionality. Well, or you don’t have any access to the project (for example, access to the Database, to the log server, and so on). And now, having received the task, having studied it for more than a couple of hours, you still sit and look at the screen in bewilderment. And instead of continuing to figure this out to no avail, you should start asking leading/clarifying questions to the creator of this task. Let's say, in an application that you use for communication in a team (for example, Microsoft Teams) or directly as a comment under this task. On the one hand, if you write a question in a personal message, most likely the answer will be faster, since the person will see the question right away. On the other hand, by asking a question in Jira, you have evidence that you are doing something, namely, analyzing the problem. There is a way to speed up this process: ask a question as a comment in Jira and send a link to this comment in a private message with a request to look.

6. Expecting too much from the team lead

Again, this is the flip side of the previous point. A team lead is a person who is the head of a development team. As a rule, most of the time of such a team member is spent on various types of communications. And at the same time, he also writes code so as not to forget what it all is. Well, as you understand, this is a very busy character. And excessive twitching for every sneeze obviously will not make him happy. Imagine if every team member bombarded him with a bunch of questions. So you can go crazy, right? And it will not be surprising that with many questions on your part, he will answer you for a long time. What can you do to reduce the number of questions to the team lead:

• Study the documentation of this project more deeply to reduce the number of blind spots.
• Ask questions to other team members. It is quite possible that they are as familiar with this functionality as the lead, or even more, because most likely one of them wrote that functionality.

Alternatively, in the IDE you can look at annotations: who and when last changed the code in a certain line. This way we will find out who would be most correct to ask this question. As you probably already understood, when asking questions to the team leader, as well as when asking questions to colleagues, you need to try to keep the golden mean - not be afraid to ask questions, but also not pester them with an excessive number.

7. Fear of code review

Code review or code review is a stage before uploading code to a common application (to a common branch, for example, master or dev). This check is carried out by a developer who is not related to this task, who can, with a fresh look, discover errors, inaccuracies or shortcomings in the code style that went unnoticed in the initial phase of development. If there are comments, they are left as comments to certain sections of the code. In this case, the developer who performed this task must correct the errors according to the review (or discuss his decisions with the reviewer, perhaps convincing him of the correctness of his decision). Afterwards, send it back for review, and so on until the reviewer has no comments. The reviewer serves as a “filter” before uploading the code. So, many novice programmers perceive code review as criticism and condemnation. They don't appreciate her and are afraid of her, and that's wrong. It is the code review that allows us to improve our code. After all, we receive important information about what we are doing wrong and what we should pay attention to. It is necessary to look at each code review as a part of learning, something that can help you improve. When a person leaves comments on your code, he shares with you his experience, his best practices. As for me, you cannot become a good programmer without getting a code review. Because you don’t even know how good your code is and whether there are any mistakes there from the point of view of an experienced person from the outside.

8. Tendency to abstruse solutions

Often different tasks/problems can have several different solutions. And of all the available solutions, beginners usually use the most complex and “abstruse” ones. And it’s true: if a novice programmer just yesterday studied many different algorithms, patterns, data structures, then his hands are itching to implement one of them. Yes, and I want to, so to speak, declare myself. Believe me, I was like that myself and I know what I’m talking about :) I had a situation where I spent a long time writing one functionality that turned out to be very, very complex. Then it was rewritten by a Senior+ level developer. Of course, I was interested to see what and how he changed it. I looked at his implementation and was amazed at how much simpler it became. And the code has become three times less. And at the same time, tests for this functionality did not change and did not fail! That is, the general logic remains the same. From this I came to the conclusion that: the most ingenious solutions are always simple . After this realization, writing code became much easier, and it became noticeably more high-level. Well then, when is it worth using patterns and algorithms, you ask? Then, when using them will be the simplest and most compact way.

9. The invention of bicycles

This concept is also known as the invention of the wheel. Its essence lies in the fact that the developer implements his own solution to a problem for which solutions already exist, and many times better than those invented by the programmer. As a rule, inventing your own bicycle will lead to a loss of time and a decrease in the efficiency of the developer’s work, because a solution may not be found that is far from the best, or may not be found at all. At the same time, one cannot discard the possibility of an independent decision. The programmer must correctly navigate the tasks that may appear before him in order to solve them competently and in a timely manner, using ready-made solutions or inventing his own. On the one hand, at universities and in courses we are bombarded with various kinds of tasks that should help us get our hands on creating bicycles. But this is only at first glance. In fact, the purpose of this is to develop algorithmic thinking and a deeper mastery of the syntax of the language. And such tasks also help to better understand algorithms/structures, and, if necessary, give them the skills to implement their advanced analogues (but this is very rarely needed). In real life, in the vast majority of cases, there is no need to invent your own wheel, since analogues have long existed that satisfy our needs. Perhaps, due to your experience, you will not know about the existence of the implementations of this or that functionality you need. This is where you need to use the first point of this article, namely, ask for help from more experienced colleagues. They will be able to guide you (for example, advise in which direction to Google) or suggest a specific implementation (certain library).

10. Don't write tests

All beginners don't like writing tests. What about newbies: non-newbies don’t like writing tests either, but they better understand why it’s needed. When you are completely green, you think: why write them? It all works, and there can be no errors. But how can you be sure that your changes don't break something in another part of the system? Your colleagues won't appreciate it if you push through changes that disrupt more than they benefit. This is where tests come to the rescue. The more an application is covered by tests, the better (also called coverage percentage). If the application is well covered by tests, by running them all you may find places that can be broken by your changes. And as I said in the example above, when refactoring the functionality, the tests did not fail, and all because the general logic did not change. This means that tests can also show whether the logic of a certain functionality has changed or not. So even if you don't like writing tests, there are undoubted benefits from them, and they are worth the time spent on them.

11. Excessive commenting

Many developers suffer from perfectionism, and beginners are no exception. But sometimes a side effect of this desire is that they start commenting on everyone and everything. Even what is not needed, because it is so obvious:

Cat cat = new Cat(); // cat Object

Not all novice programmers immediately realize that commenting code is not always a good thing, because the code will turn out to be much more cluttered and difficult to read. What if the code was changed, but there was no comment? It turns out that he will deceive us and only confuse us. Why then such a comment? Usually, well-written code does not need commenting , since everything in it is already obvious and readable. If you write a comment, it means that you have already ruined the readability of the code and are trying to somehow smooth out the situation. The best approach would be to initially write readable code that does not have to be supplemented with comments. I also couldn’t help but mention the correct naming of methods, variables and classes, namely, a rule that I myself adhere to: The best comment is the absence of a comment, and instead of it, the correct naming that clearly describes this or that functionality in your application.

12. Bad naming

Often, beginners falsify the names of classes, variables, methods, etc. For example, when they create a class whose name does not describe its purpose at all. Or a variable is created with a short name, something like x , and when two more variables named n and y are created , it becomes very difficult to remember what x does . In such cases, you have to carefully think about the code and study this functionality under a microscope (perhaps using a debugger) in order to simply understand what is happening there. This is where the correct naming in the code that I mentioned above comes to our aid. Correct names improve the readability of the code, accordingly saving time on familiarization, because it is much easier to use a method in which the name approximately describes its functionality. In code, everything consists of names (variables, methods, classes, file objects, etc.), this point becomes very important when creating correct, clean code. It is worth remembering that the name should convey the meaning: why, for example, the variable exists, what it does and how it is used. And I will note again and again that the best comment for describing a variable is its correct name. For a deeper study of comments and correct naming, I advise you to read the timeless classic: “Clean code. Creation, analysis and refactoring”, Robert Martin . On this note, the first part of this article (reflections) has come to an end. To be continued…