Quand ne donnez-vous pas de l'aide à des programmeurs moins expérimentés? [fermé]

Pensez-vous que c’est une bonne idée quand un programmeur débutant a besoin d’aide pour intervenir et essayer de les éduquer? Ou vont-ils ignorer tous les conseils "d'enseigner au poisson" que vous leur donnez et vous concentrer sur le "poisson" que vous venez de leur apporter? Les laissez-vous toujours comprendre par eux-mêmes, sachant que les erreurs sont le meilleur moyen d'apprendre? Ou avez-vous peur qu'ils soient tellement brûlés et frustrés qu'ils perdent le désir de se mettre au diapason?

Quand choisissez-vous quand aider quelqu'un de moins expérimenté que vous et quand prendre du recul et le laisser apprendre grâce à ses erreurs?

Dans l'un de mes emplois, j'apprenais et enseignais (parce que je ne sais pas tout, mais j'en sais plus que certains)

Ne posez pas à tout prix les mains sur le clavier. C'est frustrant pour vous et pour la personne que vous enseignez. Même si vous leur donnez des instructions pas à pas, lorsque vous posez vos mains sur le clavier, cela revient à leur donner un morceau de code et à leur dire "ceci résout le problème".

Dans ce que j'ai appris:

• Ne tapez pas le code pour eux
• Essayez d'enseigner à leur niveau (s'ils comprennent la syntaxe, ne leur expliquez pas. Cela les ennuiera; enseignez plutôt les classes / fonctions utilisées)
• Ne les ignorez pas et ne dites pas: "Trouve-le toi-même". Vous allez vous retrouver avec eux plus tard, sauf que maintenant, les 3 lignes de code avec lesquelles ils ont eu des problèmes, est maintenant de 50 lignes réparties sur 8 fichiers essayant de contourner le problème.
• Apprenez-leur à apprendre par eux-mêmes. L'un des meilleurs moyens est de leur dire d'utiliser stackoverflow. Parfois, même en connaissant la réponse, ils me l'ont demandé. Je dirais "bon, je vais poser cette question sur stackoverflow". et je leur donnerais un lien vers la question. Prenez une pause-café et observez un code différent. Quand ils sont revenus en leur demandant "Alors, comment puis-je résoudre ce problème?" J'ai constaté que les masses sont généralement un meilleur enseignant que moi.
• Quand ils copient et collent du code sur Internet et demandent pourquoi cela ne fonctionne pas, demandez-leur d'expliquer ce que fait chaque ligne. S'ils ne le peuvent pas, dites-leur de rechercher les fonctions / classes utilisées. Si nécessaire, fournissez des explications sur la classe et les fonctions
• Réalisez des revues de code pour vous assurer qu'ils résolvent le problème, pas seulement pour le contourner afin qu'il soit visible plus tard.
• Sois gentil. Quand une personne commence juste dans votre base de code sans documentation, ne lui dites pas simplement de lire le code source. Donnez un aperçu de haut niveau résumé de la fonction en question. Ou, mieux encore, commencez à écrire de la documentation :)
• Être humble. Ne vous inquiétez pas du problème. Si vous ne le savez pas, dites-le et aidez-les à le rechercher. Plusieurs fois, le fait de connaître suffisamment le domaine pour savoir quels mots clés rechercher est une aide suffisante pour vous.

Méthode socratique, c’est-à-dire leur poser des questions qui les amènent à penser positivement

[ceci est utile même lorsque vous ne savez pas quel est le problème, encore moins la solution]

J'ai appris à les aider architecte et s'arrêter là. Choisissez les bons outils, élaborez une conception générale d'un problème complexe ou deux, et laissez-les s'y attaquer. S'ils reviennent et demandent des conseils, donnez-les-leur en petits morceaux. S'ils ne le font pas, laissez-les être.

Vous avez tout à fait raison à propos du "brûlé et frustré". Ce sera exactement ce que vous ferez si vous gérez ou micro-gérez. Enfin, il est très utile d’établir une relation de travail amicale avec vos collègues. Le temps passé à gagner la confiance et le respect mutuel sera rentabilisé 10 fois.

Je les aide quand j'ai vraiment besoin que tout soit fini rapidement, quand il est clair qu'ils se sont heurtés à un mur de briques et quand il est clairement déraisonnable de s'attendre à ce qu'ils le découvrent sans aide. Si, toutefois, ils ne consacrent pas de temps à quelque chose, il vaut mieux qu'ils le tentent en premier.

Pour ce qui est de prendre le "poisson" au lieu de "apprendre à pêcher", la meilleure façon de le faire est de ne pas résoudre les problèmes des gens pour eux . Donnez-leur des idées et laissez-les courir avec. S'ils courent avec et échouent, aidez-les davantage. S'ils réussissent, c'est encore mieux.

