Les programmeurs seniors devraient-ils être tenus d'embaucher et d'encadrer un développeur junior? [fermé]


25

Dans une boutique conçue pour être soudée et solidaire, cela devrait-il faire partie de la culture selon laquelle les développeurs seniors sont associés à des développeurs juniors en tant que mentors? Ou ce mentorat devrait-il être quelque chose de plus organique et spontané, c'est-à-dire non requis, mais autorisé à se développer sans encouragement artificiel?


12
Les mandats ne fonctionnent pas; en fait, ils ont souvent l'effet inverse. Al Capone a été créé par la législature du gouvernement. Certains Allemands de l'Est qui ont dû étudier le russe pendant 4 ans étaient fiers de ne pas pouvoir prononcer une seule phrase dans cette langue. La même chose peut se produire si vous donnez mandat à l'enseignement de l'évolution ou si vous avez le mentor du gars senior pour le junior.
Job

3
Il doit être organique pour valoir quoi que ce soit, mais il peut encore être forcé d'une certaine manière en décidant qui est là en premier lieu. Quiconque ne travaille pas en étroite collaboration avec les autres développeurs, qu'ils soient juniors ou seniors, ne vaut pas grand-chose. Il devrait y avoir une conversation continue au sein de votre équipe, et tout le monde devrait apprendre et enseigner. C'est une bonne raison de commencer les gens comme entrepreneurs ou employés provisoires pour voir s'ils gélifient correctement.
Peter DeWeese

@Job Vous êtes-vous déjà demandé qu'un développeur pourrait finir par faire la même merde toute sa vie [exagération inoffensive] s'il ne mentorait pas un junior pour faire son [je veux dire commun .. il ne va pas la guider en physique]?
Chani

Réponses:


37

Je pense que cela devrait être encouragé mais pas obligatoire; les seniors ne devraient pas être affectés à des juniors ou quelque chose comme ça, sinon vous vous retrouverez à Dilbert-land. La relation «mentor-mentoré» requiert un certain niveau d'amitié à la base, ainsi qu'une bonne dose de respect mutuel. Vous n'obtenez pas cela en disant simplement aux gens de partir et de «mentir».


3
Comment l'encouragez-vous alors? Comment pouvez-vous vous assurer que les aînés et les juniors savent qu'il est acceptable de prendre du temps de travail pour être mentor / être encadré?
richard

3
Si vous encouragez un modèle de programmation en binôme, ce type de relation échoue souvent si vous encouragez simplement les juniors et les seniors à se jumeler. En plus de cela, entretenez des amitiés à travers toute l'équipe; exercices de consolidation d'équipe, sorties et autres interactions non professionnelles.
KeithS

Cela semble être un bon moyen de favoriser les amitiés qui devraient naturellement conduire au mentorat.
richard

Je suis tout à fait d'accord, le mentorat à son meilleur redonne autant au mentor qu'au mentoré, donc des conversations ouvertes et «au niveau des yeux» sont une condition préalable
Asaf

21

cela devrait-il faire partie de la culture selon laquelle les développeurs seniors sont associés à des développeurs juniors en tant que mentors?

Oui.

organique et spontané, c'est-à-dire non requis, mais laissé à se développer sans encouragement artificiel

Cela n'arrivera pas assez souvent pour réellement aider quelqu'un.

Les personnes ayant des relations existantes dans les organisations seront perçues comme des cliques ou des élitistes par de nouvelles personnes. Les cliques ne s'effondreront pas normalement. Nous restons avec des gens que nous connaissons - c'est un élément essentiel de la nature humaine.

