Comment encadrer un programmeur junior [fermé]
quelqu'un a-t-il des suggestions sur la façon d'encadrer un programmeur débutant ? Si vous avez été le mentor de quelqu'un, Avez-vous suivi un processus quelconque ou était-ce assez informel ?
si vous avez été encadré dans le passé, quel genre de choses Avez-vous trouvé le plus utile ?
12 réponses
essayez de réserver entre 30-60 minutes par jour pour revoir leur code ensemble. Si vous ne pouvez pas faire cela, alors essayez de vous réunir pour revoir leur code à chaque fois qu'ils font une commit de code, à moins que ce ne soit très basique. Demandez-leur d'expliquer pourquoi ils ont choisi l'approche qu'ils ont pris à la place des autres. Un tel processus permet d'établir une excellente relation, ainsi que de vraiment stimuler les étudiants à réfléchir sur leur propre et être en mesure de défendre leurs décisions. Non seulement l'étudiant jusqu'à la fin avec quelqu'un accessible à qui ils peuvent faire confiance, mais vous remarquerez une amélioration de leur qualité de code et de logique presque immédiatement.
Modifier: aussi, si vous n'êtes pas en mesure de consacrer autant de temps à co-examiner avec votre subalterne, alors vous ne devriez probablement pas les encadrer et plutôt voir si quelqu'un d'autre a un horaire qui le permettrait. Le but du mentorat est de contribuer activement au développement professionnel de l'étudiant, et il n'apprendra pas grand-chose s'il est approprié on ne leur prête pas attention et on ne les guide pas.
j'ai eu la chance de travailler comme stagiaire (l'un des deux) dans une petite entreprise de logiciels et j'ai eu l'occasion de travailler sur un projet "presque Nouveau" qu'ils avaient. Ils m'ont mis en place avec tout le nécessaire et m'ont donné une introduction dans ce que le projet était réellement (des choses de base comme ce que les exigences étaient, etc).
au début, nous avons dû faire des tâches mineures comme faire des recherches sur des choses qui comptaient pour le projet (ils nous avaient donné une liste de sujets). C'était, je pense, pour voir combien nous pourrions gérer nous-mêmes, comme les choses que nous avons besoin de regarder et de recherche n'étaient pas anodin et il a pris un bon 2 semaines (en comptant la base démos que nous avons eu à le créer pour elle). Cette phase de test s'est en fait déroulée sans beaucoup de "coaching".
cependant, après cette période, Nous pourrions travailler sur le projet lui-même. C'est aussi à ce moment que nous avons commencé à être coachés ensemble, dans un style similaire à programmation de paires, sauf qu'on était trois (2 stagiaires et 1 coach).
nous avons beaucoup appris de lui, mais c'était d'une manière informelle, et il n'a pas agi comme le gars "tout-savoir-écouter-moi". Lorsque nous avions des suggestions, il écoutait et réfléchissait avec nous pour savoir si elles étaient bonnes. ou donner son avis sur les raisons pour lesquelles une idée ne devrait pas être faite de cette façon... Maintenant que j'y pense, il nous a activement encouragés à faire des suggestions, et à réfléchir à de meilleures façons de faire les choses, au lieu de rester assis là à "recevoir des ordres" de quelqu'un qui il sait quoi faire de mieux que toi.
Donc en bref:
- laissez le programmeur junior travailler (principalement) seul pour étudier les matériaux disponibles, lui donner une liste de petites choses à faire comme chercher de l'information, ou construire de petites démos.
- Vérifier le travail qu'il a fait régulièrement et de lui indiquer s'il existe de meilleures façons de faire les choses. Faites aussi remarquer les articles qu'il a bien faits, de cette façon il se souviendra de ceux pour plus tard.
- le laisser travailler sur un il travaille dans le cadre du même projet et lui donne des conseils lorsqu'il a des questions.
- l'effort doit venir des deux côtés: l'encourager à poser des questions, à remettre en question "la façon dont il est fait actuellement". Posez-lui des questions sur la façon dont il pense que cela devrait être fait et donnez-lui aussi votre avis.
- faites en sorte que cela soit "agréable" - ne laissez pas croire que vous donnez des ordres.
pendant un stage dans une grande entreprise qui avait beaucoup de TI à l'interne, j'ai été jumelé avec un mentor. Cette pratique a certainement contribué à mon perfectionnement professionnel, tant sur le plan des compétences techniques que des compétences en affaires. Voici certaines des raisons pour lesquelles le mentorat travaillé si bien:
- Crédibles: le mentor avait plus de 8 ans d'expérience et un bagage accompli sur lequel s'appuyer pour diriger et former. Il avait traversé différents défis, travaillé dans différents environnement, donc il avait une grande perspective.
- Authentique: le mentorat a été encouragé par le superviseur, mais il n'était pas si formel qu'il en faisait un exercice pour passer à travers les motions. Le mentor voulait être mentor, et je voulais que quelqu'un apprenne.
- Passion: le mentor aimait le domaine dans lequel il se trouvait, les problèmes qu'il résolvait et les technologies qu'il utilisait. Quand je suis venu sous son aile, j'ai trouvé que c'était infectieux.
- Sharp et d'Articuler: le mentor a abordé les questions de façon critique et les a formulées de façon concise. Il n'y avait pas beaucoup de flou dans nos discussions; nous sommes arrivés à la racine de la question et il m'a dirigé sur des pistes sages de résolution de problèmes et d'action.
- significatif: le travail que je faisais avec le mentor était un travail significatif, pas seulement un exercice pour m'occuper ou m'améliorer dans un ensemble de compétences. En travaillant ensemble sur une tâche qui a l'organisation, qui a aidé à cibler mon intérêt et à légitimer le processus de mentorat.
à mon premier emploi, il y avait vraiment ceci patient dude qui m'aidait toujours à résoudre mon problème immédiat, et ensuite m'enseignait un principe sous-jacent important. J'ai aimé cela parce qu'il m'aiderait à rester productif tout en m'enseignant comment devenir un meilleur programmeur.
je serais le junior, je suppose :) je pense que j'apprécierais une approche informelle. Cela dépend probablement beaucoup de vos personnages et de ceux de votre filleul, mais je dirais que vous apprenez mieux si vous n'avez pas d'ego sur votre chemin. Briser la glace, assurez-vous de laisser des commentaires les directions. Des choses comme la révision de code (dans les deux sens?) et la programmation par paire occasionnelle peut fonctionner, et s'il ya un bon match, il peut être beaucoup de plaisir, ainsi!
parce que je devais expliquer pourquoi
j'ai apprennent mieux par la lecture de livres, donc après gloussant sur Unix pour les Nuls (yay!!! Je n'étais pas le seul à pensé que c'était obscure et knuckleheaded parfois) j'ai commencé avec Unix en un Mot et Sobell Guide Pratique des commandes Linux. Après cela, j'ai imprimé la documentation Vim et j'ai commencé à la parcourir. Puis j'ai regardé quelques livres sur Python, le langage de mon premier projet. On m'a donné tout le temps dont j'avais besoin pour me sentir à l'aise à propos de ces choses (ce qui était le vrai problème, comme je le comprends maintenant) et j'ai ensuite commencé à ajouter de la fonctionnalité à un projet antérieur d'une coopérative. je me rends compte maintenant qu'il aurait été formidable de rencontrer quelqu'un tous les jours ou deux pour une révision du code, comme L'a dit Kamikaze Mercenary.
voici ma courte liste:
programmation par paires - c'est utile pour beaucoup de choses, comme le renforcement de diverses idées et pratiques. S'habituer à Resharper est beaucoup plus facile quand vous jumelez avec quelqu'un qui l'utilise souvent.
conversations Informelles - où voulons-nous aller boire un verre, aller à l'extérieur pour quelqu'un d'avoir une pause cigarette, aller déjeuner ensemble, etc. En dehors des bureaux, la discussion peut être liée au travail effectué immédiatement ou elle peut être résumé philosophique de trucs qui peuvent aider quelqu'un du jeu d'un cran ou deux. Parler de diverses technologies à venir ou de changements dans ce qui vient peut être passionnant et aider à former des liens.
rétroaction et suggestions - C'est ce qui s'est produit dans les deux cas ci-dessus. Des livres comme "How to Win Friends and Influence People" de Dale Carnegie peuvent aider à comprendre diverses dynamiques relationnelles humaines, qui bien que cela semble très technique est vraiment sur la façon de motiver quelqu'un d'autre de différentes façons. Un point clé ici est de savoir comment laisser une traînée de chapelure pour ramasser certaines pratiques, comme l'abandon de l'indice après indice sur quelque chose plutôt que de simplement donner la réponse. J'ai eu plusieurs professeurs de Mathématiques qui avait un don pour cette pour comment j'ai développé certaines de ces compétences.
ainsi, une partie de ceci est simplement de motiver l'autre personne et d'essayer de les guider comme quand quelqu'un comprend quelque chose pour lui-même, il peut être une expérience habilitante et instructive. De la, "je l'ai fait! C'est vrai, moi, votre serviteur!"c'est agréable de parler de soi quand ça arrive.
demandez-leur ce qu'ils essayeraient ensuite pour accomplir la tâche. Cela peut donner une idée d'où le "je ne sais pas quoi faire" à "eh Bien, je voudrais essayer cette mais..."catégorie sont-ils en termes d'avoir leur propre idée de qui peut être utile pour un point de départ.
Prendre un coup d'oeil à ce qu'ils veulent faire et d'offrir des conseils afin qu'ils comprendre le problème. C'est plutôt que de donner la réponse, "il suffit de prendre cette ligne de code," suggérez-leur de regarder ce qui est là et c'est tout nécessaire
d'après mon expérience, lorsqu'on encadre quelqu'un, il est très important que le mentoré veuille vraiment en apprendre davantage.
Jamais cuillère nourrir. Au lieu de les faire pointer vers les choses de valeur et utiliser les nouvelles informations qu'ils apprennent dans les projets qu'ils utilisent. La connaissance est inutile si pas mis en pratique. Alors encouragez votre filleul à coder, coder, coder.
je vous recommande de commencer à donner des parties des missions réelles que vous avez et de tout faire pour être en mesure d'utiliser son code. En d'autres termes, formez-le pour vous remplacer.
Cela vous permettra de vous engager à allouer du temps pour travailler avec junior et il sera en mesure de voir la "vraie vie". En travaillant sur des missions réelles et en entendant des commentaires animés, il sera en mesure d'obtenir p à la vitesse assez rapidement.
Inconvénient de cette approche est qu'il est possible qu'il se avoir une attention trop étroite sur votre projet particulier. N'oubliez donc pas de montrer au stagiaire les alternatives possibles et d'encourager l'analyse des compromis afin d'élargir son horizon professionnel.
Couple d'années, j'ai travaillé pour une petite entreprise, où le premier jour on m'a donné une liste de petites tâches à remplir - faire quelques petits changements dans le code, de trouver et de corriger un petit bug dans le projet. Cela m'a vraiment aidé à poser les bonnes questions de mon mentor et à me familiariser avec l'environnement, le code de base. Ces tâches étaient faciles à accomplir, donc j'avais un peu de confiance en moi, avant de me tourner vers les tâches plus importantes.
ce mode de mentorat a vraiment fonctionné avec moi très bien, donc j'ai l'intention de faire de même avec notre nouveau collègue.
j'ai déjà encadré plusieurs jeunes gens sous mes ordres. Mon approche varie légèrement en fonction de la personne un peu en fonction de la façon dont ils ont appris.
bref, j'ai donné aux jeunes gens de petits projets autonomes quand je le pouvais et je leur ai donné un temps relativement fixe pour accomplir la tâche. Une fois la tâche terminée, je réviserais leur approche, leur code et leur solution et je formulerais des suggestions d'améliorations ou une meilleure façon de traiter le problème. Je pense que de cette façon ils ne se sentent pas accablé de faire partie d'un projet plus vaste.
J'espère que cela vous aidera un peu.