The Risky Game of Relying on a Junior Developers Team

The influence on the team, mentors, code quality and money

This article originally appeared on dormoshe.ioThis article was translated to Russian by habrahabr.

It’s obvious that a company prefers to recruit experienced developers. Their output is better. The solutions that they select are more robust, creative and scalable. The medium-senior developer understands the problems, and probably, knows how to avoid traps and how to minimize the number of bugs. Besides, these developers code is faster than junior developers, and they work independently.

On the other hand, money is the crucial resource in our world, and junior developers are cheaper significantly. The salary of an experienced developer can be double than the junior. In addition, there are a lot of junior developers, and it can be tempting to recruit the junior one.

In this article, we discuss the risky game of relying on a junior developers team, the influence of this situation about the experienced developers, the mentors, the product quality and more related stuff.

The problemssss or at least some of them…

A junior developer needs a mentor. Not every medium developer can do this mission without guide and intention. Many managers fall into the trap of recruiting of many junior developers to the same team. They think that if you put the juniors with a strong mentor, all the world problems will be solved. A mentor is not a magician. Mentorship is a hard mission.

Not every developer was born to be a mentor

Most of the time, the medium developer should not do this mission without training. Junior developers have different levels of abilities, and the mentor can’t always learn them together, all the more so, when the developers recruited in a different time. Building a team that is relying on too many juniors can be destructive, and sometimes managers failed to catch it in the right moment and handle it.

The project needs more developers — then what? Shuffling

As usual, many projects start with a small number of developers. The time passed and boooom! — The project is in the right way. A lot of money and resources are invested, the customers knock on the company doors, and the pressure is felt. Then, the technical recruiters work around the clock to find new developers. The manager can’t build a team only from juniors, so shuffling is in the picture. The teams are re-build.

Caution: dizziness

Now, there is a lot of work and many developers to guide. Some of the managers decide to let them dive deep into the water. This can be a fatal error, and it will be discovered quickly. It can happen after some months that the project should grow again. Then what? Recruiting and shuffling again. People don’t like changes and don’t like it frequently. It can be a real shake to the personas in the teams. They need to learn how to work together personally and what is the strong points of each other.

The grinding of the mentors

Each manager that accepts an employee to the team make a decision. When the employee is experienced, a mentor is not often needed. Even when there is a mentor, mostly, the experienced developer is independent and autodidact. When the developer is junior, the mentor has more work to do. He has his regular tasks and the mentoring tasks. Questions can be landed on his desk every hour. The mentor should help the developer not only to solve his problems but also to learn how to learn. Otherwise, the mentor can’t does his regular working routine.

When the mentor has more than one trainee, the asks to help can leave him without an ability to work on his missions. A good mentorship requires listening and patience. It’s not easy to do, and there is side-effect on the mentor. Mentorship for a long time can be exhaustive, and sometimes the grinding is felt.

The burden of the experienced developers

Not all the experienced developers are mentors, and it doesn’t help the situation to be more convenient. It’s clear that a mentor gets fewer tasks than the others. So, the average manager expects that an experienced developer that isn’t a mentor will be more productive.

Rule of thumb, when the mentors busy with the juniors, the others need to balance the equation

They get more core tasks and be the part that allowing the mentors to mentors and the juniors to study. They are responsible for the progress of the product. It can be a very burden to be such a developer over time. The focus of the manager in the guiding process should not distract them from seeing the other team members.

The effect on the code quality

A manager can’t save the code quality when the ratio of experienced developers to juniors is 1:4. He can’t, and if you can, you are something special. Companies are live thanks to the presence of money, and when money stops to come, it’s done. The juniors, mediums, experienced developers, and the cleaners, they all come to work because they need to feed their children.

So, how much the code quality influenced? A lot. It can be on a varied scale, that depends on the pressure to be productive and the study period. In most of the case, the mentor will say ‘it will be improved in a future refactoring.’

It’s mostly a bullshit

For the same reasons, mostly, the refactoring will not come, and the code quality of the application becomes the standard of the project. Where is the best place to get a code example for something? In the same application. It’s following the code conventions. The styles are there. The name prefixes are the same, so why not? Ctrl+C & Ctrl+V and goodbye to the coding standard and C’est la vie.

C’est la vie. Gemma Correll

Brittleness Code

The code quality is injured. What about the brittleness? When the junior writes a code block, he doesn’t know yet where the code can be broken. Brittleness code is where a bug can appear quickly. An example of this situation is when the function doesn’t check the arguments values, their type or range of validation. This is the easy one. It can be harder to found when, for example, the if statement checks for undefined and not for a null value in JS or the if condition is complex without paying attention to operators precedence order. The code reviewer should be suspicious and aware of this weakness. Testing of the code can minimize the risk dramatically.

The message is - DOSE and do it carefully

Juniors, experienced developers, mentors, managers, bugs, quality, brittleness, customers, and money. All of them are important and parts of the scene. There are a lot of drawbacks, but everyone starts as a junior in his baby steps. No senior developer was born with the knowledge and the experience.

We can’t bite the hand that feeds us

We need to understand that this shuffling and shakes to the team are not natural and that it cost, sometimes a lot. You need to dose and do it carefully. If shuffling is necessary, be sure that they won’t happened less than nine months or one year one after the another. Be sure that your mentors are not grinding and the other developers are not exhaustive.

There is a lot of advantages in a junior developer recruitment. With the appropriate mentorship and the right study plan, you can find a lot of benefits. It’s easier to shape a developer in his baby steps than an experienced developer. They know that they are less attractive. Therefore they have more drive and willingness to invest time in order to improve their abilities and build their career.

You can follow me on Medium or Twitter to read more about Angular and JavaScript.