En tant que consultant depuis plus de 30 ans (une centaine d'engagements clients), je peux affirmer que les nouvelles personnes sont toujours des étrangers. Ce n'est pas une caractéristique de la "culture" ou des "atmosphères". C'est une caractéristique essentielle de la façon dont les gens travaillent. Les consultants forment leur propre clique parce que le personnel établi n'a pas tendance à les inclure dans quoi que ce soit.

La seule façon d'établir un mentorat est d'insérer de nouvelles personnes dans les cliques.


@David Thornley et S.Lott: Pouvez-vous partager ce que vous avez vu dans vos expériences? Des annecdotes? Je reçois des réponses vraiment mitigées ici!
richard

@Richard DesLonde: Je n'ai presque jamais vu de mentorat se former spontanément, même si je ne suis peut-être pas la meilleure personne à poser (je suis un peu asocial pour un développeur de logiciels). La seule fois où j'ai vu cela se produire à une échelle significative, c'est lorsque la direction a demandé des personnes intéressées à être des mentors et des mentorés et suggéré des jumelages.
David Thornley

1
@Richard DesLonde: "Je reçois des réponses très mitigées"? Qu'est-ce que vous attendiez? C'est une question subjective sur la "socialisation". Il n'y a pas de bonne réponse. S'il y en avait, nous le ferions déjà.
S.Lott

C'est ce que je pensais. Mais vous et David y arrivez de l'autre côté que la plupart des autres réponses, donc je voulais que vous fassiez un peu plus d'effort pour équilibrer les réponses. Je veux autant d'informations des deux côtés que possible. Merci! :-)
richard

8

Le sens traditionnel d'un «mentor» défie quelque peu les affectations. Vous pourriez aussi bien essayer d'assigner des amis.

D'après mon expérience, il est bon d'affecter un nouveau membre de l'équipe à un membre de l'équipe établi comme principal contact pour les questions au cours de la première semaine, du mois ou plus.


1
Comment encourageriez-vous alors le mentorat? Vous voulez que les juniors se sentent à l'aise d'être encadrés et vous voulez que les seniors se sentent à l'aise avec le mentorat.
richard

1
@Richard: En tant que développeur senior, le mentorat est une tâche principale. On ne vieillit pas en vieillissant et en se faisant barbe. Si vous ne pouvez pas être mentor, n'entrez pas dans ce rôle. "Juste" être développeur.
back2dos

1
@Richard Habituellement, la conversation se passe comme suit: Développeur principal: "Ces gars-là écrivent des interfaces terribles! Ça fout tout ce que j'ai conçu l'année dernière." Moi: "Vous savez, si vous voulez que les nouveaux gars écrivent des interfaces plus propres, vous voudrez peut-être vous asseoir avec eux et expliquer votre pensée."
Christopher Bibbs

7

Les développeurs seniors devraient-ils être appelés à encadrer les développeurs juniors?

Absolument pas. Certains bons développeurs seniors vont être d'horribles mentors et la confrontation de personnalités est un must have pour réussir le mentor. Je pense cependant que les développeurs seniors devraient être tenus de faire quelque chose au sujet de l'équipe de développement. Cela pourrait être le prototypage de quelque chose en marge, l'amélioration d'un processus ou d'une pratique, la mise au point de nouveaux outils, la présentation de matériel technique au groupe, la direction d'une équipe ou autre chose. En d'autres termes, ils devraient avoir la responsabilité de quelque chose de plus grand que le partage de travail individuel.

Ou ce mentorat devrait-il être quelque chose de plus organique et spontané, c'est-à-dire non requis, mais autorisé à se développer sans encouragement artificiel?

