Comment aider un débutant en difficulté à mieux faire son travail?

Question

J'ai été le seul développeur et le "développeur senior" de facto sur le produit phare de mon entreprise depuis un certain temps (une application .NET WinForms, mais ce n'est pas lié). Tout récemment, ils ont embauché un nouveau développeur novice avec un diplôme en informatique frais. Aucune expérience en contrôle de source, en tests unitaires, en maintenance logicielle, etc.

Récemment, je lui ai confié un petit morceau de travail et je me suis rendu entièrement disponible pour l'aider, pour constater que sa production laissait vraiment à désirer, tant en termes de vitesse que de qualité. J'ai essayé de ne pas être trop autoritaire, donc la seule orientation initiale que je lui ai donnée est un article de wiki décrivant la tâche que j'ai mis à jour (mais lui non), plusieurs exemples de code sur de nouvelles technologies (comme IPC), et j'ai décomposé les tâches en plusieurs cas FogBugz (auxquels il n'a donné aucun estimé original, temps réel, ou commentaire jusqu'à ce que je lui dise ce que je mettrais). Il posait rarement des questions et, lorsqu'il le faisait, il semblait suivre mes suggestions comme s'il s'agissait de consignes, souvent sans les comprendre et même lorsqu'elles étaient erronées.

Alors... Je comprends parfaitement sa situation où vous ne savez pas quoi faire et avez peur de poser des questions. Je sais que c'est de ma responsabilité de mieux faire mon travail, mais personne ne m'a donné de directives donc je n'ai pas d'expérience de ce à quoi ressemble un meilleur travail. Heureusement, il est en vacances pour une semaine, donc j'ai un peu de temps pour réfléchir à comment améliorer le processus. Voici quelques éléments qui me viennent à l'esprit, mais je suis ouvert aux suggestions et critiques:

