Que devez-vous faire si votre junior n'a pas adopté votre suggestion? [fermé]

Je dirige une équipe de 3-4 développeurs juniors. Mon travail - en plus d'écrire du code - est de fournir une supervision et des conseils aux juniors.

Mais, je comprends parfaitement à quel point les développeurs chérissent l'autonomie dans leur travail, et je ne veux pas détruire leur motivation intrinsèque en les alimentant à la cuillère avec mes pensées et mes algorithmes; Je veux qu'ils explorent le problème à leur manière, y réfléchissent eux-mêmes et ne viennent à moi que lorsqu'ils sont vraiment confrontés à des problèmes insurmontables.

Quand ils viennent à moi, je dois parfois proposer un algorithme complètement différent pour résoudre le problème car leur algorithme n'est pas assez robuste (rappelez-vous, je suis le senior et j'en ai vu plus qu'eux). Bien sûr, j'expliquerais cela d'une manière agréable afin de ne pas blesser leurs sentiments, et je soulignerais doucement comment ma solution est largement supérieure à la leur, pas de ton condescendant ou de mots condamnant.

Mais malgré tout, ils sont parfois réticents à accepter ma suggestion, en partie parce qu'ils ont tant investi dans leur propre algorithme, ou en partie par crainte que l'utilisation d'une nouvelle méthode entraîne plus de temps d'apprentissage et les fasse apparaître à la direction comme s'ils ne vont nulle part. Mais au fond de mon cœur, je sais très bien que mon algorithme est bien meilleur que le leur et ils devraient simplement l'adopter.

Que dois-je faire s'ils n'adoptent pas ma suggestion? Dois-je simplement leur demander de suivre mon chemin, ou devrais-je simplement leur laisser se cogner la tête contre le mur de nombreuses fois et attendre qu'ils reviennent vers moi? Faire de l'ancien fait de moi un dictateur, mais faire plus tard nous coûterait un temps de développement précieux et entraînerait des coûts de correction de bogues. Je suis vraiment dans un dilemme ici.

Aidez-les à comprendre pourquoi ils devraient apporter la modification suggérée. Et écoutez-les s'ils ont une bonne raison de ne pas faire le changement. Discutez et parvenez à un accord sur la base de la meilleure chose à faire.

Cette approche est importante pour les raisons suivantes:

• Vous voulez qu'ils fassent le changement pour de solides raisons commerciales / techniques. Il est important d'être clair sur ce que c'est (souvenez- vous que vous pourriez aussi vous tromper, alors soyez humble ...).
• Vous voulez vraiment transmettre le raisonnement derrière votre suggestion - de cette façon, le destinataire apprendra à résoudre lui-même des problèmes similaires à l'avenir. Vous aurez également une meilleure relation si vos juniors sentent qu'ils apprennent de bonnes idées de votre part.
• Vous ne serez pas respecté si vous utilisez votre ancienneté et ne pouvez pas prouver que vous avez réellement de bonnes raisons.
• Votre patron aimerait sans doute être sûr que vous utilisez efficacement le temps de vos juniors sur des choses qui créent de la valeur réelle, et pas seulement "faire à ma façon" pour le plaisir.

Si vous êtes intelligent, vous pouvez également les amener à répondre simplement en posant des questions . Bien fait, votre junior arrivera lui-même à la bonne conclusion (et sera donc beaucoup plus disposé à le mettre en œuvre). Exemples de questions:

• Votre code suppose l'accès à la base de données de production. Comment pourrions-nous changer cela afin qu'il fonctionne toujours et puisse être correctement testé par JUnit dans un environnement de développement déconnecté? (réponse potentielle: ah! nous devrions utiliser l'injection de dépendances ....)
• Que se passera-t-il si un attaquant a délibérément envoyé du SQL intelligemment construit dans votre formulaire de saisie de données en ligne? (réponse potentielle: ah! peut-être ne devrions-nous pas construire des instructions SQL en concaténant du texte non vérifié des internets)

EDIT : Si vous réussissez à persuader votre junior que la bonne chose à faire est de suivre votre suggestion, mais ils hésitent encore ici, voici quelques conseils supplémentaires:

• Découvrez pourquoi ils sont réticents. Il est possible qu'ils aient besoin de se rendre compte personnellement que peu importe si vous jetez du code, à condition d'obtenir le résultat. Ou il se peut qu'ils se sentent sous la pression du temps à cause d'un délai. Vous devez savoir, sinon vous ne pouvez pas les aider .....
• Vous pouvez faire valoir qu'ils peuvent considérer le changement comme un moyen d'améliorer leurs compétences de refactoring. Une fois que les compétences de refactoring sont suffisamment bonnes, vous devriez être en mesure de réaffecter même rapidement une base de code assez grande et complexe.
• Vous devez souligner que tout sera sous contrôle de source, afin qu'ils puissent toujours revenir à une ancienne version si nécessaire.

Je détestais l'attitude dominatrice de mon dernier chef d'équipe, mais je le respecte pour le fait qu'il avait des connaissances techniques supérieures et il m'a beaucoup appris sans me donner de cours. Plus important encore, il ne m'a jamais forcé à suivre son plan. Il jouerait l'avocat du diable avec mon plan, me forçant à prouver que mon plan était parfait. Il chercherait des échappatoires et attendrait mon explication pour savoir pourquoi ce n'est pas une échappatoire ou une solution moins coûteuse. Il me demanderait s'il existe des solutions alternatives et proposerait des idées si je n'en avais pas. Je devrais évaluer ses idées et que son plan n'était pas optimal. S'il était convaincu que mon plan était bon ou avait au moins le même rapport risque-rendement que le sien, il donnerait le feu vert. Si j'échouais avec mon idée, je devrais essayer sa solution.

Il doit y avoir un compromis entre liberté et délais. Vous n'avez pas le luxe de prolonger le délai et vous ne pouvez pas laisser vos juniors le dépasser. Vous devez être poli mais ferme avec eux qu'une fois qu'ils ont essayé leur algorithme et ne l'ont pas fait fonctionner, ils ont le devoir de vous écouter. Prouvez par l'exemple que vous connaissez vos affaires. Mais, tout aussi important, faites-les apprendre, ne leur enseignez pas.

Si c'est une exigence, notez-la comme ça. S'il ne s'agit que d'une suggestion, comme vous le constatez, ils devraient être libres de le faire autrement. Quelques questions que je voudrais poser:

• Avez-vous le pouvoir de demander des solutions spécifiques?
• Quelle est l'étendue de cette autorité?
• La solution est-elle mauvaise ou simplement différente?

Je suis sûr que vous pourriez demander plus, mais les deux premiers se concentrent sur votre autorité et le dernier sur la question de savoir si la question mérite vraiment d'être poussée.

La réponse suivante a quelques excellents points supplémentaires et j'ajouterais ici que vous devez la traiter davantage comme un processus collaboratif où vous travaillez au moins certains d'entre eux avec votre "équipe" plutôt que de simplement leur imposer des diktats. Ils apprendront en travaillant sur les problèmes avec vous plus que simplement en leur disant: «envisagez de le faire de cette façon».

L'apprentissage ne se produit vraiment que là où des échecs se produisent, car l'échec est une motivation et fournit des indices de mémoire pour le rappel à l'avenir. C'est essentiellement ce que nous appelons l'expérience, et une bonne expérience en milieu de travail proviendra d'avoir échoué et appris des échecs. Si vos juniors étaient capables de tout obtenir correctement la première fois, soit ils n'apprendraient rien, soit ils ne seraient pas juniors.

Si vous avez trop de juniors qui gâchent les choses, votre entreprise a peut-être mal employé, avec trop de développeurs de niveau junior où les contraintes de temps nécessitent des personnes plus expérimentées pour minimiser vos risques, mais même alors, vous pouvez avoir des problèmes et des retards, car les développeurs seniors font des erreurs d'apprendre aussi.

Vos juniors devront apprendre et acquérir de l'expérience afin de pouvoir faire face dans un environnement où les délais sont serrés. En tant que chef d'équipe, c'est votre travail de donner l'exemple et d'inspirer vos juniors à travailler efficacement, mais la réalité est que vous devez mettre de côté les soucis de fierté personnelle et les soucis de vos horaires serrés si vous voulez que vos juniors apprennent réellement quelque chose et vous devez donc leur permettre d’échouer. Par conséquent, c'est votre travail de faire un appel. Parfois, vous devez donner au junior l'espace pour échouer, puis les accompagner patiemment dans un processus de révision pour leur montrer où ils pourraient améliorer leurs idées. À d'autres moments, vous devez baisser le pied, mais faites-le d'une manière qui vous permette de montrer que cela ne répond pas à un besoin réel qui ne reflète pas mal les capacités de votre junior en soi.

Quant à la question des délais serrés, c'est là que vous devez planifier et répartir votre travail en fonction des forces et des faiblesses relatives de votre équipe. En fin de compte, la balle s'arrête avec vous. Lorsque vous êtes en charge des autres, vous n'êtes pas là pour être l'ami de tout le monde, vous êtes là pour faire un travail difficile dans des circonstances difficiles. La façon dont vous gardez tout le monde de votre côté revient à parler aux gens de vos préoccupations et de vos problèmes, en expliquant pourquoi vous avez besoin que les membres de votre équipe fassent quelque chose d'une manière particulière.

D'après mes propres expériences personnelles, vous devez réserver un certain temps avec votre junior pour discuter des forces et des faiblesses des deux idées, puis rechercher en collaboration la meilleure solution qui résoudra le problème en cours - même au risque de vous permettre de être trompé - puis aller de l'avant. Si vous ne parvenez pas à parvenir à un consensus à la fin du temps qui vous est alloué, vous devez alors clore la réunion avec un résumé qui tient compte des préoccupations discutées et note qu'aucun consensus n'a été atteint. Quel que soit le résultat de votre rencontre, vous remerciez votre junior pour le temps passé et indiquez que vous reviendrez avec votre décisionprochainement. Après un examen attentif de votre discussion, vous aurez la possibilité d'allouer du temps supplémentaire pour une discussion plus approfondie ou de demander au junior de poursuivre le plan sur lequel vous vous êtes fixé en fonction des résultats de votre réunion.

Oui, le temps est parfois précieux, mais lorsque vous choisissez d'embaucher des juniors, vous devez accepter que vous assumez la responsabilité d'investir et de favoriser leur développement professionnel, et vous devez l'accepter en conséquence, ce sera pendant un certain temps vous coûte au moins du temps.

Je me demande si vous présentez réellement votre suggestion d'une manière qui n'est pas condescendante. Lorsque vous utilisez des expressions telles que:

ma solution est largement supérieure à la leur

et

au fond de mon cœur, je sais très bien que mon algorithme est bien meilleur que le leur et ils devraient simplement l'adopter.

cela me fait penser que vous pourriez rencontrer une attitude de «ma voie est supérieure». Personne n'aime avoir cette attitude. Lorsque je l'ai reçu dans le passé, je me suis activement efforcé d'utiliser un algorithme différent pour prouver que la personne avait tort. Il se pourrait que vos juniors fassent de même.

Une meilleure façon devrait être de s'asseoir avec la personne et de discuter de son algorithme. Expliquez pourquoi vous ne pensez pas que cela fonctionnera et écoutez les réponses qu'ils vous donnent avec un esprit ouvert. Voyez si leur algorithme peut être modifié pour fonctionner correctement.

Si ce que vous possédez ne fonctionnera certainement pas, expliquez-leur pourquoi cela ne fonctionnera pas. Quelles parties sont incorrectes, impliqueront des réécritures plus tard ou ne correspondent pas au modèle commercial. Assurez-vous qu'ils comprennent bien vos raisons. Ensuite, expliquez-leur votre algorithme, en leur indiquant les éléments où cela fonctionnerait et leur code échouerait.

Tout d'abord, connaissez-vous la vraie raison pour laquelle votre junior n'a pas adopté votre suggestion?

Parfois, vous savez, un junior peut réellement écrire quelque chose de mieux que son senior en raison de nouvelles perspectives et d'une éducation CS plus à jour. Bien qu'en tant que senior, vous avez peut-être vu des exemples plus réels. Mais un mauvais piège dans lequel je vois souvent mes aînés tomber, c'est oublier que les meilleures pratiques pourraient changer avec le temps. Je suis sûr que cela ne s'applique pas à vous, car vous vous êtes mis à jour sur des sites tels que ceux-ci. ;)