Non, je ne suis pas d'accord non plus avec cette prise. J'ai vu trop de situations où le mentorat devrait être «organique et spontané» et cela arrive trop rarement. Je pense que les organisations doivent assumer la responsabilité de donner au mentorat une chance de devenir contagieux - mais cela ne peut pas être forcé. C'est difficile, mais ça vaut le coup. Je pense que l'organisation pourrait faire des choses comme:

  • Rencontres informelles entre les mentors potentiels et les protégés potentiels
  • Moyens et opportunités suggérés pour que le mentorat soit officiellement reconnu par l'organisation (par exemple, si vous êtes un endroit qui a un numéro de facturation pour pratiquement tout, créez un numéro de facturation pour les réunions de mentorat - clarifiant qu'il s'agit d'une partie viable du travail )
  • Formation et soutien aux mentors
  • des conseils aux protégés pour savoir comment sélectionner un mentor et à quoi s'attendre
  • conseils aux mentors sur ce à quoi s'attendre et quoi offrir
  • Modèles suggérés (ou appliqués) pour le mentorat avec des modèles de participation - par exemple, il est beaucoup plus facile de lui donner une chance si vous savez à l'avance que votre objectif est une expérience de 3 mois avec des rencontres hebdomadaires et un objectif d'aider un nouveau développeur à se lever et aller dans l'entreprise. Cela ne veut pas dire que cela ne deviendra pas plus ... mais cela donne une place aux gens pour commencer.

5

