Recently I've read many articles about how to choose the best junior developers, and how to train them. This is an hot topic for project managers, as they need to have good and cheap developers: usually, this also means "young" developers.
I still haven't found any article, though, approaching this subject from a psychological point of view. Typically, these writings are about technical training, or maybe about how to productively insert a junior resource into a team: but not about how to make the junior motivated to give everything for the project.
I think it's a really different situation from inserting an already expert developer into a team. A young developer still needs to understand almost everything about team work, daily planning, and so on. Sometimes universities don't give them any hint about the situation they'll find in a real work place, so it's time for them to find out. I suggest, let them find out the hard way.
A young developer needs to be involved in all the team activities. He really should be able to write a lot of code, discuss planning, design and so on, since the start of his work in the project. In an agile team, this means that he should write code at least as often as he drives his pair; he should be able to speak while the team writes down user stories, and participate actively to retrospectives.
Don't care too much about the impact this could have on both the developer and your team: in the worst case, you'll have a small loss of productivity, but we'll discuss this in detail later in this article.
I think a good analogy can be done with football. Yeah, I wrote football - after all, it's a team game, where the cohesion between all the team members is important to achieve success.
In a football team, as players get old, young players come in, and they need to be inserted into the first team. This process can be really difficult, no matter how good the young players are: for a coach, leaving the 33 years old world-class striker on the bench and throwing the 17 years old promise on the field, could result in both a success or a failure covered with critics.
However, if you ask any football coach what's the best way for young players to improve, they will answer the same: experience. They need to *play*. A young player, if left on the bench, can not grow, even if he has the chance to train with the best footballers in the world. He needs to feel the adrenaline of important matches, receive the ball and face the toughest opponents.
Going back to our junior developer, it's exactly the same situation. If you want him to improve, you must not leave him on the bench, thinking that time will help him.
Such a cautious and mild approach could result in a demotivated young resource, compromising both his morale and his productivity. Also, you'll need a lot of time to evaluate his real skills.
You should let him code, even if he's half as fast as your other developers, and hear his opinion about the practices of your team. Involve him in all the team activities, and try to teach him what he needs to start working with your team.
Obviously, this can be done only if he has at least some basic skills, but choosing the best young resources is another topic - I won't dwelve into this right now.
Maybe you'll realize he's such a good developer that after some weeks he'll be perfectly inserted in the team, contributing interesting ideas and giving a productivity boost, but even if this takes more time, it's the right thing to do.
Such a steep approach is obviously not productive in the first weeks, but as time goes on, you'll be able to evaluate better not only the technical skills of your junior, but also his resistance to pressure and work load. These characteristics are as important as the technical skills, maybe even more, so finding them out is definitely useful.
Nessun commento:
Posta un commento