Reprise de la confiance du programmeur principal [clôturé]

Mon patron a découvert que je ne suis pas aussi intelligent qu'il le pensait.

Un exemple de mon expérience:

Je suis programmeur junior et je travaille en équipe de deux, mon patron (programmeur senior) et moi-même.

J'ai été chargé de développer une application web interne pour l'entreprise dans laquelle nous travaillons. J'ai écrit le back-end au front-end (la conception de la base de données était déjà en place et la technologie du serveur avait été choisie). Il vérifierait périodiquement mes progrès en observant l'application Web en action et était satisfait de son avancement. Lorsque j'ai terminé l'application Web, il était satisfait de la qualité du produit final.

Il y a quelques jours, il s'est intéressé au code, alors je lui ai dit quelles technologies j'utilisais (pour le front-end), et c'est là qu'il est allé vers le sud. Pour le front-end de l'application web, j'ai utilisé un framework Javascript (Backbone.js). Lorsqu'on m'a demandé pourquoi je ferais une telle chose. Ma réponse était parce que je sentais que le cadre s'intégrait assez bien dans cette application et m'aiderait à mieux structurer le code que si je l'écrivais à partir de zéro ... "Eh bien, c'est décourageant" était sa réponse.

Donc, étant donné cet exemple, ma question est:

Si vous êtes un programmeur senior et que vous avez perdu confiance en la capacité de votre programmeur junior, que souhaiteriez-vous que votre junior reprenne confiance?

EDIT : Merci à tous pour les bonnes réponses et les commentaires positifs!

S'il a aimé le produit que vous avez construit, mais qu'il est coincé dans votre utilisation de Backbone, vous devez tous les deux avoir une conversation sur la pile technologique souhaitée.

En tant que développeurs, nous devons utiliser des outils facilement disponibles et, par conséquent, déplacer en douceur notre flux de travail. S'il s'attendait à ce que vous construisiez le front-end à partir de zéro, il aurait dû être explicite et avoir une bonne raison.

Le fait qu'il ait d'abord apprécié le produit est une preuve suffisante que vous avez bien fait et que vous êtes suffisamment «intelligent».

tl; dr Vous avez bien fait. Parlez à votre aîné et voyez ce qu'il attend de vous.

Il ne me semble pas très "senior" pour émettre un jugement instantané comme ça. J'ai toujours tendance à utiliser un cadre approprié au lieu de l'anti-motif "Réinventer la roue carrée". S'il était vraiment senior, il comprendrait et connaîtrait la valeur d'un bon cadre. Au mieux, je m'attendrais à ce qu'il remette en question le choix de Backbone.js par rapport à un autre framework JavaScript MVC et bien plus tôt dans le processus. Il a échoué dans le mentorat et le contrôle de vous en tant que junior et vous a aidé sur le bon chemin de développement (dans son esprit).

Il semble que vous ayez fait le bon choix dans le développement du projet étant donné le manque de direction de sa part (hypothèse) et que vous travaillez à devenir un développeur plus compétent. Je pense qu'il pourrait être utile de lui expliquer votre choix de cadre, pourquoi vous pensez qu'un cadre était approprié, et de souligner que le projet a été fait et à sa satisfaction en partie en raison de l'utilisation d'un cadre bien documenté et soutenu. Si vous ne pouvez pas progresser, il n'y a peut-être aucune valeur à paraître mieux à ses yeux. Vous seul pouvez y répondre.

La majorité des réponses et des commentaires ont la bonne idée en ce que vous et la personne âgée auraient besoin d'avoir une sorte de discussion et qu'il peut être important pour vous d'intensifier et de défendre vos décisions, même si votre personne âgée n'est pas d'accord avec vos choix .

Pour répondre à votre question sur ce que j'aimerais voir en tant que senior:

J'aimerais voir si mes développeurs juniors peuvent se lever et défendre ses décisions, même en cas de légère déception. Si j'étais satisfait du produit mais pas de la mise en œuvre, je m'attendrais à ce que les juniors soulignent que j'aurais dû être plus précis dans mes spécifications en leur donnant le produit. J'aimerais qu'ils soient en mesure de défendre leur position mais aussi d'admettre qu'ils n'ont peut-être pas fait le bon choix si tel était le cas.

PS: Je dois mentionner que je suis une personne âgée qui aime se tromper sur le plan professionnel car cela me donne l'opportunité d'apprendre quelque chose de nouveau. Et j'aime savoir comment les autres membres de mon équipe font les choses pour qu'il n'y ait pas / moins de surprises à la fin d'un sprint / d'une tâche.

Tout d'abord, je pense que cela doit être considéré comme une opportunité et non un échec. Il y a évidemment un décalage dans les attentes et on ne sait pas d'où cela vient, ce qui doit se passer pour tout remettre sur les rails, etc.

Deuxièmement, si vous considérez cela comme une défaillance actuelle ou si vous n'êtes pas aussi intelligent que vous pensez, cela crée des relations de pouvoir que vous ne voulez pas. Donc, si vous avez pris des décisions que vous jugez défendables, vous devez être prêt à les défendre jusqu'à un certain point.

Bien que je convienne avec duggieawesome que vous voulez avoir une conversation, cela ne suffit pas. Vous devez être prêt à entrer, à discuter de vos idées de conception, à expliquer pourquoi vous avez fait ce que vous avez fait et à défendre le raisonnement. Vous devez également accepter qu'il n'y a pas qu'une seule bonne réponse et que le programmeur principal peut avoir des raisons valables de préférer une conception différente et que vous souhaitiez donc être prêt à écouter ces raisons sans concéder que vos décisions étaient mauvaises en fonction sur ce que vous saviez (sauf si vous décidez que vous auriez dû mieux savoir, et puis c'est une autre affaire).

Gardez à l'esprit que le design est généralement une question de compromis. Vous voulez être prêt à discuter des compromis et voir ce que vous pouvez faire tous les deux pour vous assurer que vous pourrez discuter des compromis de conception à l'avenir. Peut-être que vous vous attendez à ce que vous soyez plus sur la même page que vous? Peut-être que votre patron est un idiot (cela peut arriver parfois)? Peut-être avez-vous vraiment pris une décision erronée compte tenu de ce que vous saviez des exigences? Entrez cependant avec un esprit ouvert et en toute confiance, et soyez prêt à vraiment en parler.

Edit: je veux ajouter quelque chose sur le fait d'être intelligent. Les personnes les plus intelligentes que je connaisse sont celles qui pensent avoir quelque chose à apprendre de tout le monde. Les gens qui sont fermés et qui croient qu'il n'y a qu'une seule bonne façon ne finissent pas par prendre de bonnes décisions imaginatives dans des domaines comme le design et ils ne peuvent pas relier les choses de la même manière que les gens qui sont prêts à apprendre de tout le monde. Entrer et être prêt à partager et même à faire rebondir des idées est un signe à la fois intelligent et confiant. Les différences de conception ne deviennent pas nécessairement une question d’être meilleur que l’autre. En supposant des concepteurs compétents, différents modèles seront optimisés différemment.

Je suis d'avis que vous n'avez rien fait de mal. En tant que développeur senior, il aurait dû s'intéresser à la façon dont vous développiez l'application ainsi qu'aux résultats. Entrer après la fin d'un projet et dire qu'il n'aime pas comment cela a été fait n'est pas très professionnel de sa part.

Mais, pour répondre à votre question principale: comment pouvez-vous regagner l'opinion d'un aîné sur vous après qu'elle ait été perdue? Tout d'abord, demandez-leur comment ils estiment que vous auriez dû le faire. Posez des questions si vous ne comprenez pas et prenez des notes. Montrez que vous voulez apprendre.