1. Demandez quelle partie de la dernière itération a été la plus difficile. Demandez quelle partie a pris beaucoup plus de temps que prévu.
2. Faites du pair programming. J'ai déjà suggéré cela et il semblait ouvert à l'idée, mais chaque fois que nous avons commencé, j'avais tendance à prendre le relais parce qu'il ne tapait pas assez vite. C'est quelque chose sur lequel je dois travailler.
3. Faites une revue de code avant de vérifier le travail. (Nous ne l'avons pas fait cette fois-ci en raison de ses vacances.) La revue de code mettrait en lumière les éléments suivants.
4. Exiger des commentaires sur tous les membres publics. (Aucun de ses codes n'est commenté.)
5. Exigez qu'il supprime tout code inutilisé. (Un examen sommaire montre qu'il ne l'a pas fait.)
6. Exigez qu'il engage du code à chaque cas FogBugz lorsqu'il le termine et/ou révise les cas lorsqu'ils diffèrent de ce qu'il découvre en codant.
7. Exigez qu'il entre des estimations originales dans FogBugz et bascule le drapeau "en cours" pour le maintenir sur la tâche.

Alors que les choses de la revue de code sont spécifiques et techniques, je suis plus préoccupé par sa capacité à être autonome et à demander/obtenir de l'aide là où il en a besoin. Je ne considère pas les exigences de FogBugz (6 et 7) comme des règles strictes, mais il semble qu'il doive les suivre pour rester sur la bonne voie.

Aussi, je sais que je dois améliorer mes compétences en mentorat/formation autant que lui doit améliorer ses compétences en codage. Des suggestions sur par où commencer quand le "développeur senior" n'a pas participé à une revue de code formelle ou n'a pas réussi une séance de pair programming sans prendre le contrôle?

Mon premier réflexe est de mettre à jour ce qu'il a déjà vérifié, mais je sais que je devrais le réserver pour une revue de code. Je voulais qu'il vérifie le travail pour que je puisse commencer à coder la partie qui utilise ce qu'il a vérifié. Donc, devrais-je utiliser ce qu'il a vérifié même si je ne pense pas que cela soit satisfaisant?

Answer 1

Eh bien, vous méritez une médaille pour avoir consacré autant de temps à ce problème.

Je suggérerais ces choses :

1. Faites-lui lire Code Complete.
2. Traitez-le comme un programmeur senior, mais vérifiez chaque étape qu'il fait jusqu'à ce que vous voyiez de bons résultats.
3. Ne prenez pas le dessus sinon il n'apprendra pas. Laissez-le faire des erreurs, puis faites-lui corriger.
4. Il devrait toujours faire des estimations. Ensuite, faites-lui reconnaître quand son estimation est incorrecte.
5. Encouragez-le toujours à penser. Les nouveaux étudiants en informatique pensent rarement; ils codent comme des robots.

Donnez-lui quelques règles de base, comme : ne jamais réécrire le même code, et si vous le faites, vérifiez votre conception, etc.

Rappelez-vous aussi qu'il a peur de vous autant qu'il veut apprendre de vous. Vous avez peut-être oublié des choses qu'il est en train d'apprendre, donc vous devez l'encourager à poser des questions et vous assurer qu'il ne se sente pas stupide de le faire.

Dans six mois, il sera bon et prêt ! (à partir et chercher un travail mieux rémunéré :-) )

Answer 2

Voici quelques conseils sur la manière dont cela se passe au Japon.

Tout d'abord, faites-lui configurer son environnement de travail (donnez-lui une semaine pour le faire), puis dites-lui qui est qui et donnez-lui une liste des adresses e-mail de ses collègues. Une semaine ne le mettra pas sous pression, et il accomplira quelque chose de tangible dans ses 5 premiers jours.

Le premier vendredi, emmenez le nouveau venu avec l'équipe prendre quelques verres, faire du karting, ou aller à Disneyland (à environ une heure de route). Cela dépend de vos goûts et de ce que le nouveau venu préfère. Cela l'aidera à comprendre l'équipe, à les voir interagir à un niveau personnel, et lui fera se sentir comme un membre de la famille. De cette manière, il se sentira beaucoup plus confiant pour approcher les autres pour obtenir de l'aide.

Ensuite, faites-lui faire un peu de codage de base pendant 2 à 3 semaines. Donnez-lui, par exemple, 5 petits exercices par jour lors de sa première semaine. Des choses au niveau de fizz-buzz. Et faites une revue de code à la fin de chaque journée.

Pendant sa 2ème semaine et sa 3ème semaine, faites-lui travailler sur un projet ludique (avec une vraie deadline). Dans le même domaine que son futur travail, mais pas partie du projet réel. De cette manière, il a un bac à sable pour travailler sans craindre de casser le travail des autres. Passez en revue le code avec lui deux fois par semaine. Et demandez-lui de présenter son travail à l'équipe une fois terminé. Cela lui donnera une confiance inestimable.

Maintenant, après ses premières 3 semaines de formation de base, sortez à nouveau prendre des verres ou vous amuser avec l'équipe.

Il a passé le rite d'initiation (très important psychologiquement).

Maintenant mettez-le au travail sur le projet réel, mais donnez-lui une semaine pour lire le code et poser des questions. En milieu de semaine et à la fin de la semaine, organisez des réunions afin qu'il puisse poser des questions à l'équipe, sans avoir l'impression de devoir interrompre qui que ce soit.

Maintenant que vous avez un nouveau venu heureux, curieux et confiant, faites tout ce que tout le monde suggère ici :)

Answer 3

Faites du programme en binôme. J'ai déjà suggéré cela et il semblait ouvert à l'idée, mais chaque fois que nous avons commencé, j'avais tendance à prendre le contrôle parce qu'il ne tapait pas assez vite :

Ce n'est certainement pas correct. Cela ne l'aidera probablement pas à penser qu'il a de l'espace pour apprendre.

Ne faites pas beaucoup de changements à son travail pendant qu'il est absent. Cela le fera se sentir terrible. Au lieu de cela, travaillez sur son optimisation avec lui quand il reviendra (et évitez à tout prix l'envie de prendre le contrôle de la frappe).

Mettez en avant les choses qu'il a bien faites (il vient de faire son premier changement - c'est une énorme réussite qui mérite d'être célébrée), et ce n'est qu'une fois que vous l'avez fait que vous pouvez lui parler de là où il peut s'améliorer, tout en renforçant les points positifs de son changement.

