En tant que développeur de logiciels, j'ai occupé à la fois votre poste et celui de Dave. Dans les équipes de développement logiciel qui travaillent ensemble depuis longtemps, chaque collègue commence à développer une idée de qui est le `` go-to '' pour les connaissances sur un projet ou un système particulier (surtout si c'est quelque chose de tellement ésotérique que StackOverflow ne peut pas aider !). C'est formidable que Dave soit bien qualifié et qu'il apprenne rapidement les choses, mais dans les cas où le temps pourrait être contre eux, un collègue peut simplement rechercher celui qu'il sait avec certitude a l'expérience de ce qu'il était collé sur. Cela ne s'applique pas uniquement aux apprentis ou aux développeurs juniors. Dans un emploi, malgré le fait d'avoir deux développeurs seniors au-dessus de moi, mes collègues me posaient des questions sur les problèmes C # simplement parce que j'étais le «C # guy». J'ai dû leur faire comprendre au fil du temps que les autres en savaient assez aussi.

Une solution pourrait être de rendre votre équipe plus consciente de ce sur quoi Dave a travaillé (pas seulement les réalisations). On dirait que votre collègue ne savait pas ou devait se rappeler que Dave avait suivi un cours pertinent sur quelque chose. Il peut également être intéressant de demander à Dave, par exemple, d'observer un collègue sur une tâche JavaScript après avoir terminé un cours JavaScript. Cela aidera Dave à se faire un nom au sein de l'équipe et rendra vos collègues plus convaincus qu'il est plus qu'un simple livre intelligent, et donc plus susceptible de demander son aide le moment venu. Cela peut même être démontré en donnant à Dave la chance de travailler sur une tâche de haut niveau ou importante (si vous sentez qu'il est prêt).

Plus Dave s'intègre à l'équipe, plus ils en viendront à reconnaître et dépendre de ses connaissances. Comme Dave a plus de chances de démontrer des connaissances qui ne peuvent provenir que de son travail avec votre équipe de développement, plus il est probable qu'il sera sollicité pour obtenir des conseils.

Quand j'ai commencé mon apprentissage en tant que développeur de logiciels, j'étais dans une situation similaire. Même si je n'avais aucune qualification «sur papier», j'avais une grande expérience privée du développement de logiciels. Personne ne m'a cru. J'ai donc demandé au développeur senior le plus respecté de l'équipe sur quoi il travaillait et si je pouvais y jeter un œil. J'ai ensuite passé le lendemain à analyser le code source à la recherche de la pire partie que je pouvais trouver. Puis je l'ai approché et lui ai demandé:

Salut [développeur senior]. J'ai regardé votre code source et il y a une chose que je ne comprends pas. Quelle est la raison pour laquelle vous n'avez pas utilisé [solution plus efficace] ici? Je suis sûr qu'il y a une bonne raison pour laquelle vous avez utilisé [solution inefficace]. Mais je ne connais pas cette technologie aussi bien que vous. Alors j'aimerais vraiment savoir pourquoi vous avez fait ça.

Maintenant, il n'avait bien sûr aucune raison de le faire de manière inefficace. Le moyen efficace ne lui est tout simplement pas venu à l'esprit. À ce moment-là, il a compris que je suis bien plus capable que mon titre de poste ne le dirait, mais la façon dont je lui ai montré était soumise et non conflictuelle, donc il ne me percevait pas non plus comme une odieuse je-sais-tout.

Cinq ans plus tard, j'ai obtenu son poste. *

* _{non, ne vous inquiétez pas. Je ne l'ai pas intimidé. Il a obtenu une offre d'emploi encore mieux rémunérée ailleurs.}

Une chose que vous devriez enseigner à Dave est l'importance de la visibilité sur le lieu de travail. Les gens peuvent le sous-estimer parce qu'ils ne sont pas conscients de ses talents et le jugent simplement en fonction de l'intitulé de son poste.

Ce que vous voudrez peut-être l'encourager à faire:

• Faites des présentations devant l'équipe. Dissimulez-le comme un exercice pour tester les compétences en présentation.
• Recherchez des projets internes qui présentent un intérêt pour la direction.
• Résolvez des problèmes de longue date que tout le monde a peur de résoudre.

Cela vaudrait la peine de parler au responsable de Dave et / ou au responsable de l'équipe de développement (s'ils sont des personnes différentes) spécifiquement sur ce sujet, et pas seulement dans le cadre d'une conversation informelle.