Deuxièmement, lors de votre prochaine tâche, s'il y a quelque chose qui a été omis de la description, proposez vos idées, puis exécutez-les par le développeur senior. Ne vous demandez pas comment faire, car cela n'aidera pas leur opinion sur vous. Mais si vous venez avec vos propres idées et vos propres solutions, demandez-leur si vous êtes sur la bonne voie, cela leur montrera que vous essayez et que vous avez les compétences pour faire le travail. Cela peut être aussi simple qu'un simple e-mail disant "Hé, je prévois d'utiliser x pour faire y . Des idées?"

Troisièmement, quand ils lèvent la tête pour voir comment vous allez, ne les laissez pas partir sans regarder votre code.

Fondamentalement, ouvrez les voies de communication. Votre développeur senior ne semble pas être du genre à être sur vous ou sur votre code, vous devez donc intervenir et être la personne à communiquer. Il vaut mieux que toutes les personnes impliquées découvrent que quelque chose n'est pas exactement pensé à l'origine le plus tôt possible.

Une chose que vous devez savoir dès le départ est de savoir s'il est découragé parce que vous ne pouvez pas donner une défense complète de votre choix de cadre, ou si c'est parce que vous avez utilisé un cadre.

Dans le premier cas, il est important que vous appreniez à évaluer et à sélectionner le code tiers à inclure dans un projet, et que vous sachiez comment exprimer cette décision à vos supérieurs et être prêt à vous y tenir avec justification. C'est une compétence difficile à apprendre, mais elle vient avec l'expérience. C'est également une bonne compétence à apprendre, car dès que vous incluez une bibliothèque tierce dans un projet, vous introduisez un composant qui peut ne pas être entièrement compris par les autres développeurs, qu'ils n'ont pas le contrôle total et peuvent contenir des bogues, trous de sécurité et autres choses dont ils doivent être conscients.

S'il est déçu parce que vous ne l'avez pas écrit à partir de zéro, c'est un tout autre problème. Il se peut qu'il ait de bonnes raisons de décourager l'utilisation de frameworks (tels que ceux que j'ai décrits ci-dessus), ou peut-être existe-t-il une politique d'entreprise contre eux ou limitant le choix de frameworks que vous pouvez faire. De toute façon, il aurait dû vous le communiquer et le fait qu'il n'indique pas un échec de sa part. D'un autre côté, il peut simplement avoir un cas de préjudice lié au cadre, car malgré les problèmes que les cadres peuvent entraîner, ils présentent également des avantages majeurs, comme vous le savez sûrement. Il peut juste penser que vous devriez tout faire vous-même, même si cela signifie refaire le travail qui a déjà été fait et rendu public en raison du "syndrome non inventé ici".

Qu'il n'ait pas expliqué pourquoi il est déçu de votre utilisation d'un framework est certainement un échec de sa part à communiquer efficacement. Il vous a laissé vous demander ce que vous avez fait de mal, alors que la réponse pourrait bien être "rien". Il vous a également amené à vous remettre en question, ce qui vous rendra moins enclin à utiliser votre propre initiative à l'avenir. S'il y a un trait qu'un bon programmeur ne peut pas se permettre d'avoir, c'est un manque d'initiative. Et bien que je sois sûr que ce n'est pas intentionnel, son attitude nuit au moral car il a soudainement retiré les éloges pour un travail bien fait sur un petit détail de la façon dont vous avez accompli la tâche.

Ce n'est pas parce qu'il est le programmeur principal qu'il est infaillible.

Votre commentaire de suivi qui a dit que le patron est bouleversé, il doit apprendre quelque chose de nouveau ...

Sauf s'il y a plus que vous n'avez pas mentionné, je serais ennuyé par LUI.

L'apprentissage des nouvelles technologies est une grande partie de notre travail et chaque équipe devrait embrasser l'apprentissage et l'auto-amélioration.