À l'avenir, il pourrait être judicieux de ne pas laisser les gens valider du code qui n'a pas été examiné au préalable (comme vous l'avez mentionné dans votre point 3), et d'autoriser les changements à être validés une fois que tous les problèmes soulignés dans l'examen auront été résolus.

_{Remarque: Je n'ai jamais occupé de poste de direction, donc c'est juste un descriptif de la manière dont j'aimerais que vous abordiez la situation si j'étais l'autre personne.}

Answer 4

Il n'y a pas si longtemps, j'étais un débutant, et je me souviens comment cela se sent et des choses qui m'ont aidé et des choses que je n'appréciais pas trop.

Conseils :

1. Ne le mettez pas sur un projet où il est le seul programmeur sur ce projet. Mettez-le sous la direction d'un développeur principal et assignez-lui de petites tâches qui peuvent être complétées en peu de temps. Il sera plus facile pour lui d'estimer quelque chose qui pourrait prendre 16 heures de travail plutôt que quelque chose qui pourrait prendre 80 heures. En ce moment, il a probablement peur de donner des estimations parce qu'il ne veut pas vous donner une "mauvaise réponse". Il a peur de vous dire 32 heures alors que vous vous attendiez à 8 ou quelque chose comme ça. lol J'avais toujours peur de ça.

2. Passer en revue le code avant de le valider est une bonne chose, mais laissez-le résoudre les problèmes lui-même. Si vous apportez des changements significatifs à son code pour lui, cela peut le faire se sentir mal.

3. Je ne recommanderais pas la programmation en binôme. J'ai toujours voulu résoudre les choses par moi-même pour que quand je réussisse, je reçoive tout le crédit. Mais soyez plutôt disponible pour lui à tout moment pour qu'il puisse poser des questions. Être dans la même pièce que les autres codeurs sur le projet est très important, surtout pour un programmeur débutant. La programmation en binôme peut être bénéfique plus tard, mais en tant que débutant, je préférerais travailler seul.

4. Savoir quand poser des questions est une compétence en soi à mon avis. Vous ne voulez pas harceler le gars derrière vous trop souvent, mais en même temps, vous ne voulez pas passer une demi-journée à chercher sur Google et finir par tourner en rond toute la journée alors que le gars derrière vous connaît immédiatement la réponse. Encouragez-le à trouver des réponses par lui-même, mais ne craignez pas de demander de l'aide s'il ne les trouve pas facilement.

5. Il doit absolument apprendre à commenter le code. Examiner le code des autres lui apprendra l'importance de cela. Il doit apprendre à écrire un "code auto-documenté". Le "Quoi" devrait être documenté automatiquement en utilisant de bons noms de variables et des techniques de codage bien réfléchies et faciles à lire. Parfois, des commentaires sont nécessaires pour expliquer le "Pourquoi" du code est écrit d'une certaine manière.

6. Le fait de lui faire faire des revues de code est une bonne chose. Peut-être que vous faites équipe avec lui et que vous et lui passez en revue le code de quelqu'un d'autre avec lui.

7. Ne prenez pas trop souvent le contrôle du clavier. Pendant une minute, c'est correct, mais s'il va devenir programmeur, il ferait mieux d'apprendre à taper le plus rapidement possible, et la pratique est le seul moyen.

8. Comme quelqu'un l'a mentionné ci-dessus, il appréciera d'entendre qu'il fait du bon travail, alors assurez-vous de lui dire lorsque vous voyez quelque chose qu'il a fait et que vous aimez !

Answer 5

Vous voulez l'amener à vos normes professionnelles? Excellent. Vous devez lui enseigner quelles sont ces normes. D'un point de vue de mentorat, ne lui imposez pas toutes les règles en même temps. Introduisez-en une nouvelle tous les jours. Avec le temps, il y arrivera, ou éloignez-le.

Une chose qui manque dans votre liste est les révisions de code. Oui, vous devriez passer en revue tout son code, mais.... Il devrait également passer en revue tout votre code. De cette façon, l'apprentissage se fait dans les deux sens. Cela le fera se sentir comme faisant partie de l'équipe.