Avec le responsable de l'équipe de développement vous devriez mettre en évidence ce problème que vous avez vu et suggérer qu'ils recherchent des opportunités non seulement pour lui de grandir et de contribuer, mais pour lui de prendre la responsabilité réelle de quelque chose. Il sera beaucoup plus difficile de se mettre à l'écart par inadvertance du fait qu'il est le spécialiste d'une technologie particulière ou qu'il occupe un poste de responsabilité dans un projet. Cela a également l'avantage d'être un très bon apprentissage de la prochaine étape pour lui.

Avec son propre manager, cela peut être sous la forme de commentaires pour sa prochaine évaluation et peut-être même d'une recommandation de promotion / changement de titre / augmentation de salaire / bonus / repenser ses opportunités de développement de carrière à la lumière de ses progrès exceptionnels.

Vous devriez également lui proposer de l'encadrer si personne d'autre ne le fait.

Le cas échéant, vous pouvez également offrez-lui / demandez-lui de se joindre à vous avec une partie de votre travail afin de lui permettre de s'entraîner, d'acquérir une expérience plus large, de contribuer là où il est apprécié et d'obtenir une plus grande visibilité.

Peut-être que certaines personnes dans l'équipe ne veulent pas d'un apprenti brillant. Que devrait penser le patron si l'apprenti fait certaines choses mieux que les soi-disant membres expérimentés de l'équipe? Et l'apprenti est probablement payé une fraction de ce que reçoivent les experts.

Il semble que l'apprenti est trop bon pour cette équipe. Ils veulent quelqu'un qui n'est pas bon et qui n'apprend pas vite. Ils veulent quelqu'un qui demande aux experts et qui n'a pas de bonnes idées que les experts n'ont pas.

Je suppose que vous avez le choix d'être du côté de l'équipe ou du côté de l'apprenti et contre l'équipe ...

Donnez-lui du temps

Bien qu'il existe de nombreux programmeurs qui essaient de garder une longueur d'avance en adoptant de nouvelles techniques, d'après mon expérience, j'ai conclu qu'en général:
Les programmeurs qui n'ont jamais / pas expérimenté de nouvelles entrées comme le statu quo.

Ils n'aiment pas les nouvelles techniques / programmes / méthodes / ... ils savent comment les actuels se comporter et quels quircks ils ont. Le passage, par exemple, à un nouveau style de programmation pourrait demander un certain effort et l'OMI encore plus d'efforts de la part des personnes âgées. Et maintenant, imaginez un nouveau type au hasard le dire. Et il reçoit tous ces éloges pour cela aussi, où ils maintiennent un équilibre qui n'est jamais complimenté ¹ !

Je n'aime pas utiliser de clichés, mais c'est une situation où ' le respect »doit être mérité. Premier spectacle, c'est une équipe qui joue, une approche un peu plus passive. Après un certain temps, il apparaîtra compétent, même sans montrer le code. Après un moment, s'il a ses propres tâches, il pourrait lancer un "hé, j'ai écrit cet extrait, j'aimerais que vous en pensiez". De cette façon, il peut montrer son niveau et en même temps apprendre comment le reste de l'entreprise fonctionne (toutes les nouvelles idées semblent bonnes, mais sont-elles adaptées?).

Après un certain temps, le statu quo va l'inclure. D'après mon expérience, plus vous poussez le changement, plus vous êtes réticent. Trouvez le flux, rejoignez-le, influencez-le.

¹ Peut-être incorrect, mais cela explique un peu l'émotion.

Cette réponse est basée sur mon expérience d'apprenti.

