Cinq nouveaux développeurs juniors et de nombreuses tâches complexes. Et maintenant?

Notre entreprise a embauché cinq nouveaux développeurs juniors pour m'aider à développer notre produit. Malheureusement, les nouvelles fonctionnalités et les corrections de bogues entrantes nécessitent généralement des connaissances plus approfondies qu'un développeur récemment diplômé (threading / simultanéité, débogage des goulots d'étranglement des performances dans un système complexe, etc.)

Déléguer (et planifier) ​​des tâches qu'ils peuvent (probablement) résoudre, répondre à leurs questions, les encadrer / les gérer, revoir leur code en utilisant tout mon temps et j'ai souvent l'impression que je pourrais résoudre les problèmes moins de temps que l'ensemble du processus de délégation (en comptant seulement mon temps). De plus, je n'ai pas le temps de résoudre les tâches qui nécessitent une connaissance approfondie du système / des compétences plus avancées et il ne semble pas que cela changera dans un avenir proche.

Et maintenant? Que dois-je faire pour utiliser efficacement leur temps et mon temps?

Oui, vous pouvez résoudre les problèmes plus rapidement qu'eux, c'est pourquoi vous êtes senior et ils ne le sont pas. Cependant, un bon senior veut également emmener ses juniors au niveau senior et la seule façon d'y parvenir est de leur laisser apprendre à faire les choses.

Le mentorat est l'utilisation la plus efficace de votre temps en ce moment, pas le codage.

Regardez-le de cette façon, si vous passez le mentorat pendant six mois et que les juniors apprennent suffisamment pour devenir des développeurs intermédiaires - alors vous avez 5 développeurs intermédiaires et un senior. Si vous faites tout le travail vous-même parce que c'est plus rapide, dans six mois, vous aurez toujours 5 juniors qui se tortilleront les pouces peuvent avoir moins de devlopers juniors ou moins) et un senior surmené et grincheux

Vous savez quelles interactions complexes se trouvent généralement dans les bogues, alors développez une formation spécifiquement sur ces types de choses, comment résoudre les problèmes et trouver le problème réel, puis les types de méthodes généralement nécessaires pour les résoudre. Donnez-leur ensuite ces problèmes à mesure qu'ils se présentent. Oui, il faudra plus de temps pour les réparer et vous devez prévoir cela dans vos estimations de temps.

L'idée de programmation en binôme est excellente. Associez-le à un autre pour chaque problème vraiment avancé. Même s'ils ne savent pas encore assez pour résoudre le problème, avoir le junior au clavier pendant que vous leur dites quoi essayer en termes de recherche de la cause aidera à leur apprendre le processus de dépannage. Bien sûr, ne vous attendez pas à ce qu'ils prennent la dictée. expliquez ce que vous voulez qu'ils recherchent et pourquoi. Demandez-leur leurs idées et écoutez-les. Expliquez pourquoi leur idée n'est pas un bon choix si elle ne l'est pas. Utilisez la méthode d'enseignement socratique en posant des questions directrices. Ils se souviendront mieux de la solution qu'ils ont trouvée eux-mêmes à travers vos questions directrices que celle que vous leur avez dictée sans explication. Ils se souviendront également mieux s'ils ont correctement tapé la solution plutôt que de simplement vous regarder la taper.

Une fois que le junior vous a aidé à résoudre une classe particulière de problèmes dans le cadre d'une paire avec vous, vous pouvez le jumeler avec quelqu'un d'autre la prochaine fois que cette classe de problème se présentera et ne sera disponible que pour consulter, sans se tenir debout sur ses épaules pendant ils essaient des choses différentes.

Vous avez cinq nouvelles personnes, ce qui est vraiment difficile. Vous devez être juste envers chacun d'eux et faire pivoter les personnes avec qui vous vous associez ou donner des conseils. Ne jouez pas aux favoris. Mais vous devrez également être une personne qui vous offre un «amour dur» si quelqu'un ne réussit pas et ne progresse pas. Vous devrez peut-être appeler un ou plusieurs d'entre eux de côté et leur dire qu'ils doivent s'améliorer et pourquoi vous pensez qu'ils ne réussissent pas. Si peu de gens vous laisseront faire tout le travail si vous vous associez et si vous le pouvez, ne le permettez pas car c'est plus facile. Si la personne ne peut pas faire le travail, c'est plus gentil avec elle et bien mieux pour votre équipe si vous ne la portez pas une fois qu'il est évident qu'elle ne peut pas ou ne veut pas apprendre à être plus indépendante.

N'oubliez pas que vous obtenez ce que vous attendez. Si vous n'attendez pas grand-chose, vous n'obtiendrez pas grand-chose. Attendez-vous à ce qu'ils brillent et la plupart d'entre eux atteindront votre niveau.

La programmation par paires semble être une excellente possibilité ici.

• Donnez à quatre d'entre eux deux des plus simples de ces bogues, laissez-les se jumeler et demandez à chaque paire de s'attaquer à l'un d'eux.
  • Formulez cette demande comme: "Pouvez-vous comprendre ce qui cause cela?". Ne leur demandez pas de commencer à réfléchir à la façon de le réparer.
  • Une fois qu'ils ont un certain niveau d'une explication, puis leur demander comment il pourrait être fixé. De cette façon, ils ne seront pas aussi submergés par une énorme tâche à la fois. Laissez-les aller expérimenter le code s'ils ne l'ont pas déjà fait, et une fois qu'ils auront un plan - même vague - vous pourrez les guider vers une bonne solution.
• L'autre, vous pouvez l'appairer et commencer à travailler sur l'un des plus difficiles avec lui. Cela peut être plus difficile compte tenu de son inexpérience avec le code, mais il bénéficiera également d'une personne ayant de l'expérience avec lui.
  • Je pense qu'une nouvelle fonctionnalité pourrait être un bon moyen de le faire, compte tenu de votre expérience. Vous pouvez lui montrer l'API existante au fur et à mesure du développement de la nouvelle fonctionnalité.

Pour une anecdote / un exemple de cette suggestion qui fonctionne: C'est ainsi que j'ai été présenté à la partie la plus velue de la base de code sur laquelle je travaille - avec l'autre développeur relativement nouveau avec lequel j'ai été associé, nous avons fini par faire quelque chose comme ceci:

• On nous a donné un bug, et après environ 10 minutes d'introduction, on nous a dit d'essayer de comprendre ce qui se passait.
• Environ une heure plus tard, nous nous sommes séparés et avons creusé en deux courants de pensée différents.
• Environ deux heures après cela, j'ai compris en général comment le code fonctionnait, mais je ne savais pas exactement où la mauvaise sortie était générée. Il a compris comment il était généré, en fouillant dans les données brutes et dénormalisées, mais n'a pas pu comprendre le code.
• Nous nous sommes appariés et avons suivi les chemins de code ensemble, et nous avons obtenu une réponse exacte. À partir de cela, nous avons réfléchi avec notre responsable à quelques solutions possibles et nous avons fini par l'implémenter plus tard.

J'ai depuis hérité de la maintenance de toute cette partie de la base de code, car je suis vraiment le seul à comprendre comment cela fonctionne (les développeurs originaux qui sont toujours là ne s'en souviennent même pas complètement).