MAIS, la direction a d'autres soucis à se faire. Ils ont des délais à respecter, ils ont des budgets de formation limités ou inexistants.

Du point de vue de la gestion de l'homme, ce pourrait être quelqu'un d'autre qui travaille sur la phase 2 de votre projet à votre place. Votre patron pourrait avoir une autre oreille marquée pour faire ce travail, et il sait que cette personne a maintenant une courbe d'apprentissage pour quelque chose de nouveau.

Et maintenant un MAIS sur le MAIS précédent ... c'est la faute de votre patron. Si vous êtes nouveau et junior, il aurait dû fournir au moins quelques conseils. Dans une moindre mesure, vous auriez pu également demander des conseils sur la technologie à utiliser.

Si vous êtes un programmeur senior et que vous avez perdu confiance dans la capacité de votre programmeur junior, que souhaiteriez-vous que votre junior reprenne confiance?

Étant donné que vous avez dit qu'il ne voulait pas apprendre à utiliser le cadre que vous avez utilisé, je pense que la question devrait être: " Si vous êtes un programmeur senior et que vous avez perdu la capacité d'apprendre de votre programmeur junior, que devez-vous faire pour vous débrouiller? "

En tant que développeur professionnel, vous n'arrêtez pas d'apprendre. Déjà. Si vous le faites, vous allez stagner. Et cela pourrait être bien dans certains domaines. Les opérations bancaires ont beaucoup de systèmes existants en fonctionnement qui doivent être maintenus, donc la connaissance des anciens systèmes qui évoluent très lentement est très bien. Un de mes amis éditait COBOL pour une banque pour découvrir que le code source qu'il fixait n'avait pas été touché depuis environ 30 ans (et l'auteur original était notre professeur COBOL à l'université) ... Cela dit, il doit encore apprendre de nouvelles choses car les anciens systèmes doivent être intégrés dans les nouveaux systèmes.

Revenons à votre développeur senior. Vous avez dit " qu'il était contrarié d'avoir à apprendre quelque chose de nouveau ", et à mon avis, cela sonne des sonnettes d'alarme assez fortes.

J'apprends toujours. Bien que j'aimerais vraiment que mon employeur récupère ma facture d'éducation chaque année, il est rare qu'ils dépensent quelque chose proche de ce dont je pense avoir réellement besoin, mais je sais que je dois rester employable, alors je dépense quelque part dans la région de 2000 £ GBP (environ 3000 $ USD) sur ma propre éducation chaque année.

Si votre personne âgée n'apprend pas de nouvelles choses, alors elle commencera à prendre de mauvaises décisions (peut-être qu'elles le sont déjà) et la qualité du code avec lequel vous traitez diminuera car elles sont coincées dans une ornière et ne ressentent pas le besoin d'obtenir hors de cette ornière.

L'un des meilleurs développeurs avec qui j'ai travaillé était un développeur junior qui savait toutes sortes de choses que je n'avais jamais eu l'occasion de regarder. Il a tellement apporté à la table que j'étais souvent dépassé. Mais j'ai apprécié ses efforts et je n'ai jamais été "découragé" par tout cela. J'ai été ravi qu'il ait pris le temps d'apprécier toutes les possibilités et de les présenter à l'équipe. Il dirige maintenant une équipe et il ne cesse de me parler des développeurs qui apportent des choses à la table et de ce qu'il apprend d'eux.

Votre développeur senior doit apprendre des choses. Ils doivent apprendre à ne pas utiliser des mots émotifs (comme «décourageant») pour cacher leurs propres insuffisances, car cela ébranlera la confiance des autres. Ils doivent apprendre de nouveaux cadres (même s'ils ne peuvent pas tout apprendre, savoir ce qu'il fait et comment cela résout un problème, et s'ils en ont besoin à l'avenir, ils peuvent investir du temps dans l'apprentissage plus en profondeur). Et ils doivent apprendre qu'ils occupent un emploi où ils devront continuer à apprendre tout le temps.