Fraîchement sortie de l'école avec les A-Levels j'ai obtenu un poste d'apprenti dans une société de conseil multinationale, nous avons suivi une période de formation initiale la plus dont ne s'est pas étendu de manière significative sur mes connaissances autodidactes déjà existantes. Mais ce que cela a donné, c'est l'accès à des mentors dont le rôle était de fournir des conseils, de répondre à des questions techniques et conceptuelles, et dont l'influence a grandement contribué à ma croissance.

Lors de mon lancement dans l'entreprise principale, j'ai été placé dans l'équipe «innovation», il y avait beaucoup de choses passionnantes en cours de développement auxquelles nous ne pouvions participer que superficiellement en raison de notre besoin de progresser dans le cours d'apprentissage & du «programme de formation».

Pendant mon séjour, je suis entré dans des discussions avec le chef d'un service sur l'intégration, et leur a confié la tâche de développer un prototype d'application d'intégration. J'ai trouvé quelques apprentis avec qui diriger ça à côté et tout se passait bien.

Après une période de développement pendant mes soirées, je me suis rendu compte qu'il me manquait probablement certaines connaissances qui amélioreraient le processus de développement, des informations techniques concernant les technologies de l'époque telles que Angular, que l'équipe d'innovation utilisait sur une base quotidienne. J'ai contacté l'ingénieur principal de l'équipe pour obtenir des conseils, on m'a dit qu'il ne me laisserait pas de temps car je n'avais pas encore terminé le cours (ce qui ne m'intéressait pas, je préfère coder), et j'ai ensuite été interviewé par lui sur la façon dont on m'avait assigné ce projet plutôt que sur l'équipe dans son ensemble, il ne comprenait pas pourquoi un chef de département me choisirait pour gérer cela et voulait en revendiquer la propriété.

Cela m'a considérablement démoralisé, j'ai continué sans conseils sur le développement mais je ne savais pas comment gérer cette situation ou chercher de l'aide ailleurs. À cette époque, je traversais une rupture avec un partenaire de longue date, ce qui, combiné au fait d'être loin de chez moi et d'avoir peu de soutien émotionnel, signifiait que je commençais à arriver tard au travail (même si je partais toujours en dernier). Une semaine ou deux de cela, un rendez-vous médical manqué (j'ai commencé à utiliser mon état actuel comme béquille pour expliquer mes arrivées tardives), j'ai été entraîné par moi-même à une réunion des ressources humaines et j'ai eu la possibilité d'être renvoyé sur place ou de signer ma lettre de démission, j'ai rédigé mon e-mail de démission dans la salle d'entrevue car je sentais que je n'avais pas d'autre choix et que j'étais parti avant le déjeuner.

Mon responsable, l'équipe, le chef de l'autre département, personne sachez que cette action RH était prise contre moi, le responsable RH qui m'a fait ça a été relâché peu de temps après.

Bref, si possible essayez de le protéger, portez sa situation à la conscience du supérieur et mettre en lumière son potentiel au sein de l'organisation dans un rôle en dehors de l'apprentissage lui-même, lui expliquer la bureaucratie et comment y exister, tout en le guidant vers des mentors et en étant conscient de sa situation, il est probablement plein d'optimisme et courage, mais il y a une ligne fine entre les défis passionnants et se laisser dépérir au sein d'une société sans le soutien ou la promotion de ses talents.

Vous et Dave devriez être plus directs dans votre offre d'aide.

Dave est entouré d'ingénieurs logiciels chevronnés. Leur dire "je sais quelque chose" est facilement ignoré (peut-être par fierté, peut-être parce qu'ils ne voient honnêtement pas comment Dave pourrait les aider). Leur dire "Vous devez utiliser X de cette manière et Y d'une autre manière pour accomplir Z" est très concret, prouve ses connaissances et rend difficile son rejet.

La même chose s'applique à vous. Demander à un ingénieur senior "avez-vous demandé à Dave" peut être compris comme

• "Prenez Dave sous votre aile et essayez de résoudre le problème ensemble" - ce qui peut ne pas sembler très raisonnable
• "Avez-vous essayé de demander de l'aide à vos collègues au hasard?" - ce qu'il a fait, il a juste demandé au hasard à un autre collègue
• "Je sais que Dave sait comment vous aider"