Leur apprendre. Attribuez-leur des tâches qu'ils peuvent facilement résoudre.

En termes simples, le problème est que ladite main-d'œuvre n'est pas suffisamment qualifiée pour être très productive avec la tâche qu'elle a. En tant que tel, vous pouvez soit 1) faciliter la tâche 2) essayer d'augmenter les compétences de la main-d'œuvre.

Un problème similaire se produit presque toujours (dans une certaine mesure) chaque fois qu'une nouvelle personne rejoint une équipe et commence à travailler sur une base de code dont elle n'a aucune expérience. Cela devient plus problématique si les outils et les méthodologies sont inconnus. En entraînant la personne à se familiariser avec les outils et les méthodologies, le problème peut être atténué plus rapidement.

Cependant, résoudre un tel problème prend du temps - on ne peut pas s'attendre à ce que les autres sachent tout ou apprennent tout en un seul instant. Peut-être que l'introduction de quelques livres sur la concurrence, l'optimisation logicielle et les méthodologies générales nécessaires serait un bon début.

Il semble que vous n'ayez pas participé à la décision d'embauche. Faites une évaluation juste de leurs capacités à gérer les tâches en cours. Notez un rapport avec une recommandation (formation externe et tâches de ce type tant que cela n'affecte pas votre délai de livraison), envoyez le rapport à votre responsable qui peut commencer à parler à la personne qui a engagé ces gars. Une nouvelle personne peut être absorbée dans une équipe, mais 5 nouvelles personnes à la fois, cela ne semble pas bon sauf si vous avez un magasin détendu. Quoi que vous fassiez, n'essayez pas de leur enseigner le temps de votre projet, sauf si cela est pris en compte dans le plan.

Edit: Il peut être approprié de mentionner la loi de Brook dans cette situation.

Vous pouvez peut-être passer du temps à créer un environnement de bac à sable où vous pouvez les jeter pour résoudre certains des problèmes difficiles sans faire de mal. Demandez-leur de tester leurs solutions aussi complètement que possible. Mettez plus d'un sur le même problème.

Toutes ces choses leur donnent la possibilité d'acquérir les compétences nécessaires pour être utiles, et elles nécessitent moins de temps. Bien sûr, si vous les avez (la plupart du temps) couler ou nager et qu'ils coulent à peu près, vous devez repenser les choses.

Dans la profession de programmeur, les gens qui ne peuvent pas apprendre la plupart du temps par eux-mêmes ne valent probablement pas vraiment l'effort qu'il faudrait pour leur enseigner. Mais je pense qu'ils vous surprendront probablement le plus souvent à quel point ils s'entendent lorsque vous réduisez l'aide.