Commençons par éliminer quelques idées fausses
L'intégration d'un développeur junior va demander du travail, à la fois de votre part et de celle de votre équipe. Il est donc déraisonnable de s'attendre à ce que vous fassiez tout tout seul. Mais ne vous inquiétez pas, ce n'est pas parce que vous serez le destinataire de la plupart des enseignements que vous serez le seul à bénéficier de l'interaction. En enseignant, l'enseignant apprend mieux la matière lui-même.
Mais attendez ! Il y a encore mieux ! Même en tant que nouveau membre d'une équipe, vous pouvez avoir un impact positif grâce à quelques actions intelligentes et à valeur ajoutée. Toutes ces actions peuvent être résumées comme suit : Faites d'abord tout ce que vous savez faire. Ensuite, demandez de l'aide.
Vous pouvez explorer ces actions en examinant l'expérience d'intégration d'un développeur junior. Dans ce contexte, vous, l'ingénieur junior, pouvez vous attendre à connaître une partie du travail, mais certainement pas tout. Compte tenu du rôle, on peut raisonnablement supposer que l'objectif de votre embauche est de décharger les autres membres de l'équipe d'une partie du travail de niveau débutant. Alors, comment pouvez-vous, en tant que développeur junior, agir pour atteindre cet objectif le plus rapidement et le plus efficacement possible ?
Votre travail consiste à apprendre !
La réponse la plus courte est la suivante : vous devez apprendre. Vous devez apprendre à connaître les systèmes sur lesquels vous travaillez. Vous devez apprendre des méthodes de travail efficaces. Vous n'avez pas besoin d'un simple guide de réponses. Vous devez acquérir les compétences nécessaires pour vous nourrir.
Et vous devez acquérir la certitude que, tout en faisant tout cela, vous continuez à apporter de la valeur. Ne tombez pas encore dans le piège de vous comparer à vos coéquipiers. Il y aura un moment pour cela, mais ce n'est pas maintenant. Au lieu de vous concentrer sur les différences entre ce que vous pouvez accomplir et ce que les développeurs seniors accomplissent, concentrez-vous sur la question de savoir si vous faites tout ce que vous pouvez faire ou non.
En appliquant la mentalité "faites tout ce que vous savez faire", vous pourriez obtenir un ticket recommandé pour vous. La première étape pour être en mesure d'accomplir le travail est de savoir quoi faire. Pouvez-vous expliquer en anglais ce qu'il faut faire pour réaliser le billet ? Avez-vous besoin de modifier le moment où une fenêtre modale s'ouvre ? Ou ajouter des données à un formulaire ?
Commencez par écrire ce que vous devez faire. Cherchez un moyen de le formuler. Si vous êtes bloqué, vous aurez tout de même apporté une certaine valeur ajoutée. Vous avez réduit le problème à une série d'actions spécifiques. Qui plus est, tout cela est écrit sous une forme transférable !
Ainsi, lorsque le développeur senior vient vous aider, vous pouvez vous assurer que vous les comprenez. Vous n'avez pas laissé le développeur senior deviner où vous en étiez dans le projet ou ce que vous compreniez. Vous avez fourni un point de départ, ce qui est très bien. De plus, vous avez facilité la charge de travail sans écrire une seule ligne de code !
Revenons aux étapes écrites... Si vous êtes sûr que c'est correct et que vous savez comment le mettre en œuvre, essayez-le et écrivez quelques tests ! De cette manière, l'ordinateur aide à confirmer que le code fonctionne comme prévu. Mais veillez à délimiter le travail dans le temps ! Ne partez pas pour quatre heures et ne revenez pas vers le senior pour vérifier. Au lieu de cela, appuyez-vous sur la fonction Inspecter-Adapter de l'approche agile. Essayez d'utiliser un cycle d'itération plus court.
Mettre des "garde-fous" dans votre processus
Je suggère personnellement d'utiliser un Pomodoro comme une bonne structure de travail. Un Pomodoro est un simple minuteur de cuisine. Réglez-le sur 25 minutes pour un travail ciblé toutes les demi-heures et utilisez les 5 minutes restantes pour évaluer ce que vous avez fait ou pour aller chercher de l'eau. Vous pouvez passer une ou deux Pomodoro, pas plus d'une heure, à peaufiner notre solution. Ensuite, faites-la vérifier. De cette façon, vous pouvez faire des progrès, tout en recevant un retour sur votre travail et sur votre orientation de la part du développeur principal.
Imaginons que vous regardiez à nouveau les étapes que vous avez écrites. Plutôt que d'être confiant ou totalement désorienté à ce stade, vous êtes quelque peu sûr que c'est la bonne voie, mais vous ne savez pas comment vous y prendre. Dans ce cas, ne vous empressez pas de demander de l'aide. Prenez plutôt le temps de rechercher la bonne approche. Le simple fait de chercher "comment {faire X}" peut commencer à donner de bons résultats.
Il s'agit là d'une étape cruciale. Ne vous contentez PAS de copier la réponse que vous trouvez dans votre travail. En tant que développeur junior, l'objectif est de commencer à apporter une valeur ajoutée, à la fois dans l'immédiat et à long terme. Pour y parvenir, il faut faire preuve d'un certain degré d'autosuffisance. L'un des objectifs de notre travail doit donc être d'apprendre, et on n'apprend pas si l'on se contente de copier. Prenez donc le temps de comprendre les réponses que vous trouvez. Cela peut signifier avoir recours à StackOverflow dans une fenêtre et l'éditeur dans une autre pendant que vous tapez manuellement une version de la solution que vous examinez.
Là encore, appliquons la technique Pomodoro. Le time-boxing peut apporter une aide itérative. Et vous pouvez améliorer votre travail de manière itérative sans interrompre constamment le développeur senior. Si vous n'avez pas encore eu l'occasion d'essayer la réponse, montrez-la et dites-la. Cela peut montrer à votre développeur principal où vous cherchez des réponses et où il peut mieux vous aider en tant que mentor.
Abordons maintenant la dernière possibilité que vous pourriez rencontrer au cours de vos recherches. Supposons qu'aucune des réponses trouvées sur l'internet ne soit vraiment utile. Elles présentent peut-être des éléments de solution, mais rien qui corresponde directement à votre problème. Cela pourrait signifier que la tactique "Je dois {faire X}" doit être affinée. Il se peut aussi que vous fassiez quelque chose d'unique, et c'est très bien ainsi. Cherchons un moyen de continuer à avancer, avant de courir chercher de l'aide.
Les développeurs de logiciels sont souvent confrontés à des exercices de "pseudo-code" lors des entretiens. Je vous propose d'utiliser cette même technique pour renforcer la tactique du "je dois {faire X}". Dans le cadre d'un flux de travail plus important, il y a de petites étapes.
Considérez par exemple la manière dont vous calculez le prix d'un panier dans une application de commerce électronique. Vous devrez compléter le prix récapitulatif et les taxes dues. Pour calculer le prix récapitulatif, vous devrez peut-être effectuer quelques calculs simples de prix unitaire, puis appliquer des coupons. Pour calculer la taxe, vous devrez peut-être déterminer quels articles sont imposables et quels taux vous devez utiliser. Vous pouvez ensuite calculer la taxe sur chaque article. Mais remarquez ce qui s'est passé ici. Vous avez décomposé le défi ! Vous avez pris le concept "Je veux {faire X}", qui était dans ce cas "Calculer le total du panier", et vous l'avez décomposé en étapes pour y parvenir. Vous avez ensuite examiné ces étapes et les avez décomposées davantage.
Quelques signatures et commentaires simples en pseudo-code pourraient ressembler à ceci :
En décomposant le travail, vous y avez réfléchi. Vous avez ajouté de la valeur, tout comme vous l'avez fait en partageant les premières étapes. Vous avez résumé le travail en disant "Je veux {faire X}". Le membre le plus expérimenté de l'équipe peut maintenant venir examiner le plan de travail. À partir de là, il est facile d'apporter des corrections ou de suggérer des mises en œuvre. Il trouvera peut-être les étapes que vous avez oubliées. Comme nous avons dressé la liste de nos étapes de travail, ils pourront la voir plus facilement ou cela vous permettra de poser des questions plus spécifiques. Et comme d'habitude, fixez des délais. Prenez quelques Pomodoros au maximum pour faire un pas en avant. Ensuite, demandez un retour d'information et de l'aide.
Gardez vos cycles simples. Faites tout ce que vous savez faire, puis demandez de l'aide. Vous ajouterez un peu de valeur à chaque étape. Vous obtiendrez un retour d'information rapide et itératif. Cela vous permet de trouver un équilibre entre la demande d'aide et la réalisation de progrès satisfaisants. En prenant proactivement le temps de passer d'une étape à l'autre, vous renforcez la confiance de votre équipe en vos capacités. Vous obtiendrez également l'aide nécessaire pour progresser sans rester bloqué trop longtemps. En prenant le temps de travailler vous-même sur le problème, vous renforcez votre aptitude à poursuivre votre contribution à long terme. Et qui sait ? À ce rythme, c'est peut-être vous qui dirigerez la prochaine session d'accueil des nouveaux arrivants !
Pour en savoir plus sur Improving et sur nos postes à pourvoir, contactez-nous!