Au lieu de cela, dites-leur "Dave a mentionné qu'il connaissait une solution à votre problème."

Bien que je sois d'accord avec à peu près toutes les réponses déjà ici, avec les conseils suivants:

• Donnez-lui du temps
• Le «respect» se gagne au fil du temps
• Rendez-le médior / senior
• Attribuez des tâches plus importantes / plus complexes
• Demandez à Dave de faire de la programmation en binôme avec les autres / seniors

Je pense qu'il manque quelque chose. Dans votre question, vous mentionnez que vous avez déjà essayé ceci et cela:

J'ai déjà essayé d'expliquer à tout le monde à quel point il est bon et les réalisations qu'il a réalisées en si peu de temps temps, en vain. Il veut vraiment faire bonne impression pour aider à démarrer sa carrière, mais a du mal à ne pas l’écouter.

Il y a 2 choses qui ressortent, dont 1 devient un question:

1. "[...] relance sa carrière mais trouve difficile qu'il n'ait pas été écouté"
2. Vous avez essayé d'expliquer - Depuis combien de temps cela dure-t-il?

Si c'est "assez long" (remplissez ce montant en vous-même, vous êtes le meilleur juge de la situation), j'en viens à ce conseil:

Dites-lui de trouver un emploi ailleurs.

Je veux dire cela dans le meilleur des cas pour Dave. Si vous avez essayé ce qui précède et que vous avez probablement essayé la plupart des conseils / réponses à votre question, dites-lui de simplement partir. Les développeurs de logiciels sont rares, être quelque part où vous n'êtes pas écouté est nul. Ok ok, tu écoutes, mais "le reste" ne le fait pas, ça craint.

Quoi qu'il en soit, c'est ce que je ferais si j'avais un stagiaire qui devenait un peu plus stagiaire et que cela se produise. Je lui dirais aussi de me mettre comme référence et de ne plus postuler à des emplois de stagiaire; minimum junior (basé sur le temps passé dans les emplois, les managers ont tendance à faire tourner leur culotte par rapport aux «trop» jeunes médians / seniors).

Pourquoi Dave est-il encore un junior s'il peut surpasser les cadres supérieurs et reprendre les choses rapidement? La seule façon que je vois pour forcer cela est de faire de Dave un développeur senior ou de niveau intermédiaire et de lui attribuer des tickets de bogue - en supposant que vous utilisez Scrum ou Kanban -.

À part cela, vous avez juste besoin pour améliorer sa réputation avec des choses qui comptent réellement; réalisations, pas des notes standard dans les cours standard.

Être un développeur senior ou un chef d'équipe plus que des compétences en programmation, il y a la communication, la responsabilité et la responsabilité des démarreurs en tant que développeur senior dont vous êtes plus responsable et que vous êtes davantage une personne à contacter. .. tout, vous ne pouvez généralement pas choisir et choisir.

Ensuite, il y a des modèles d'architecture / échoué à), mais le moment où vous leur demandez de concevoir quelque chose est un moment WTF pour le dire gentiment.

Alors, que devrait faire Dave? Faites une grande partie des problèmes qu'il résout, démontrez une compréhension, plutôt que de dire "c'est fait" (qui est synonyme de "c'était simple"), montrez une compréhension du système et produisez du code avec un minimum de bogues.

Que devez-vous faire? Encouragez Dave à expliquer sa résolution de problème au reste de l'équipe. De plus, s'il a acquis les compétences dont il estime avoir besoin, vous devriez l'encourager à postuler pour un poste de non-apprenti là-bas ou ailleurs.

Dave pourrait utiliser l'effet Ben Franklin ... on dirait qu'il est un peu du mauvais côté en ce moment.

L'idée est que nous aimons croire que nous sommes justes, donc si nous faisons une faveur à quelqu'un, nous rationalisons inconsciemment qu'il doit être une bonne personne qui mérite une faveur, et inversement si nous faisons du mal à quelqu'un (même par accident), nous essayons de rationaliser qu'il méritait en quelque sorte d'être blessé.

