Dangerous game. Should I rely on a team of juniors

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

Obviously, any company prefers to take in a team of experienced developers. Recoil from them is better. They offer more reliable and creative solutions that are convenient to scale. A real senior-developer understands the problem and, probably, knows how to be in a mess and minimize the number of bugs. In addition, the code for such developers is faster than for beginners, and they know how to work independently.

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

We in Alconost have translated an article about how risky it is to rely on a team of young developers and how this situation affects experienced developers, mentors, and product quality.

Problems, at least some

A young developer needs a mentor. Not every fired developer will cope with such a task without guidance and clear understanding. Many managers make the same mistake: they recruit a lot of young developers into one team. They think that if you give newcomers into submission to a strong mentor, all problems are solved. But a mentor is not a wizard. To be a mentor is hard work.
')
Not every developer is suitable for mentors. As a rule, the average developer should not undertake such a mission without training in mentoring. The abilities of all junior developers are different, and the mentor cannot teach them all at the same time, especially if the juniors were connected to the team at different times. Creating a team that is excessively tied to a lot of novice 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 on the nascent project busy few developers. Time passes, and - buum! - The project has moved to a stable development. More and more time and money is invested in it, customers are pressing on you, pressure is felt. Then techie recruiters are taken around the clock to look for new developers. You can not build a team of some newcomers - so you have to resort to shuffling. Commands are rebuilt.

So, now a lot of work, you need to lead a lot of developers. Another manager decides: "I will throw them into the business, let them swim out." Such an error can be fatal, and you will soon find out. What then? Hiring someone again and shuffling again. People do not like change, especially - frequent. Such measures can really shake team members. Colleagues should work, feel each other and know the strengths of the teammates.

Burnout mentor

Any manager who takes a person to the team makes a decision. If the recruit is experienced, a mentor is often not required. 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 basic duties and load - pedagogical. Every hour he may receive new questions. A mentor should not only help the developer solve problems that arise, but also teach how to learn. Otherwise, the mentor will not have time to perform their basic duties.

When a mentor has several wards, they can fall asleep to him for help and leave no time for the main work at all. A good mentor must be patient and listen. Long-term mentoring is sometimes debilitating, and burnout is sometimes felt.

Burden of experienced developers

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

The iron rule is that when some of the teammates are occupied by youngsters, others must redistribute their workload between them. They get more key tasks and thus allow mentors to learn, and newcomers to learn. They are responsible for the progress in product development. Over time, such a role can become very burdensome. The manager leading the process should not deprive such developers of contact with other members of the team.

How does this affect the quality of the code?

The manager can not keep the bar on the quality of the code, if there are four beginners for one experienced developer. He is not strong, and if you are strong, then you stand dear. The company is alive, while fueled by money, and when the money dries out - it's all over with her. All - beginners, fired, experienced developers and even cleaners - go to work because they want to feed the family.

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

Usually this is nonsense. For the same 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 own application. All code design standards are met there. Prefixes, too, as it should, so why not? Ctrl + C & Ctrl + V, farewell programming standards, ce la vie.

Fragile code

The quality of the code has suffered. What about fragility? When a novice writes a block of code, he still does not know where this code may break. The code is called fragile if bugs arise easily in it. Example: the function does not check the values ​​of the arguments, their type or validation range. This is a simple example. But sometimes it is more difficult to catch a bug, for example, if the JS code checks the instruction for undefined, but not for null, or if the if condition is complicated and the programmer did not take into account the order of precedence of operations. The editor viewing the code should be aware of such flaws and be wary of looking for them. Testing the code allows you to drastically reduce risks.

Our message - DOSING, and neatly.

Newbies, experienced developers, mentors, managers, bugs, clients and money. Each of them is important and plays its role. Anyway, everybody starts from the very first steps. No senior developer was born immediately with sufficient knowledge and experience.

You can not bite the hand that feeds you. It must be understood that shaking up and reshuffling a team is an intervention that can be costly. It is important to know the measure and strictly observe it. If you can’t do without shuffling, make sure that it doesn’t occur more often than at intervals of nine months to a year. Make sure that the mentors do not fade, and the rest of the developers are not working on wear.

Recruitment of young developers is a tactic with many advantages. If how to establish mentoring and choose the appropriate curriculum, such work can be very fruitful. A novice developer is easier to shape 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 time on leveling up their skills and building a career.


About the translator

The article is translated in Alconost.

Alconost is engaged in the localization of games , applications and sites in 68 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.

We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

Read more: https://alconost.com