S'ils sont bons programmeurs, ils devraient trouver le moyen de le faire eux-mêmes. Maintenant, dans une situation où il est presque impossible de trouver des informations ou une solution à un problème donné, donner un coup de main est apparemment raisonnable si vous le maintenez dans les limites de la raison. Ne leur donnez pas à la cuillère la solution.

A titre d'exemple, j'ai peut-être 18 ans et j'apprends depuis des années de mon propre chef et j'ai écrit des choses folles, notamment mon propre compilateur et je suis autodidacte. Je ne cherche de l'aide qu'avec des choses sur lesquelles je suis vraiment coincé (comme dans le cas de mes recherches et de mes expériences depuis au moins une journée, mais en vain). J'aimerais aussi donner un contre-exemple: dans un cours de programmation, un étudiant m'a demandé de déboguer un code qu'il n'avait même pas compilé!

Essentiellement, un bon programmeur, même junior, devrait pouvoir expérimenter et rechercher des solutions à la plupart des problèmes.

Je vais conseiller mais je m'en vais s'ils veulent que je fasse leur travail pour eux. En règle générale, quelques conseils sur la façon de résoudre un problème ou de reformuler la description de la tâche peuvent aller très loin. Même en leur disant simplement les mots qu'ils devraient utiliser dans Google peut être une aide suffisante. 2 minutes maximum.

J'ai récemment commencé à utiliser la technique du pomodoro . En conséquence, si je ne peux pas répondre à une question sans interrompre la réflexion sur ma tâche actuelle, je commence à me demander si je peux reporter une réponse à la fin du pomodoro, un délai moyen de 15 minutes environ. J'ai découvert un effet secondaire intéressant: lorsque je passe près de leur bureau pour répondre à la question, ils l'ont souvent déjà résolue par eux-mêmes. S'ils ne l'ont pas encore fait, je suis beaucoup plus disposé à leur accorder toute mon attention.

Ce n'est pas l'école. Ce n'est pas de la triche si vous fournissez rapidement un fait qu'ils pourraient éventuellement trouver par eux-mêmes. Au contraire, il est judicieux pour les entreprises de gagner du temps et, selon mon expérience, les compétences sont très peu perfectionnées par essais et erreurs par rapport à un mentor qui vous donne souvent de petits efforts dans la bonne direction. Je préférerais qu'ils apprennent 10 bonnes façons de faire des choses avec mon aide plutôt que 9 mauvaises façons et une seule.

Si quelque chose peut être facilement recherché, apprenez-leur à le faire. D'un autre côté, s'il s'agit de quelque chose que vous ne pouvez connaître que par expérience, comme par exemple les fichiers sur lesquels rechercher certains symptômes de bogues, je ne vois absolument aucun inconvénient à simplement donner une réponse inexpliquée.

À l'inverse, des éléments plus subjectifs, comme l'orientation de l'architecture, devraient toujours être accompagnés du raisonnement qui les sous-tend. D'une part, le développeur débutant a réfléchi beaucoup plus en profondeur à sa tâche spécifique que vous. En parler vous garantit de ne pas sauter aux conclusions. D'autre part, cela les empêche d'appliquer aveuglément des règles à des situations futures où elles pourraient ne pas s'appliquer.

Je ne peux penser qu’à un cas où j’ai carrément refusé de continuer à aider une collègue, et c’est après avoir passé plusieurs heures à expliquer quelque chose à plusieurs reprises et avoir examiné plusieurs exemples, après quoi elle ne savait toujours pas comment écrire des indices très marquants. À ce moment-là, elle avait peu d'espoir de conserver son emploi sans une réapprentissage sérieux des fondamentaux, et bien sûr, elle n'a duré que quelques mois.

Je cesse de les aider quand ils reviennent avec la même question pour la troisième fois.

Je leur dis que je serais heureux de les aider, mais seulement s'ils s'aident d'abord. De là, ils vont chercher un autre étang pour pêcher gratuitement, auquel cas ils sont généralement virés peu de temps après. Ou alors ils y travaillent et gagnent le jackpot quand ils reviennent pour plus ... c'est plus de choses à apprendre que plus de la même chose!

Je pense que le contexte est important.

Si nous avons affaire à un problème critique de support de production pour lequel le temps de réponse est important, je fournirais alors beaucoup d'aide, accompagnée de nombreuses explications, pour qu'ils puissent comprendre le problème.