Pièges à surveiller: si vous demandez trop de faveurs, ou trop de faveurs, cela ne fonctionne pas. Si vous faites des choses de manière préventive en retour, cela ne fonctionne pas. Et si un tiers neutre demande des faveurs en votre nom, cela ne fonctionne pas (et peut être préjudiciable).

Il semble que vous et Dave apparteniez aux catégories deux et trois. Le grand arriéré de faveurs de Dave qu'il a fait pour les autres leur laisse le sentiment qu'ils lui doivent, ce qui le rend moins populaire. Et votre encouragement en tant que tiers le rend moins populaire.

Si Dave, en revanche, demande à être montré ou enseigné quelque chose, la personne qui montre / enseigne 1) se sentira bien pour Dave parce ils lui ont rendu service, 2) se sentent bien dans leur peau parce qu'ils avaient des connaissances utiles, et 3) pensent peut-être que Dave est intelligent, s'il pose de bonnes questions et apprend rapidement.

Malheureusement, Dave ne l'est pas ici, mais mon conseil pour vous est d'arrêter de pom-pom girl Dave assez fort - c'est-à-dire d'arrêter d'élever Dave chaque fois que quelqu'un a besoin d'aide. Si Dave vous aide, alors c'est bien de le mentionner, ou si Dave fait vraiment bien sur un projet solo - mais à peu près au même niveau, vous mentionneriez n'importe quel autre coéquipier.

À la place, essayez d'amener Dave à parler à d'autres coéquipiers en tant qu'apprenti, plutôt qu'en tant qu'enseignant. Par exemple, il existe toujours des connaissances spécifiques au domaine qui ne sont pas disponibles dans les ressources écrites. Si Dave rencontre des problèmes comme celui-là, vous pouvez le diriger vers un collègue qui est à la fois bien informé et qui sera probablement flatté par le fait qu'il pose des questions. ("Vous devriez demander à Sally et Bob - ils ont travaillé là-dessus à l'origine et connaissent tous les détails difficiles sur les raisons pour lesquelles certaines choses sont telles qu'elles sont.")

https: // fr. wikipedia.org/wiki/Ben_Franklin_effect#Uses

Cela a toujours été le plan que je devrais simplement convaincre les meilleures personnes de l'industrie - PDG, CTO, universitaires, consultants de haut niveau, chefs de secteurs gouvernementaux ayant besoin de technologies de pointe, et plus ou moins faire dire à tout le monde. ce qu'ils veulent dire. Ensuite, j'aurais une startup et quand je commencerais à gagner de l'argent (beaucoup), cela devrait parler très fort.

Mais les choses ont changé depuis. Un ridicule excessif avait usé ma crédibilité et celle de mon produit. Au début, j'étais très, très opposée à ce que mon travail soit montré en public, mais je me suis calmé quand j'ai trouvé que cela contredisait ces fausses rumeurs sur mon travail. Avec la rapidité avec laquelle je me suis détendu, je ne me suis même pas rendu compte que cela me dérangeait autant que ma capacité soit remise en question.

En ce moment, il y a même de bonnes chances que je perde et que cela élimine le dissuasif. Les gens que j'ai mis en colère feraient alors tout ce qui était en leur pouvoir pour m'empêcher de lancer ma startup.

A propos de ces programmes "David" a écrit. Si ces programmes ne sont pas plus de plusieurs centaines à des milliers de LOC, alors je doute de ce qu'il a résolu un problème louable. Et pour vous décevoir, c'est soit j'écris des logiciels de taille (ENR étant toujours le plus gros) sous forme de produits ou de petits wrappers pour les outils Unix et autres. Je ne me dérange pas avec un petit programme vous invitant à entrer des valeurs via la CLI, en faisant des choses mineures.

J'ai un dossier de mes solutions aux problèmes combinatroniques - permutation, combinaisons, résolus avec de petites fonctions. Les fichiers de test C correspondants aux fonctions sont les seuls petits programmes que je possède. Au tout début de ce voyage, je pensais que j'allais avoir besoin de ces fonctions. Cela ne s'est pas avéré être de cette façon. Eh bien, il fallait de toute façon l'écrire.