The Risky Game
The Risky Game
Is it worth it to rely on the Junior Development Team? When hiring young devs, you might find there's a learning curve. We discuss how to integrate junior devs into your team.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
How does this effect:
Quality of the code
- The question of money.
Obviously, any company prefers to hire experienced developers into the team. The return from them is better. They offer more reliable and creative solutions that are convenient to scale. The senior developer understands the problems and probably knows how to avoid getting in trouble and minimize the number of bugs. In addition, the code for such developers works 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 double the salary of a beginner. In addition, there are a lot of novice developers, and sometimes one wants to hire one of them.
We at Alconost 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.
The Issues at the Beginning (at Least Some)
The young developer needs a tutor. Not every hired developer will cope with such a task without guidance and clear understanding. Many managers make the same mistake: they recruit many young developers into the same team. They think that if you give the newcomers the guidance of a strong mentor then all their problems are solved. But the mentor is not a magician. Being a mentor is hard work.
Not every developer is suitable to be a mentor. 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 junior team was connected to the team at different times. Creating a team that is overly 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, the nascent projects are busy and only have a few developers assigned to them. Time passes, and - a buoy! - the project has moved to the stable development phase. You invest more and more time and money, you are under pressure from customers, you feel pressure. Then recruiters-technicians are working around the clock to look for new developers. You can not build a team from some beginners - so you have to resort to shuffling. The commands are re-arranged.
So, now there is a lot of work, and you need to manage a lot of developers. Another manager decides: "I'll throw them into it, and let them figure it out." Such a mistake can be fatal, and you will soon find this out. What then? Again, hire someone and shuffle again. People do not like change, especially frequent change. Such measures can really shake up the team members and the team's chemistry. Colleagues must work to feel each other out and know the strengths of their comrades-in-arms.
Any manager who takes a person on the team makes a decision. If the rookie is experienced, the coach often does not need him. Even with a mentor, the experienced developer is usually independent and knows how to learn on their own. When the developer is inexperienced, the mentor will have to be stricter. The mentor still has their main development duties, and now they take on an extra, pedagogical, load. Every hour new questions can come to him. The mentor should not only help the developer solve the emerging problems, but also teach them how to learn. Otherwise, the mentor will not have time to fulfill his/her basic duties.
When a mentor has several mentees, they can become bored or annoyed with their requests for help and have no time for the main job. A good mentor should be patient and able to listen. Long-term mentoring can sometimes be exhausting, and sometimes you might feel a little burned out.
The Burden of Experienced Developers
Not all experienced developers are mentors, and this does not simplify the situation. Naturally, the mentor gets a lower load than the rest. Therefore, a typical manager realizes that if he does not burden the experienced developer with mentoring, he will work more productively.
Make this a rule: when some teammates are busy mentoring the young developers, others must redistribute their load among themselves.
They receive more key tasks and thus allow mentors to teach, and beginners to learn. They are responsible for the progress in product development. Over time, this role can become very burdensome. The manager in charge of the process should not deprive such developers of contact with other team members.
How Does This Affect the Quality of the Code?
The mentor may find it difficult to keep the bar on the quality of their code high if they have several beginners under their mentorship. If you're one of the ones who can, then you are worth a lot.
So, how much does the quality of the code change? Probably quite a bit. The scale varies, as it all depends on how much junior developers are expected to contribute, and the types of training they're given in your company's standards. As a rule, the tutor will say: "There will be refactoring - we will correct your mistakes."
Usually, this is nonsense. For the same reasons, there is usually no refactoring, and the quality of the code in this application becomes the "standard" for the entire project. What is the most convenient way to get sample code? In our application. All the standards of code execution are met there. And, why not? Ctrl + C & Ctrl + V, farewell, programming standards, calls.
The quality of the code has suffered. And what about the fragility? When a newbie writes a block of code, he does not yet know where this code might break. The code is called fragile if bugs easily appear in it. For example, a function does not check the value of the arguments, their type, or the range of validation. This is a simple example. But sometimes it's more difficult 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 complex, and the programmer did not take into account the order of precedence of operations. The editor viewing the code should be aware of such shortcomings and watch them cautiously. Testing the code allows you to radically reduce risks.
Bugs in Code
Each of them is important and plays a role. Whatever it was, everyone once starts with the first step. No senior developer was born an expert.
You cannot bite the hand that feeds you. It should be understood that shaking and shuffling the team is an intervention that can be costly. If you can not do without shuffling, do it no more than at an interval of nine months to a year. Make sure that mentors do not burn out, and the rest of the developers do not work on wear and tear.
A set of young developers is a tactic with many advantages. If it is necessary to arrange mentoring and to choose the appropriate curriculum for your company's junior devs, such work can be very fruitful. A novice developer is easier to form according to his taste than an experienced one.
Beginners also tend to have a higher desire and motivation to spend their own time on pumping-up their skills and building a career.
Opinions expressed by DZone contributors are their own.