Si le délai est moins sensible, alors la complexité devient le moteur. Vous pouvez, bien sûr, aider beaucoup les débutants en leur attribuant simplement des tâches adaptées au niveau de compétence, mais si vous pouvez résoudre ce problème par la recherche, je suis d'accord avec les autres affiches qui les guide sans donner la réponse exacte est une excellente approche. .

S'ils posent des questions auxquelles on peut facilement répondre en regardant ailleurs, je les oriente alors vers leur propre travail. Dans le même ordre d'idées, s'il existe un processus ou une solution assez complexe et qu'il est peu utile de le rendre esclave de ce processus, honte à vous si vous n'avez pas de wiki à leur disposition pour qu'ils puissent le vérifier.

Lorsqu'il s'agit de transférer des connaissances de domaine personnalisées à l'entreprise, je ne mâche pas mes mots. Lisez-le directement dès que possible. Les débutants ont besoin de ça pour aider avec tout ce qui vient plus tard. Il n’existe pas d’information sur l’entreprise trop rapidement ou trop facilement. Un jour, j'ai eu un patron qui a joué toutes sortes de tours pendant une heure en essayant de me conduire à une réponse. J'étais tout nouveau, je ne savais rien encore de l'application ou de l'entreprise, et je m'occupais d'un problème de support à la production. Je voulais crier: "Pourquoi jouez-vous & # @ $!! Jouez-vous à des jeux # @ & (* $%!?? Les utilisateurs qui tentent de faire sortir des factures attendent une réponse!"

Je pense que la première chose que vous devez leur demander avant de les aider est de savoir si vous avez mené une enquête à ce sujet. Si oui, demandez-leur ce qu'ils ont découvert et orientez-les dans la bonne direction. Les enquêtes sont souvent sous-évaluées, mais il s’agit de l’une des meilleures pratiques que j’ai apprises. Trouver des informations sur vos besoins vous donne le pouvoir d’apprendre par vous-même. Cela indiquera également clairement qu’ils doivent essayer au préalable.

Si le problème est plus complexe, essayez de ne pas leur dire quoi faire, mais de partager quelques idées, demandez-leur comment ils pensent pouvoir aborder le problème.

S'ils n'ont pas la moindre idée, essayez de le décomposer à un niveau très élémentaire où vous ne donnez pas tous les détails, mais décrivez suffisamment la solution pour qu'ils puissent l'essayer. Il existe des outils très utiles pour cela, tels que des algorithmes ou des organigrammes .

En conclusion, essayez de les guider sans interférer avec le processus d’apprentissage, en les aidant toujours à les faire dépendre de vous pour chaque tâche ensuite assignée, cela prendra votre temps et ira à l’encontre de la productivité.

J'évite d'aider sur des choses simples telles que la syntaxe qu'ils doivent connaître ou s'ils ne savent pas qu'ils devraient pouvoir comprendre par eux-mêmes. Si c'est quelque chose de plus complexe, cela ne me dérange pas d'expliquer une fois.

Quand il s'agit de choses comme expliquer le processus, ou les normes de codage de notre organisation / projets, etc., j'utilise la règle des trois impacts. Je pense vraiment qu’une personne est boiteuse s’il faut lui expliquer trois fois les choses. En fait, c'est également l'un des critères de notre évaluation.

Beaucoup dépend de l'apprenant. Je m'attends à ce qu'ils ramassent quelques choses par eux-mêmes. S'ils trouvent: "J'ai fait face à ce problème, j'ai essayé les méthodes A, B et C mais je ne pouvais pas résoudre le problème", je les aiderai. S'ils se contentent de dire «Je fais face à ce problème» et s'ils n'ont rien fait, je leur demanderai de revenir aux livres et de chercher une solution.

En tant que programmeur débutant moi-même (environ 9 mois dans mon travail actuel utilisant principalement Perl et SQL et avec a) aucune connaissance de Perl et b) quelques mois de bricolage avec SQL avant cet emploi), lorsque je pose des questions sur la programmation, j'essaie de montrer ce que j’ai fait jusqu’à présent, ou dans le cas où quelque chose ne fonctionnait pas (et étant difficile à déboguer), où je pense que le bogue pourrait venir. Dans la mesure du possible, j'ai cherché à apprendre à pêcher.

J'arrête d'aider dans les circonstances suivantes:

• Si je suis habitué à canaliser Google / Stack
• Si j'ai fourni la documentation et les commentaires adéquats et qu'ils raccourcissent l'étape RTFM
• S'ils sont sales, pas de commentaires, "je vais pirater ça maintenant et y revenir plus tard" & & £>! $

Si je n'ai pas fourni les docs adéquats, ou s'ils travaillent avec un outil / un cours que j'ai créé, c'est ma responsabilité de les aider.