Comment encadrer un développeur junior
Ce titre est un peu large mais je devrai peut-être donner un peu de contexte avant de pouvoir poser correctement ma question.
Je sais que des questions similaires ont déjà été poséesici . Mais dans mon cas, je ne demande pas si je devrais être le mentor de quelqu'un ou si la personne est un bon ajustement pour être un développeur de logiciels. Ce n'est pas à moi de juger. On ne m'a pas demandé tout de suite, mais il est évident que moi-même et d'autres collègues développeurs seniors doivent encadrer les nouveaux développeurs qui commencent ici. Je n'ai aucun problème avec cela et, dans de nombreux cas, cela me donne une nouvelle perspective sur les choses et je finis par apprendre dans le processus. De plus, je me souviens à quel point c'était bénéfique au début de ma carrière quand quelqu'un prenait le temps de m'apprendre quelque chose.
Quand je dis "nouveau développeur", cela peut aller de la sortie du collège à un an ou deux d'expérience.
Récemment, nous avons vu des gens commencer ici qui semblent avoir une attitude envers le développement/la programmation qui est différente de la mienne et difficile à concilier pour moi; ils extraient juste assez d'informations pour accomplir la tâche mais n'en tirent pas vraiment de leçons. Je me retrouve à répéter les mêmes problèmes avec eux. Je comprends qu'une partie de cela pourrait être une question de personnalité, mais je pense que c'est mon travail de faire de mon mieux et de les pousser hors du nid pendant qu'ils sont sous mon aile, pour ainsi dire.
Comment puis-je transmettre juste assez d'informations pour qu'ils apprennent mais ne donnent pas suffisamment pour résoudre le problème pour eux?
Ou peut-être:
Quelle est la réponse appropriée aux questions conçues pour emprunter la voie de la moindre résistance et, par essence, les forcer à apprendre plutôt qu'à emprunter la voie de sortie facile?
Ces questions sont probablement des questions d'enseignement plus générales et n'ont pas grand-chose à voir spécifiquement avec le développement de logiciels.
Remarque: Je n'ai pas mon mot à dire sur les tâches sur lesquelles ils travaillent. La direction distribue la tâche et il peut s'agir d'une simple correction de bogue au démarrage d'une application entière par elle-même. Bien que cela ne soit en aucun cas idéal et présente évidemment son propre gant de défis, je pense que c'est un sujet qu'il vaut mieux laisser pour une autre question. Donc, le mieux que je puisse faire est de les aider à résoudre le problème actuel et essayer de les aider à le décomposer en problèmes plus simples et également vérifier leurs journaux de validation et signaler les erreurs qu'ils ont faites.
Mes principaux objectifs sont de:
- Aidez-les et donnez-leur les outils dont ils ont besoin pour devenir plus autonomes.
- Dirigez-les dans la bonne direction et brisez tôt les mauvaises habitudes de développement.
- Réduisez le temps que je passe avec eux (le type de personnalité décrit ci-dessus a tendance à nécessiter beaucoup plus de temps en tête-à-tête et ne fonctionne pas bien par messagerie instantanée ou par e-mail. Bien que ce soit généralement bien, je ne peux pas toujours arrêter ce que je '' Je travaille, je brise ma foulée et je les aide à déboguer une erreur à quelques instants; j'ai mes propres projets à faire).
Il y avait une fois une question ici qui contenait ce genre d'informations, et la pièce qui m'a le plus marqué était ne touchez pas leur clavier
En bref, dites à votre junior comment d'accomplir ce qu'il essaie de faire, mais ne le faites pas pour lui.
Mais en plus de cela, voici quelques autres conseils:
- Encouragez Google (ou tout autre outil de recherche). Si vous savez que la réponse peut être trouvée facilement en ligne, dites-leur de la rechercher au lieu de leur dire la réponse. En fin de compte, vous voulez leur apprendre à s'auto-enseigner, et ne pas les faire devenir dépendants de vous.
- Rendez-vous disponible pour répondre aux questions. Si vous n'êtes jamais disponible ou si vous ne souhaitez pas être interrompu, indiquez-leur clairement qu'ils doivent maintenir leurs questions jusqu'à une heure spécifiée.
- Examinez régulièrement le code pour leur dire ce qu'ils font bien/mal. Utilisez-le comme une opportunité pour souligner les meilleures pratiques
- Commencez tôt avec les meilleures pratiques. Il vaut mieux prendre plus de temps pour leur enseigner la bonne façon que d'essayer de changer leurs méthodes plus tard.
- Faites-les commencer tôt avec la planification/documentation de ce qu'ils vont faire au lieu de les laisser commencer par écrire du code.
- Soyez ouvert à apprendre d'eux. Ils passent probablement plus de temps que vous à apprendre, et il est possible qu'ils apprennent quelque chose que vous ne saviez pas.
Aidez-les à apprendre de leurs erreurs. Il y aura des erreurs, alors assurez-vous de leur montrer que les erreurs font partie de l'apprentissage et qu'elles devraient les utiliser comme une opportunité d'apprendre.
(D'après RuneFS ci-dessous) Au lieu de leur dire comment faire quelque chose, essayez de les aider à le découvrir eux-mêmes. Cela aidera à améliorer leur capacité à résoudre logiquement un problème et à augmenter leur capacité d'apprentissage
- (D'après RuneFS ci-dessous) Au lieu de leur dire ce qu'ils ont fait de mal, dites-leur comment ils peuvent l'améliorer. Assurez-vous d'inclure pourquoi votre chemin est meilleur que le leur. Cela renforcera leur confiance au lieu de l'affaiblir. Bien sûr, s'ils ne vous écoutent pas, n'ayez pas peur de leur dire de le faire correctement :)
J'ai environ 4 ans d'expérience, et je peux vous dire de mon expérience en tant que développeur junior ce que je souhaite avoir en termes de mentorat. Il semble que vous décriviez en fait le type de développeur que j'étais lorsque j'ai commencé :)
Essentiellement, vous voulez les encourager à apprendre. Certaines personnes pensent qu'après avoir terminé leurs études collégiales, elles n'ont plus à lire de livres ni à apprendre. Ce genre d'attitude peut conduire à rechercher des raccourcis et simplement à "faire avancer les choses".
Faites-leur "Le programmeur pragmatique" et demandez-leur de le lire. Ce livre les aidera à réaliser que la programmation est un métier/carrière et pas seulement un travail. Recommandez-leur de lire des livres tous les trimestres environ. Aidez-les à construire leur "portefeuille de connaissances" (comme mentionné dans Pragmatic Programmer). Je recommande fortement Safari Books Online qui a beaucoup de livres CS/Programmation.
Grâce à leur portefeuille de connaissances, ils sauront où chercher s'ils ont des problèmes. Apprenez-leur où chercher. J'ai moi-même découvert l'utilité de StackOverflow récemment (et comme vous le savez, il vaut mieux regarder ici que Google).
Il semble que vous ne puissiez pas passer beaucoup de temps avec eux, mais la programmation par paires est très utile. Si vous ne pouvez pas le faire, faites au moins des révisions de code à l'aide de CodeCollaborator ou d'un autre outil similaire. Ils ne prennent pas autant de temps que vous le pensez.
Les tests unitaires sont également très importants. Ils peuvent rapidement révéler de mauvaises pratiques de développement, surtout si vous les associez à une intégration continue.
Posez des questions dirigeantes pour le guider vers des réponses plutôt que de simplement lui dire (enfin vous pouvez lui dire des choses de base comme le nom du serveur et la base de données qui stocke les informations). Montrez-lui comment trouver ses réponses.
Et ne réécrivez jamais son code lorsqu'il est incorrect, dites-lui ce qui ne va pas et attendez-vous à ce qu'il le corrige. Vous obtenez ce que vous attendez. Vous n'aidez personne en le rendant dépendant de vous.
Les révisions de code sont également essentielles. Et si vous jumelez un programme, laissez-le avoir le clavier fréquemment. Même si vous lui dites quoi taper, il apprendra à taper davantage qu'il apprendra juste à côté de vous pendant que vous programmez.
Prenez quelques exemples du logiciel qui sont typiques de la façon dont l'application est structurée et passez en revue avec lui ligne par ligne en vous assurant qu'il comprend pourquoi chaque ligne est nécessaire et ce qu'elle fait. Il est de votre devoir de vous assurer qu'il connaît les normes de codage et comment le code est organisé et pourquoi vous (en tant qu'entreprise) faites les choses comme vous le faites.
S'il a une autre façon de suggérer, écoutez attentivement. En premier lieu, il a peut-être raison. En second lieu, l'écoute vous dira où se situe sa faiblesse de compréhension si ce qu'il suggère n'est pas pratique. De plus, les gens ont tendance à vous respecter davantage si vous les écoutez. Lorsqu'il a tort, revenez aux questions principales pour lui faire comprendre pourquoi l'idée est fausse. S'il est même près d'avoir raison, allez parfois avec ses idées, rien n'est plus décourageant que de toujours être dit que vos idées ne valent rien.
Posez des questions sur son parcours. Il sait peut-être des choses avec lesquelles vous n'avez pas eu l'occasion de travailler. Si c'est le cas et que l'occasion de les utiliser se présente, posez-lui des questions sur ses connaissances.
Si votre application est ancienne, elle contient probablement des "pièges" sournois que quelqu'un de nouveau n'aura aucun moyen de connaître. Donc, quand il commence à travailler sur des zones où vous avez un ou plusieurs de ces pièges, vous pouvez lui en parler alors qu'il se met au courant avant de coder, puis regardez s'il est tombé dans le piège quand il a codé.
Enfin, vous obtenez le respect en partie en donnant du respect. Traitez chaque personne que vous encadrez avec respect. Ne les faites pas se sentir rabaissés ou stupides. Ils vous écouteront beaucoup mieux si vous les traitez avec respect.
- Je m'assure toujours que le développeur veut mon aide, et je prends grand soin de ne pas aller plus loin dans les explications que sa patience ne peut tolérer. Comme tout le monde, j'aime le son de ma propre voix!
- Je les traite comme des égaux et je m'assure de demander leur avis aussi souvent que je le pense.
- Attrapez-les en train de faire quelque chose de bien et faites-leur savoir.
- J'apprends toujours quelque chose quand je fais ça correctement - sur mon métier, sur mon métier, sur le développeur et sur l'enseignement.
- La première leçon est toujours: quand savoir que vous l'essayez vous-même depuis trop longtemps. Beaucoup de gens sont fiers de trouver leurs propres réponses et perdent un temps précieux à tourner en rond.
Je suis un développeur junior et je pense que mon mentor gère très bien ces choses. En général, il me dira quelques façons de faire quelque chose, mais pas comment le faire. Ensuite, je m'asseyais là et essayais des deux façons, et décidais quelle était la solution la plus propre au problème.
De plus, si jamais il faisait quelque chose qui pourrait m'être utile, il m'appellerait juste pour expliquer ce qu'il faisait et pourquoi.
Cela m'a permis de passer un peu de temps avec moi, ce qui signifie essentiellement que je devais moi-même apprendre les bonnes réponses et comment mettre en œuvre les choses. Bien sûr, si jamais je restais coincé, il serait là pour aider, mais c'était une poignée de fois. Après seulement 5 mois de travail avec lui, j'ai probablement acquis plus de connaissances sur les choses que l'ensemble de mon cursus universitaire.
La chose importante à retenir est que je suis juste un individu et cela a bien fonctionné pour moi à cause de ma façon d'être et comment il est. Il s'agit de trouver une structure appropriée qui vous aidera tous les deux.
Selon la tâche confiée, je serais tenté d'adopter plusieurs approches différentes:
Demandez-leur ce qu'ils essaieraient ensuite pour terminer la tâche. Cela peut donner une idée d'où de la catégorie "Je ne sais pas quoi faire" à "Eh bien, j'essaierais ceci mais ..." sont-ils en termes d'avoir leur propre idée qui peut être utile comme point de départ .
Jetez un coup d'œil à ce qu'ils veulent faire et proposez-leur des astuces pour comprendre le problème. C'est plutôt que de donner la réponse: "Retirez simplement cette ligne de code", suggérez-leur de regarder ce qui est là et tout cela est nécessaire.
Si le premier couple ne va pas travailler, j'essaierais de lui faire suivre mes instructions sur ce qu'il faut faire pour résoudre le problème. C'est la prochaine étape de la progression où s'ils n'ont aucune idée par où commencer et que les indices ne fonctionnent pas, c'est le point suivant.
Enfin, si rien d'autre ne fonctionne, je ferais le travail pour eux, mais j'essaierais d'éviter cela autant que possible, car c'est ainsi que des problèmes comme une personne connaissant intimement un système sont créés car quelqu'un peut envisager le déchargement du travail sur moi pour ce système que je semble si bien connaître.
Une chose que j'ai faite ici dans mon travail que j'ai trouvé vraiment utile était de mettre en place un forum (c'est-à-dire PHPbb) pour les questions et réponses internes, et de suivre la règle selon laquelle si la question et/ou la réponse prend plus de 5 minutes, cela devrait être demandé et répondu via le forum. Les avantages:
- Cela oblige le développeur junior à énoncer clairement la question, ce qui facilite la réponse, sans parler des moments où il trouve la réponse lui-même, juste en y réfléchissant un peu plus.
- Cela évite les questions en double, car le développeur junior devrait commencer par rechercher des questions similaires déjà faites
- Il aide à construire une base de connaissances qui sera utile pour les futurs employés et pour documenter de nombreuses petites choses qui pourraient être perdues avec le temps.
Je vais inverser la tendance ici et vous suggérer pas d'essayer d'encourager les développeurs juniors à apprendre comment trouver les réponses eux-mêmes. Cela ressemble à un jeu de "je l'ai mais je ne vais pas vous le donner."
Au lieu de cela, jumelez-vous avec eux pour trouver la réponse. Vous allez quand même le rechercher sur Google, alors faites-le en étant assis avec eux. Ils comprendront que c'est le moyen de trouver des réponses.
Si vous travaillez en étroite collaboration avec eux, ils découvriront comment utiliser correctement IDE; comment normaliser une base de données; comment DRY sortir votre code). .. tout ce que vous savez qui vaut la peine d'être connu.
Les clés sont les suivantes: un - pour vous mettre à leur disposition afin qu'ils puissent voir comment vous travaillez. Et deux - à dites à haute voix pourquoi vous faites ce que vous faites. "Ce code se répète, donc je vais le refactoriser", "ne pas" utiliser la méthode d'extraction sur ces trois lignes. "
Je n'ai eu à former un programmeur junior qu'une seule fois. C'était pour aider à maintenir un système que j'avais construit. Le but était finalement de lui remettre l'ensemble du système.
Après une courte période où il m'a suivi, je l'ai jeté dans le feu. Je lui assignerais des cas et je m'attendrais à ce qu'ils soient terminés. S'il avait des problèmes, je lui demanderais d'expliquer quel était le problème et où il avait regardé. Je lui conseillerais alors, dans les termes les plus généraux, où chercher ensuite. (Quelle application, peut-être quel module regarder, etc.). Je ne le laisserais jamais patauger, mais je ne ferais jamais aucun des travaux. Fournissez uniquement une direction. S'il avait encore des problèmes, je haussais les épaules et disais "Commence à tracer le code". Et chaque fois que je disais ça, il grincait des dents - sachant qu'il allait faire un exercice fastidieux. Cela le rendait fou, parce que nous savions tous les deux que je pourrais probablement trouver le problème en 10 minutes si je pouvais juste descendre de mes fesses et aider.
Des années plus tard, il est passé à de plus grandes choses et maintenant il forme ses propres juniors. Et son histoire préférée est comment je lui dirais toujours de "tracer le code", et comment ces exercices de traçage de code étaient cruciaux pour faire de lui le programmeur qu'il est aujourd'hui.
Chaque fois que l'on me pose une question dont je sais qu'elle peut être résolue par une recherche rapide sur Google, je vais trouver de la documentation ou un article relatif et le transmettre à la personne qui pose la question.
Savoir où chercher est une compétence importante, et c'est parfois plus difficile que vous ne le pensez pour un nouveau développeur. Ils ne savent peut-être même pas ce qu'ils recherchent, et c'est là que vous devez les aider.
Une fois dans leur main, les articles et la documentation les forceront à lire sur la solution au lieu de griffer d'autres développeurs pour une réponse rapide.
Cela accomplira les tâches suivantes:
- Alléger une partie du fardeau des développeurs chevronnés.
- Forcer le nouveau développeur à apprendre.
- Du bonheur pour tous.
Parfois, il suffit de leur donner un amour dur, surtout s'ils ne semblent pas vouloir apprendre. Ne leur donnez pas la réponse, mais assurez-vous de les orienter dans la bonne direction.
Je recommanderais de commencer à donner des parties de vraies tâches que vous avez et de tout faire pour pouvoir utiliser son code. En d'autres termes, entraînez-le en remplacement de vous-même.
De cette façon, vous vous engagez à allouer du temps pour travailler avec junior et il pourra voir la "vraie vie". En travaillant sur de vraies affectations et en entendant des commentaires animés, il pourra accélérer assez rapidement p.
Les autres réponses sont très bonnes, mais je voulais commenter cette seule phrase.
Récemment et dans le passé, nous avons vu des gens commencer ici qui semblent avoir une attitude envers le développement/la programmation qui est différente de la mienne et difficile à concilier pour moi; ils semblent extraire juste assez d'informations pour accomplir la tâche, mais pas vraiment en tirer des leçons.
La plupart des gens veulent savoir comment faire quelque chose. Cette attitude est bonne au début lorsque vous êtes accablé d'apprendre de nouvelles choses et d'apprendre à faire votre travail.
Rares sont les personnes qui veulent savoir pourquoi quelque chose est fait. Ce sont ces personnes que recherchent les gestionnaires intelligents, même si elles sont parfois difficiles à gérer.
Certaines personnes codent pour être bien payées. D'autres acceptent volontiers de l'argent pour le codage. C'est bien plus agréable de travailler avec des gens passionnés par la conception et le codage. Malheureusement pour moi, c'était aussi assez rare. Au moins jusqu'à ce que je trouve Stack Overflow.
Une chose à surveiller, pour ceux qui s'enthousiasment à l'idée de faire tout ce mentorat pour les développeurs juniors: assurez-vous que votre direction comprend ce qui se passe.
Enseigner aux autres est un travail difficile, en général. Il faut de la concentration et de la concentration, de la planification et des efforts, et surtout du temps. Quelle que soit l'approche que vous adoptez, si vous enseignez et encadrez de façon sérieuse, cela va vous faire perdre votre temps.
Si votre direction embauche des développeurs moins expérimentés dans l'espoir que des développeurs seniors assumeront des tâches de formation, assurez-vous que c'est explicite. Découvrez quel sera le calendrier et assurez-vous que vos calendriers de développement reflètent le temps et les efforts consacrés à la formation. Assurez-vous que la direction a des plans pour évaluer le succès des efforts de mentorat à certains moments convenus. (Bien sûr, s'ils recrutent des développeurs qui ont besoin d'enseignement et de mentorat, mais la direction ne pas le prévoit, alors c'est évidemment un problème grave.)
Tout le monde n'est pas un bon enseignant ou mentor, et tout le monde ne veut pas l'être. Je ne veux pas paraître croustillant ou amer; J'aime beaucoup l'enseignement. Mais il est stupide de s'attendre à ce que tout le monde soit bon dans ce domaine (malgré leurs propres talents), et nous ne pouvons pas non plus nous attendre à ce que tout le monde apprécie le processus (rappelez-vous, ce n'est pas facile). De plus, si vous êtes un développeur senior qui aime pas le mentorat, ou si vous sentez vraiment que vous êtes un mauvais choix pour un enseignant ou un mentor, assurez-vous que votre direction comprend qu'un plan vous impliquant ces fonctions sont un plan comportant de graves lacunes. D'un autre côté, si vous voulez devenir bon en enseignement ou en mentorat, c'est quelque chose à communiquer également.
Si l'enseignement et le mentorat sont des charges partagées de manière inégale au sein de la population des développeurs seniors, assurez-vous que ces missions sont reconnues comme précieuses pour l'entreprise de la même manière que les réalisations en matière de développement de produits sont reconnues.
J'ai enseigné diverses matières aux gens dans le passé, et ce qui m'a le plus frappé, c'est que la plupart des gens n'ont pas de compétences en résolution de problèmes . Autrement dit, si vous leur montrez une solution exacte, ils sont en mesure de la réutiliser plus tard s'ils reconnaissent ou sont informés qu'ils en ont besoin.
Mais, très peu de situations dans la vie sont comme ça. À moins que votre travail ne soit une "usine mentale" impliquant de coller le widget A au widget B avec l'outil C, vous devrez alors disposer de quelques éléments:
- Une boîte à outils de compétences et d'outils
- Une méthode de résolution de problèmes
Par exemple, prenez un regardez cette réponse que j'ai publiée . Cela couvre la méthode de résolution de problèmes que beaucoup de gens n'ont pas. Le Collège n'a enseigné cela à personne dans le programme CompSci, vous le saviez déjà ou vous l'avez compris vous-même.
Une fois que le développeur junior a compris comment résoudre les problèmes, il a besoin d'un ensemble d'outils pour le faire.
- Débogueur (le Collège n'a jamais mentionné cela)
- Profileurs
- Éditeur de texte
- Shell (et utilitaires associés)
- Ressources (livres, google, SO, pages de manuel)
Déterminez ce qui manque au développeur junior et vous pouvez l'aider à s'améliorer. Sachez simplement que certaines personnes ne sont vraiment pas intéressées à apprendre à résoudre leurs propres problèmes et veulent simplement une solution "étape par étape évidente" qui leur soit remise. Ce ne sont pas de bons développeurs.
J'espère que vous n'en aurez pas. Si vous le faites, sachez que peu importe le temps que vous passez, ils ne s'aideront pas tous eux-mêmes. Cela demanderait des efforts, et il est plus facile de simplement vous demander de le faire pour eux. Il est similaire au problème du bien-être et expliqué par la théorie économique.
L'intérêt personnel éclairé indique que les gens prendront ce que ils considèrent comme l'option la plus avantageuse dans une situation donnée. Notez que c'est ce qu'ils voient. Je vois la chose la plus importante comme l'autosuffisance et l'apprentissage. Donc, je fais les choses moi-même. Mais d'autres peuvent voir qu'ils ont juste besoin de fournir un code de travail avant la date limite. Ils recherchent donc la méthode la moins coûteuse pour le faire. En leur offrant des "cadeaux", ils doivent dépenser le moindre effort pour atteindre leur objectif. Jusqu'à ce que vous retiriez cette béquille, ils ne le feront pas grandir.
Votre organisation telle que vous la décrivez est très différente de la mienne. Je suis en contrôle de mon travail chez les juniors et je considère que c'est mon rôle de juger. Donc, beaucoup de choses sont différentes.
Une chose que je voudrais vous conseiller de faire de toute façon, c'est de visiter fréquemment leur bureau au cours des deux premières semaines. Quelque chose comme trois fois par jour la première semaine, diminuant progressivement.
Le message que j'essaie d'envoyer de cette façon est que je me soucie de leur productivité. Je m'assure qu'ils ne restent pas coincés. Je m'assure qu'ils suivent les règles et ne réinventent pas la roue. Je leur apprends à s'engager le plus souvent possible. Apprenez-les à se développer progressivement et pensez à concevoir progressivement.
Mon pire cauchemar, ce sont les développeurs qui, chaque jour, vous disent qu'ils n'ont besoin que d'un jour de plus pour que leur fonctionnalité soit réalisée. Après des semaines de retard, vous obtenez un design trop compliqué, qui est piraté dès le début par son auteur. Des fonctionnalités de buggy supplémentaires non demandées sont ajoutées au mélange pour compenser le retard et parce qu'elles étaient un effet secondaire gratuit de la conception.
Je pense que de nombreux développeurs sont enclins à cette approche. Si vous vous retrouvez seul avec une tâche compex, c'est une réaction naturelle d'essayer de prouver que vous pouvez le faire vous-même. Mais ce n'est pas la bonne réponse. La qualité est un travail d'équipe, et plus tôt ils apprennent, mieux c'est.
Je vais vous donner mon regard là-dessus.
En gros, j'apprends bien quand je:
- On me donne une introduction formelle au sujet. Je ne pourrai jamais apprendre quelque chose de nouveau sans que quelqu'un (oui, une personne) réponde à toutes les questions que j'ai sur le de nouveaux concepts. Une fois que j'ai fait cela, je ...
- Obtenez un livre. En tant que mentor, vous devriez avoir exactement le même livre pour que je puisse toujours dire quelque chose comme: "Hé, qu'est-ce que cela signifie dans le chapitre quatre, page 72, paragraphe 6 ... "et vous saurez exactement de quoi je parle. Une fois que j'ai un livre, je suis plus indépendant et je ne pose vraiment que des questions. Alors je...
- Démarrer un projet ensemble. C'est la partie la plus importante du processus. C'est ici que vous pouvez commencer à m'enseigner les meilleures pratiques, les algorithmes, les fonctionnalités de langage difficiles (mais utiles), etc.
Maintenant, vous aviez dit que vous avez vos propres projets à gérer et que vous n'avez pas toujours le temps. C'est pourquoi nous avons eu la chance de StackOverflow . Je suis sûr qu'ils seraient heureux de l'aider à déboguer son code. Quant aux questions qui ne sont pas sur le sujet, il peut les poser ici.
Cela dit, vous devez toujours travailler avec lui régulièrement. Une "chronologie" générale devrait être :
- 1 mois. Devrait connaître la syntaxe de base. Toujours pas indépendant lors du codage.
- 3 mois. À ce stade, il devrait connaître la syntaxe comme le dos de sa main et devrait être capable de résoudre facilement des problèmes simples. Il est beaucoup plus indépendant, mais pas encore tout à fait là.
- 6 mois. Ils devraient savoir, en plus de tout le reste: Meilleures pratiques, algorithmes communs, etc. Il devrait être capable de faire un projet lui-même, peut-être avec un peu d'aide de SO.
Outre ce qui précède, la façon la plus simple de rendre quelqu'un indépendant est de lui donner un sujet difficile à apprendre et de ne lui donner rien d'autre que l'Internet. Il sera forcé d'apprendre par lui-même et il connaîtra ses trucs.
Une fois qu'il sait ce que vous voulez qu'il sache, libérez-le. Permettez-lui de partir et d'apprendre ce qu'il veut apprendre (vous pourriez toujours dire que vous veulent qu'il continue à travailler dans cette langue).
J'espère que ça aide! Soit dit en passant, laissez-le lire ceci: Enseignez-vous à programmer en dix ans .
Je n'ai vu personne ici mentionner mon héros personnel, Randy Pausch .
Je pense que cela peut être bénéfique pour tous ceux qui suivent, enseignent ou encadrent des programmes (ou même pour ceux qui veulent vivre une vie pleine de sens). Vous et/ou vos collègues pourriez trouver que regarder ces conférences en vaut la peine comme moi, sur
- réaliser vos rêves (il était professeur et cela est fortement lié à la motivation des autres), et
- gestion du temps .
Faites une distinction entre les niveaux d'apprentissage inférieurs et supérieurs. Si c'est lié à la connaissance, à la compréhension ou à l'application, je n'ai aucun problème à leur donner la réponse, avec une brève explication sur la façon dont ils pourront le rechercher la prochaine fois. Ce n'est pas l'école, ce n'est pas de la triche, et ils ne compteront pas sur vous de cette façon pour toujours. Ne prévoyez tout simplement pas de faire quoi que ce soit d'autre pendant la première semaine ou les deux, afin que cela ne vous ennuie pas lorsque vous ne le faites pas.
Après les deux premières semaines, si vous êtes interrompu trop souvent avec ce genre de questions, utilisez une minuterie pomodoro et ne répondez à aucune question avant la fin d'un pomodoro. Google est facile pour vous maintenant, car vous savez quoi rechercher. Souvent, ils ne le font pas, donc si vous devez leur dire de rechercher quelque chose sur Google, dites-leur quels termes de recherche utiliser pour obtenir les meilleurs résultats.
Si un problème est lié à l'analyse, la synthèse ou l'évaluation, je passe plus de temps sur le sujet. C'est là que vous fournissez votre raisonnement derrière vos décisions et les aidez à tirer les mêmes conclusions. Cela revient le plus souvent en matière de design et de style. Ne leur dites pas seulement d'utiliser un certain design, montrez pourquoi ils sont supérieurs à leur premier choix. Laissez-les faire des erreurs et laissez-les réparer leurs propres erreurs.