L’encadrement de juniors (stagiaires et jeunes diplômés) est un sujet assez vaste, et je vais juste aborder ici un point de détail qui concerne la manière dont les entreprises abordent leur productivité.

Il existe un principe de base qui est valable pour tout le monde :
« Comprendre ce qu’on fait et ce sur quoi on travaille »

Quand on embauche une personne qui a de l’expérience, c’est souvent pour la faire travailler sur des projets assez pointus. Dans ce cas, on s’attend communément à ce que la complexité de la tâche implique un « temps de démarrage » conséquent.

Il est assez logique que les juniors, pour leur part, se voient affecter des tâches plus accessibles d’un point de vue technique. Mais de nombreuses personnes voudraient qu’un junior soit immédiatement opérationnel. La réflexion qui est faite est du style : « Ce n’est pas bien compliqué, franchement, il devrait avoir terminé dans 2 jours, non ? ».
Le problème, c’est que n’importe quel travail doit se faire en ayant une maîtrise de son environnement et de ses impacts potentiels.

On ne peut pas demander à un jeune embauché de faire du bon boulot, si on n’a pas pris le temps de le former correctement sur les méthodes et outils spécifiques employés dans l’entreprise. Même si le travail demandé semble mineur, il faut se souvenir que l’expérience du collaborateur est limitée elle aussi. Un défaut d’encadrement peut conduire à des situations désagréables. La plus commune est que le junior, après avoir travaillé 3 jours sans avoir reçu de formation interne, doit recommencer tout le travail parce qu’il n’a pas respecté les directives qu’il n’a pourtant pas eues. On voit aussi fréquemment des personnes qui commencent à modifier du code sans le comprendre, générant un nombre incroyable de bugs de régression.

La pire situation que j’ai vue, c’est une entreprise qui formait ses jeunes « à la dure » : aucune formation, directement affectés aux débuggages ! Autant vous dire que ce n’était pas très efficace…

Si vous encadrez un junior

Vous devez lui fournir toutes les informations nécessaires. On ne laisse pas les gens se débrouiller tous seuls ; cela revient à les laisser dans la merde. Prenez le temps d’expliquer les méthodes, outils et usages qui ont cours dans votre entreprise. Faites leur faire un premier projet pour se faire la main, sur lequel vous les encadrerez de très près.

Ce n’est qu’une fois que vous serez certain qu’ils savent ce qu’ils font que vous pourrez leur donner des tâches plus importantes.

L’important n’est pas qu’ils puissent développer rapidement une fonctionnalité dès leur première semaine. L’important, c’est qu’ils comprennent l’environnement technique, les méthodes et outils de votre entreprise, pour qu’ils puissent par la suite travailler efficacement.

Si vous êtes un junior

Il est de votre devoir de comprendre ce que vous faites. Si à un moment vous vous retrouvez à modifier des choses sans vraiment savoir ce que vous faites, vous devez vous arrêter immédiatement. Prenez le temps d’assimiler les choses. Demandez de l’aide si vous avez l’impression de ne pas en voir le bout.

Peut-être avez-vous envie d’effacer un gros pavé de code qui vous semble inutile ou mal écrit ? Mais avez-vous songé que ce code abscons est nécessaire pour corriger un bug très bizarre et pas évident à comprendre ?
Vous avez un petit bug, qui semble pouvoir être résolu en incrémentant simplement une variable ? Mais si vous ne maîtrisez pas les impacts de cette incrémentation, qu’est-ce qui risque de ce passer sur le reste du code qui utilise cette variable ?
Vous ne savez pas comment l’entreprise gère sa documentation, alors vous ne la consultez pas (et ne risquez pas de l’enrichir) ? Eh, ça serait sûrement plus efficace de demander à se faire expliquer les choses, non ?