Dangerous game. Is it worth relying on a junior team

How does this affect the team, mentoring, code quality, and also the issue of money

Obviously, any company prefers to hire experienced developers. The returns on them are better. They offer more reliable and creative solutions that are easy to scale. The Zapravsky senior developer understands the problems and, probably, knows how to avoid a mess and minimize the number of bugs. In addition, the code for such developers is faster than for beginners, and they can work independently.

On the other hand, money rules the world, and juniors are much cheaper. The salary of an experienced developer can double the salary of a beginner. In addition, there are many beginning developers, and sometimes you want to hire one of them.

We are at Alconost translated an article on how risky it is to rely on a team of young developers and how such a situation affects experienced developers, mentors and product quality.

Problemable, at least some

A young developer needs a mentor. Not every fired developer will cope with such a task without leadership and a clear understanding. Many managers make the same mistake: they recruit many young developers into one team. They think that if you give beginners to a strong mentor, all problems are resolved. But a mentor is not a magician. Being a mentor is hard work.  

Not every developer is a mentor.As a rule, the average developer should not take on such a mission without practicing mentoring. The abilities of all junior developers are different, and the mentor cannot teach them all at the same time, especially if the juniors joined the team at different times. Creating a team that is excessively tied to many beginning developers can lead to destructive consequences, and managers sometimes miss the moment of truth and do not have time to cope with the situation.

The project requires additional developers - what to do? Shuffle

Usually a few developers are busy with a nascent project. Time passes, and - boom! - The project has moved to sustainable development. More and more time and money is being invested in it, customers are pressing on you, you feel pressure. Then tech recruiters are accepted around the clock to look for new developers. It’s impossible to assemble a team of newcomers alone - so you have to resort to shuffling. Commands are reassigned.

So, now there is a lot of work, it is required to lead many developers. Another manager decides: "I’ll throw them in business, let them come up." Such a mistake can be fatal, and you will soon find out about it. What then? We hire someone again and shuffle again. People do not like changes, especially frequent ones. Such measures can really shake team members. Colleagues must work, feel each other and know the strengths of associates.

Burnout Mentor

Any manager who takes a person to a team makes a decision. If the rookie is experienced, he often does not need a mentor. Even with a mentor, an experienced developer is usually independent and can learn by himself. When the developer is inexperienced, the mentor will have to be tighter. He has the main responsibilities and the load - pedagogical. Every hour he may receive new questions. The mentor should not only help the developer to solve problems, but also teach how to learn. Otherwise, the mentor will not have time to fulfill his basic duties.

When a mentor has several wards, they can bombard him with requests for help and completely leave no time for the main job. A good mentor should be patient and able to listen. Long mentoring is sometimes debilitating, and sometimes burnout is felt.

The burden of experienced developers

Not all experienced developers are mentors, and this does not simplify the situation. Naturally, the mentor receives less load than the rest. Therefore, a typical manager realizes that if you do not burden an experienced developer with mentoring, he will work more productively.  

The iron rule: when part of the teammates are occupied by young animals, others must redistribute their load among themselves. They get more key tasks and thus allow mentors to learn and beginners to learn. They are responsible for product development progress. Over time, such a role can become very burdensome. The process manager should not deprive such developers of contact with other team members.

How does this affect code quality?

A manager cannot keep the bar for code quality if there are four beginners per experienced developer. He is not in strength, and if you are in strength, then you are worth a lot. The company is alive as long as it feeds on money, and when the money runs out - it's all over with it. Everyone - beginners, shelled, experienced developers, and even janitors - go to work because they want to feed their families.

So how much does code quality change? Strong. The scale in this case varies, it all depends on how juniors are forced to be productive, and on the training period. As a rule, the mentor will say: “There will be refactoring - we’ll fix it.”

This is usually nonsense.For these very reasons, no refactoring usually occurs, and the quality of the code in this application becomes the "standard" for the entire project. Where is the most convenient way to get a sample code? In our application. All standards for code design there are met. Prefixes are also right, so why not? Ctrl + C & Ctrl + V, goodbye, programming standards, se la vie.

Fragile code

The quality of the code has been affected. What about fragility? When a beginner writes a block of code, he does not yet know where this code may break. A code is called fragile if bugs easily occur in it. Example: a function does not check the values ​​of arguments, their type or range of validation. This is a simple example. But sometimes it’s harder to catch a bug, for example, if in the JS code the instruction checks for undefined, but not for null, or if the if condition turned out to be complicated, and the programmer did not take into account the precedence order of operations in it. The editor looking at the code should be aware of such flaws and look for them cautiously. Testing the code can dramatically reduce risks.

Our message is DOSE, and carefully.

Beginners, experienced developers, mentors, managers, bugs, clients and money. Each of them is important and plays a role. Be that as it may, everyone once begins with the very first steps. Not a single senior developer was born immediately with sufficient knowledge and experience.

You can’t bite the hand that feeds you. You need to understand that shaking and shuffling a team is an intervention that can be expensive. It is important to know the measure and strictly observe it. If you can’t do without shuffling, get it to happen no more often than with an interval of nine months to a year. Make sure that mentors do not fade, and the rest of the developers do not work hard.

Recruiting young developers is a tactic with many advantages. If you need to properly mentor and choose a suitable curriculum, such work can be very fruitful. It is easier to shape a novice developer to your liking than an experienced one. Beginners know that they are not in great demand. Therefore, they have a higher desire and motivation to spend their own time on pumping skills and building a career.   


About the translator

Translation of the article was done in Alconost.

Alconost localizes games , applications and sites in 68 languages. Native translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.

We also doadvertising and training videos - for sites that sell, image, advertising, training, teasers, explainers, trailers for Google Play and the App Store.

Read more: https://alconost.com