Je pense que ce qui en fait une exigence pourrait potentiellement se retourner contre, car certaines personnes ne sont tout simplement pas câblées de cette façon, et seraient très découragées par l'idée. Cela étant dit, vous devez identifier les personnes qui, selon vous, sont aptes à être des mentors et les approcher pour qu'elles jouent un rôle plus actif dans le mentorat (si ce n'est déjà fait). Cette approche par l'exemple pourrait se développer et inspirer un mentorat plus spontané.

Vous pouvez également planifier des activités de groupe régulières, ce qui aidera l'équipe à se gélifier. Il peut s'agir d'activités entièrement sociales, comme un déjeuner d'équipe, ou d'activités qui intègrent l'apprentissage de la programmation, comme un club de lecture de programmation hebdomadaire.

Vous pouvez également avoir des "mini post-mortems" réguliers sur les systèmes, qui fonctionneraient comme une révision de code de groupe. L'un des avantages de la révision en groupe est que tout le monde peut bénéficier des commentaires, plutôt que de la seule personne qui a écrit le code d'origine. Vous pourriez avoir besoin de trouver des bénévoles qui se sentent à l'aise pour que leur code soit jugé afin de démarrer les choses, et assurez-vous de maintenir la civilité.


4

Je n'ai jamais aimé les termes programmeurs junior et senior. Par exemple, je programme depuis un certain temps et même si j'ai de l'expérience dans certains domaines, je suis très vert dans d'autres. Par exemple, nous passons à WPF et bien que j'ai une tonne d'expérience dans l'application de formulaires Windows, WPF est encore nouveau et me pardonne. Donc, bien que je sois un programmeur "senior", vous pourriez embaucher quelqu'un de la rue avec beaucoup moins d'expérience "totale" et il pourrait probablement programmer une application WPF mieux et plus rapidement que moi à ce stade.

Cela ne veut pas dire que je n'ai pas beaucoup de bonnes expériences de conception et d'architecture d'application qui pourraient être appliquées à l'application WPF, mais je connais mes limites.

Je suppose que vous devez être disposé à être le mentor à certains moments et le mentoré à d'autres.

Si vous avez des membres de l'équipe qui n'ont pas peur d'être le mentor lorsqu'ils ont les connaissances et un mentoré chez les autres lorsqu'ils en ont besoin, vous vivrez une expérience fructueuse.

Si vous pouvez favoriser ce type d'environnement de développement où les développeurs sont humbles et ouverts à de nouvelles idées et aident les autres en cas de besoin, les relations sempai-kohai sortiront naturellement.

Forcer le mentorat créera probablement un système de castes dont les développeurs pourraient se ressentir. Il vaut mieux traiter chaque développeur de la même manière au même niveau.

Cette industrie est très différente. La sénorité n'est pas toujours meilleure.

Parfois, les seniors doivent être encadrés par les juniors.


Cette réponse mérite plus que le +1 que je peux lui donner.
Peter Taylor

3

J'ai été dans des environnements qui font les choses dans les deux sens.

Le premier travail que j'ai eu hors de l'école, on m'a assigné un mentor. Je n'aimais pas le gars et je n'étais certainement pas d'accord avec lui sur tout. Je n'aimais pas être obligé de travailler avec lui, et j'étais presque sûr que mon employeur avait fait une erreur, mais rétrospectivement, j'ai beaucoup appris.

Avance rapide de quelques années, et maintenant je suis dans une entreprise qui traite les développeurs avec une attitude chacun pour soi. Les développeurs sont soumis à des délais serrés, et peu ou pas d'allocations sont accordées aux développeurs qui passent du temps à prendre d'autres sous leurs ailes pour leur montrer les cordes. Je pense que c'est dommage. Je vois comment les développeurs juniors ont du mal avec les mêmes choses que moi, mais sans mentor pour les aider, cela leur prend beaucoup plus de temps.

J'ai acquis une réputation de «mentor» parce que les nouveaux employés «semblent apprécier l'aide que je peux leur fournir». Pour autant que je sache, c'est une façon sophistiquée de dire aux RH que je suis prêt à tolérer des évaluations de productivité médiocres afin que je puisse faire la bonne chose, qui est de permettre aux développeurs juniors de faire leur travail efficacement et de s'améliorer rapidement.

Je pense que c'est ce que nos employés juniors méritent, et avec le recul et l'expérience, je pense que la première entreprise pour laquelle je travaillais et le gars qui m'a encadré avaient beaucoup plus compris que je ne le pensais à l'époque.

Tout cela est la longue façon de dire que même si je souhaite que vous n'ayez pas à affecter de mentors, c'est probablement le seul moyen équitable de se répandre dans le travail. Si vous ne le faites pas, vous devriez donner aux personnes qui le font leur dû. Ce n'est pas un travail facile; il nécessite à la fois des compétences interpersonnelles et des compétences en ingénierie; et cela prend du temps.


3

Les développeurs seniors devraient aller au-delà du barattage du code. Cependant, la direction à suivre ne doit pas être la même pour tous les développeurs seniors.

Certains sont bien adaptés au mentorat. D'autres ne le sont pas et devraient poursuivre un autre objectif de niveau supérieur, qu'il s'agisse de planifier et de mettre en œuvre des améliorations architecturales, ou d'évaluer de nouvelles technologies, ou de planifier et de diriger des améliorations de processus (par exemple, intégration continue, TDD, etc.)

Fondamentalement, un senior ne devrait pas être seulement quelqu'un qui coupe le code depuis quelques années de plus que les juniors. Ce devrait être quelqu'un qui est disposé et capable d'assumer des responsabilités supplémentaires qui contribueront au succès de l'équipe. Le mentorat des juniors est important, mais ce n'est pas la seule chose importante, et ce n'est pas quelque chose auquel tout le monde est bien adapté.


3

Obliger un tel mentorat est contre-productif car les êtres humains luttent tout naturellement contre les activités, les actions et les relations forcées. Une meilleure approche consiste à récompenser les personnes qui font du bon mentorat, amenant ainsi les gens à vouloir être mentor.

Bien sûr, cela pose le problème de la mesure du «bien» dans ce contexte. Une solution imparfaite, mais facile à mettre en œuvre pourrait être de demander aux nouveaux arrivants après un an (éventuellement de manière anonyme) d'écrire les noms, disons, des trois principales personnes qui les ont aidés à s'intégrer dans l'entreprise et / ou la base de code. Après cela, vous pouvez récompenser les personnes dont les noms sont les plus mentionnés. Cependant, les récompenses monétaires ne fonctionneront pas ici. Il vaut mieux trouver une sorte de récompense sociale.


3

l'équipe mène la structure, menant à des revues de code devrait faire l'affaire ...

Vous auriez un membre senior de votre personnel responsable d'un ou plusieurs juniors. Je ne pense pas que ce soit une aide spontanée, mais plutôt un processus formel; en ce sens que le membre senior sera responsable de la qualité du travail produit par les nouveaux venus. Cette approche a 2 avantages (au moins): former les seniors aux styles de management et s'assurer que les juniors produisent un code de qualité.


J'ai intégré votre commentaire qui a fourni des informations supplémentaires dans votre réponse. À l'avenir, si quelqu'un vous demande de clarifier ou d'élaborer sur un point, veuillez modifier votre réponse pour inclure les nouvelles informations. De cette façon, les personnes qui visitent cette question plus tard peuvent voir une réponse complète de votre part sans avoir à fouiller dans les commentaires.
Adam Lear

2

Dans toute programmation, cela dépend . Mais je voudrais vraiment qu'un développeur senior encadre de nouvelles recrues, qu'elles soient juniors ou non, pour leur donner la meilleure formation pour le travail à accomplir.


2

Non, car cela impliquerait que le nombre de développeurs seniors et juniors soit toujours le même. Je pouvais voir encourager les développeurs seniors qui veulent être des mentors, mais appliquer un jumelage pourrait être une très mauvaise idée. L'idée de soutenir les relations de mentorat est bonne et ne devrait pas être rejetée ici.

Cependant, l'encouragement artificiel n'est pas une mauvaise idée. Dire à tous les développeurs juniors et seniors qu'ils vont être des mentorés et des mentors peu importe ce qui pourrait être un peu religieux et se retourner contre eux assez rapidement.


S'il existe un cadre connu au sein de l'entreprise sur la façon de gérer le mentorat, ce serait formidable. Cependant, si cela n'existe pas, la clé devient d'avoir différents types de moments entre le mentor et le mentoré:

  1. État actuel - Où en sont les choses maintenant? Quel est le défi actuel que le mentor peut aider à résoudre?
  2. État futur - Ce qui est recherché: un indice, une solution, des questions à poser, à qui demander?
  3. Rétrospective - Qu'est-ce qui a fonctionné et n'a pas fonctionné pour apporter des changements?
  4. Changements futurs - Qu'est-ce qui sera essayé à l'avenir qui pourrait mieux fonctionner que ce qui a été fait auparavant?

Au moins ce sont des états que je peux voir et donner un sens à mon avis pour adopter une approche descendante logique. D'autres peuvent vouloir quelque chose de beaucoup plus organique et de forme libre qui peut également fonctionner. L'essentiel est de se faire une idée de comment obtenir de chaque côté des compétences qui devraient être perfectionnées par la pratique de la communication dans cette relation. Chaque partie devrait tirer quelque chose de la relation et il devrait y avoir des règles de base communes pour avoir ce type de relation, car la rétroaction est un gros problème ici.

Combien de temps on y passe est une question juste qu'il faut en réalité regarder ce qui est fait et dans quelle mesure il est acceptable de passer du temps à développer des compétences et à établir des relations. Je pouvais voir des paires qui voulaient une heure par semaine pour passer par là, tandis que d'autres voudraient peut-être quelques heures par jour pour couvrir cela. N'oubliez pas qu'il peut y avoir d'autres interactions où un senior et un junior peuvent travailler ensemble mais pas dans une relation de mentorat formelle.


1
Ouais je vois ça. Je me demande comment vous encouragez le mentorat et les mettez à l'aise pour prendre du temps de travail rémunéré pour le faire?
richard

2

J'ai vu quelques tentatives différentes de systèmes de mentorat. Ceux que j'aimais le plus étaient ceux où le développeur senior avait un ensemble spécifique de tâches qu'ils ont effectuées pour aider le développeur junior, ce qui a ouvert la voie au mentorat sans l'exiger. Par exemple, un réviseur de code en tête-à-tête pour le développement principal assigné pour les six premiers mois pourrait être très utile et mènerait probablement au mentorat. Ceux que je n'aimais pas étaient ceux qui me semblaient être un travail très chargé et qui ne semblaient pas être directement liés au travail effectué - par exemple, rencontrer votre mentor assigné pendant une demi-heure chaque semaine. C'était particulièrement ennuyeux lorsque les deux membres de la relation de mentorat n'interagissaient généralement pas entre eux pendant la semaine et n'avaient rien à voir avec leurs projets respectifs. Il se sentait très forcé et délicat plutôt que concentré sur une croissance professionnelle. La dernière chose que vous souhaitez, c'est qu'une relation de mentorat ressemble à une séance de conseil.

IME, vous ne pouvez pas compter sur le développement de relations de mentorat, donc fournir un mentor potentiel en associant un développeur senior et un développeur junior pour un ensemble d'activités commerciales jumelées normales (révision de code, débogage, programmation de pair, etc.), au moins au est d'abord une excellente idée. Idéalement, le membre senior devrait se porter volontaire pour le rôle et devrait pouvoir percevoir un avantage personnel. Dans mon entreprise actuelle, les développeurs seniors sont presque des chefs de file pour leurs projets, et l'avantage est qu'ils constituent leur propre équipe de projet. Dans l'autre entreprise, les mentors enquêtaient souvent sur la voie de la gestion.


2

Je pense que chaque entreprise qui embauche de jeunes développeurs devrait avoir une sorte de programme de mentorat raisonnablement efficace. Mais je ne suis pas sûr que la position par défaut devrait être que chaque développeur senior devrait le faire pour la simple raison que de nombreux développeurs, peu importe leur niveau de développement, sont moche pour le mentorat. Cela va malheureusement avec le territoire. Certains d'entre nous ne sont tout simplement pas des gens formidables, si vous voulez.

D'un autre côté, là où il y a des gens qui sont bons dans ce domaine, ils devraient être reconnus pour cela, et non des points noirs parce que leur sortie de développement réelle tombe pendant qu'ils expliquent un problème localisé simple concernant, oh la mise en œuvre de l'IDE à un débutant qui a toujours utilisé NotePad et Javac, par exemple.

Cela nécessite une gestion équilibrée. Je ne suis pas certain que ce soit courant.


2

Pour que tout mentorat fonctionne, il est essentiel que la direction reconnaisse que c'est important et y consacre du temps, et l'encourage activement!

Pour toute personne réservée à 100% avec des affectations, il n'y a littéralement pas de temps pour faire ou recevoir du mentorat, et cela ne se produira pas.


1

En règle générale, les navires de mentorat sont un bon tremplin pour la transition du niveau supérieur au chef d'équipe ou au gestionnaire. Il est plus efficace de lier le mentorat à l'avancement dans un PDP (Personal Development Plan) ou quel plan de mérite que votre entreprise utilise. Lier leur augmentation de salaire et leur évolution de carrière au moins en partie à leur capacité à transmettre des connaissances et à former de nouveaux développeurs est essentiel pour construire un personnel informatique solide qui peut résister aux changements de gestion et de rotation du personnel. Fournir des objectifs clés et travailler avec le personnel pour l'aider à s'améliorer fait partie de cette croissance du leadership. Pour ceux qui pensent qu'il n'est pas juste de lier une évaluation senior à une performance junior qui fait partie de la croissance. Dans la plupart des cas, vous ne parlez pas d'une réduction de salaire, mais plutôt d'une augmentation réduite ou d'un avancement ralenti.


0

La première fois que j'ai rejoint l'équipe, le propriétaire et un développeur principal m'ont donné des instructions. Je pourrais demander n'importe quoi à l'un et à l'autre et ils répondraient tous les deux. Cependant, j'étais assez respectueux pour ne pas les déranger à moins que je ne puisse pas le comprendre en temps opportun.

Cela a très bien fonctionné mais là encore, vous avez probablement besoin de gens sympas avec un sens de l'humour pour que cela fonctionne.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.