Je suggère d'essayer d'approcher vos juniors sans aucune (ou peu) "aura" d'un senior, d'essayer de parler avec eux en niveau, de montrer de la curiosité dans le code qu'ils ont écrit. Posez des questions, écoutez leurs réponses. Ne posez pas de questions accusatrices telles que:

"Votre code est assez rigide, vous devez le changer en ceci ..."

demandez plutôt

"Je me demande simplement, si quelqu'un devait ... votre code parvient-il à gérer cela? ... Je pense qu'un modèle de stratégie pourrait aider ici. Qu'en pensez-vous?"

Je pense que cela vous aidera à engager des conversations plus saines avec eux que comme un professeur / conférencier les regardant comme un tout savoir. Cela vous aidera également à mieux voir leur raisonnement et leurs perspectives.

Contrôlez-vous l'accès push au référentiel?

En open source, l'accès push est toujours contrôlé par un gatekeeper qui est chargé de faire respecter la qualité. Si vous surveillez activement les commits qu'ils poussent, vous devez être très conscients des améliorations possibles.

Arrivent-ils à pirater ou à améliorer votre code. S'ils ont la chance de voir les éléments internes sur le fonctionnement de votre code, ils peuvent apprendre à mieux s'adapter à votre style. Si vous poussez vos suggestions sans accepter les suggestions avec un esprit ouvert, elles seront moins enclines à écouter votre opinion.

