Typical mistakes of junior developers

We learned from middle and senior programmers what mistakes juniors most often make. They were also asked to tell us how these mistakes can be avoided. Here’s what they said.

***

We remind you that you can ask your question to the experts, and we will collect answers to it if it turns out to be interesting. Questions that have already been asked can be found in the list of issues in the section.

If you want to join the ranks of experts and send an answer from your company or yourself, then write to experts@tproger.ru, we will tell you how to do this.

***Yulia Rumyantseva

Head of Web Development Department, Alfa-Leasing Group

Junior developers pay little attention to the names of methods and variables. They often come up with a name for a function that does not reflect its purpose, and in the end they themselves get confused about what they wrote.

Errors can be associated with the invention of the “bicycle”, when instead of ready-made code, developers write their own. Or the other extreme is using ready-made libraries without understanding the logic of their work. There are mistakes due to carelessness and haste. To avoid shortcomings, you can give the code to senior colleagues for review, discuss implementation plans before the start of development, don’t panic and don’t rush.

Typically, junior professionals are not involved in application architecture design. But if this does happen, it’s better to take a look at how everything works in successful projects (open source and those used in the company) and be sure to consult with your mentor.

Typical mistakes that novice developers make when working with Git are violations of the branching and merging methodology. You should definitely follow the standards and regulations in your team and never use the –force attribute when publishing.

If this problem is systemic, it is recommended to study the spiral development model and strive to implement it into the process and define clear acceptance criteria at the input (Defenition of Done).

If this is a personal problem for the developer, then you can try yourself in TDD, clarify the acceptance criteria, or transfer tasks for improving the code to technical debt. Well, we remember that perfection is achieved not when there is nothing to add, but when there is nothing to remove.

Even neutral words can leave an unpleasant aftertaste if we do not know how to respond correctly to comments addressed to us. You need to learn to separate constructive criticism from subjective assessments. A useful book recommendation on this topic is “Thanks for the Feedback” by D. Stone and S. Heen.

To avoid problems with application performance, it is recommended to use microservice architecture, library code, development patterns – these are things that can be included in the application at the initial stage.

It is important to learn the basic principles of programming. Good code is not just something that works, but one that is also maintainable and adapts to change. By ignoring basic programming principles, developers make the code unpredictable and reduce the quality of the final product.

The easiest way to stay motivated and develop is to start looking at mistakes as opportunities. Opportunities for growth and development. Go to Fails Night, where seniors share their work failures, maybe it will inspire you!

Denis Bazarnov

Leading Consultant, DS Services Department

The term “complexity” is more appropriate than “misunderstanding.” The difficulty is caused by the fact that when learning any programming language (hereinafter – PL), a beginner mainly studies the implementation of simple mathematical problems or classification methods. In practice, PL is a universal tool that is used every day. And the spectrum of daily solved problems may not include mathematics or classification methods or algorithmic problems. And the junior gets the wrong impression in the spirit of “they taught one thing, but they have to do something completely different.”

To answer briefly: 10 years ago the most common errors were syntax errors. A newbie would come with a typical question: “Listen, my compiler/interpreter is complaining, I’ve tried everything, but I don’t understand what it wants.” Now that AI can already write simple code, when IDEs are more advanced, most errors are logical. And it will not be possible to avoid them until the developer clearly understands “how it works now and how it should be.”

Problems with algorithms are rare. The most common problems are with describing the required data structures using the types of a specific language.

The most common mistake is merge conflicts. And most mistakes begin with conflict. The best practice is to have your own git methodology (see git flow).

If you don’t pay enough attention to code reviews, you can easily slide into a situation where newbies rewrite their code several times and still don’t pass code reviews. And the opposite situation is when newcomers unite in groups, comradely approve each other’s pull requests, and as a result: low-quality code. Therefore, rules are more often introduced, for example: comments on code reviews must be justified (with a link to the section, for example), mild (without insults), but mandatory. And, of course, any newbie code should be reviewed by at least one more experienced colleague.

An analogy is appropriate here: can a person without appropriate education build a small country house? Maybe. But can this same person build a skyscraper given all the resources? No. Even if there is a verified design of the building, a person without education is unlikely to be able to fully read and understand it. At the same time, our universities do not teach children how to design and build skyscrapers exclusively. It’s the same story with programming: can a beginner make a minimal application based on examples from the Internet? Yes, sure. But when it comes to large-scale projects, his knowledge will clearly not be enough.

You will be surprised, but I believe that the problem of motivation is rooted in the question: “How to get into IT?” From my observations: for most beginners, especially those aged 30 years and older, the motivation is primarily financial in nature and sometimes sounds drastic, for example, like this: “It doesn’t matter what I do, but what matters is what I get for it.” they will pay well.” And what do we have after 3-6 months? A person receives a tangible income, basic needs are satisfied, and it’s time for such internal questions as “Is this mine? Do I like doing this? Well, since such questions arise, the answer is obvious. And that’s it – hello burnout. What can you recommend? Do not stop. And if you haven’t started yet, then start choosing your specialization. Our industry is very broad, almost everyone can find their own direction and activity that they like to do.

***

We remind you that you can ask your question to the experts, and we will collect answers to it if it turns out to be interesting. Questions that have already been asked can be found in the list of issues in the section.

If you want to join the ranks of experts and send an answer from your company or yourself, then write to experts@tproger.ru, we will tell you how to do this.