Dans certaines circonstances, il n'y a pas de bonne réponse (comme les préférences de style de codage). Dans ce cas, essayez d'établir (ou d'appliquer) une politique à l'échelle de l'entreprise afin qu'ils comprennent que le style du code doit être adapté pour être cohérent avec la base de code principale. L'utilisation d'une directive de style déjà établie (comme le guide de style Microsofts pour C #) est la meilleure façon de procéder, en particulier pour les nouveaux développeurs de l'équipe.

Si vous faites des déclarations générales sur leurs techniques de codage, il y a de fortes chances que vous ne compreniez pas complètement le raisonnement derrière leurs choix. Juste le ton de votre question vous fait paraître arrogant. Que gagnez-vous / sacrifiez-vous en poussant votre approche sur les jeunes développeurs?

La question clé que vous devez vous poser est la suivante: vos suggestions visent-elles à maintenir / améliorer la qualité de la base de code ou à affirmer votre domination / supériorité sur vos pairs? Le premier est un simple contrôle de qualité et peut être justifié en tant que tel, l'échelle est préjudiciable à la dynamique de l'équipe, que vous ayez ou non le droit.

Quoi qu'il en soit, si vous voulez pousser votre solution sur vos pairs, vous devez avoir la preuve concrète qu'elle est, en fait, supérieure. Une augmentation de l'ampleur des performances devrait être assez facile à améliorer, rien de moins ne vaut l'effort (à l'exception des applications critiques pour les performances). Forcer votre travail sur les autres pour justifier votre sentiment personnel de supériorité finira par vous distinguer comme le «vieil homme entrejambe».

Remarque: Les meilleurs programmeurs et les plus talentueux que j'ai rencontrés au fil des ans ont toujours semblé être ceux qui étaient prêts à s'arrêter et à expliquer l'histoire derrière l'origine de leur approche.

Eh bien, cela semble intéressant et très naturel avec de jeunes programmeurs très attachés au code qu'ils ont écrit, peut-être ont-ils passé un certain temps à arriver au même ou ils l'ont choisi sur un bon site (alors en effet, Hey Jon skeet a écrit cela homme!!).

Néanmoins, la chaîne de base attachée ici est une pièce jointe avec le code qui est l'endroit où vous auriez besoin de vous concentrer et je pense que vous auriez besoin de faire des efforts considérables pour leur faire comprendre que l'exécution et le résultat attendu sont plus importants que leur nom étant gravé sur les référentiels sources pour insérer ce code. Vous devrez tracer des lignes pour expliquer pourquoi votre code est meilleur et est également bon en termes de maintenance pour les travaux futurs.

Prenez en considération que quelques échecs sont éminents (besoin de quelques pauses cardiaques pour tout attachement) mais avec un effort progressif, je pense qu'ils se reproduiraient et pourraient mieux apprécier vos efforts. Je pense que vous auriez besoin d'un peu de temps et de quelques échecs. Le leur imposer serait un autre moyen de contourner quelques réussites, puis le jugement dernier et la révolte.

Tout le monde a un style différent. Si vous trouvez 10 personnes différentes et leur présentez un problème non trivial, elles vous proposeront 10 approches différentes en utilisant 10 styles de "normes de codage" différents.

Le point étant: choisissez ce qui compte. Si quelque chose vous est présenté par un junior qui ne produit pas la bonne solution, le fait de manière extrêmement inefficace (+1 ordre de grandeur, pas une instruction ici ou là), ou crée une faille de sécurité, alors expliquez votre problème et pourquoi. Si c'est un commentaire "j'aurais fait ceci", eh bien c'est super, vous auriez fait "cela" et elle a fait "autre chose" mais le problème est toujours suffisamment résolu (voir les points ci-dessus). Passez à la fonctionnalité ou au correctif suivant.

Une partie de l'apprentissage pour être un bon leader consiste à apprendre à reconnaître ce qui compte vraiment et ce qui ne l'est pas vraiment. De plus, vous vous supprimez comme un goulot d'étranglement potentiel pour les performances de votre groupe s'ils doivent tout contrôler à travers vous.

EDIT: assurez-vous que vos suggestions sont des exigences authentiques et non voilées. Une suggestion n'est rien d'autre qu'une suggestion que l'on est libre de suivre ou non. Si c'est une exigence, énoncez-la comme telle.

Comme certains des autres l'ont fait remarquer, si vous ne faites que prouver aux développeurs juniors des suggestions et qu'elles sont formulées comme telles, vous n'avez vraiment pas beaucoup de raisons de vous ennuyer si elles ne les suivent pas, car elles peuvent ne voit pas beaucoup de raisons de le faire. De même, vous ne pouvez vraiment pas les critiquer pour ne pas avoir suivi votre suggestion, car ils ne sont pas réellement orientés pour faire les choses d'une certaine manière.

Pour ce qui est d'essayer d'amener les développeurs juniors à faire les choses comme vous préférez les faire:

• Maîtrisez votre terminologie, faire une suggestion n'est pas la même chose que faire une recommandation qui n'est définitivement pas la même chose que donner une direction . Utilisez la terminologie en conséquence pour faire passer votre message et si vous pensez que votre façon de faire quelque chose est une meilleure façon de le faire, dites-leur que c'est votre recommandation de le faire. De même, s'il est absolument essentiel que les choses soient faites d'une manière donnée (c'est-à-dire qu'elles ne peuvent pas résister à un délai), alors soyez franc et donnez-leur des instructions sur la façon de procéder.
• Les développeurs juniors sont toujours en train de suivre le processus d'apprentissage, quelle que soit la façon dont vous formulez les choses, fournissez toujours une sorte de raisonnement derrière ce que vous leur dites, sauf s'il y a une raison spécifique que vous ne pouvez pas. Même dans ce cas, la plupart des gens comprendront si vous dites quelque chose dans le sens de "Cela doit être fait de cette façon, je m'en fous moi-même mais la décision a déjà été prise." ils ont tendance à être assez raisonnables.
• Si ce n'est vraiment qu'une suggestion, assurez-vous que votre idée est réellement meilleure que comment elle l'a fait. Si vous ne pensez pas que ce soit le cas, asseyez-vous avec le développeur et faites une révision du code et du concept afin qu'il puisse justifier sa solution. Il se peut qu'une fois qu'ils commencent à l'expliquer à quelqu'un d'autre - et que vous posiez les bonnes questions - ils verront une meilleure façon et voudront recoder les choses par eux-mêmes.
• Ne chicanez pas sur les détails si leur solution est similaire à ce que vous avez initialement suggéré, il se peut qu'ils aient pris en compte ce que vous leur avez dit et aient fait les choses légèrement différemment ou changé leur concept d'origine en fonction de votre suggestion.

Il s'agit d'une introduction parfaite aux tests unitaires. Si vos développeurs juniors ont une solution, elle devrait être testable. Demandez-leur de produire un test unitaire pour souligner leur code. Passez ensuite en revue le test unitaire . Si vous pouvez montrer des trous dans le test, il est facile de les faire relancer le test et de voir leur solution se briser sous la pression.

Cela vous permet de leur montrer pourquoi votre solution est meilleure, vous donne un test unitaire que vous pouvez réutiliser lorsque le code change et donne aux développeurs juniors une expérience d'apprentissage précieuse. Et qui sait, vous découvrirez peut-être que leur solution est parfaite.

À un moment donné, vous devez être en charge. On dirait que vous faites un effort pour leur permettre d'exprimer leurs opinions. Vos suggestions peuvent ne pas être parfaites. Les autres développeurs peuvent ne pas comprendre / être d'accord avec vous. Ils ne sont probablement pas d'accord les uns avec les autres. Si vous êtes en charge, ce n'est pas une démocratie. Ils le savaient lorsqu'ils ont pris le poste.

S'il n'y a pas de situations où ils doivent vous suivre, vous ne méritez pas et ne sert à rien en tant que patron. Changez votre rôle dans l'équipe pour être une ressource et non une autorité si vous ne prévoyez pas de l'utiliser. À un moment donné, vous devez expédier le meilleur code possible en fonction des contraintes de temps disponibles et ne pouvez pas débattre, rechercher et débattre à nouveau chaque ligne de code jusqu'à la fin des temps.

Donnez les ordres. Vivez avec les conséquences. Apprendre de l'expérience. Le respect doit être réciproque. Vous le démontrez et ils ne le sont pas.