Comment corriger un junior, mais l'encourager à penser par lui-même? [fermé]

Je suis le chef d'une petite équipe où tout le monde a moins d'un an d'expérience en développement logiciel. Je ne me qualifierais certainement pas de gourou des logiciels, mais j’ai appris quelques choses au cours des quelques années où j’ai écrit des logiciels.

Lorsque nous procédons à des revues de code, j'enseigne et corrige pas mal les erreurs. Je vais dire des choses comme "C'est trop complexe et compliqué, et voici pourquoi" ou "Que pensez-vous du déplacement de cette méthode dans une classe séparée?" Je fais très attention de communiquer que s'ils ont des questions ou des opinions divergentes, c'est bon et nous devons en discuter. Chaque fois que je corrige quelqu'un, je lui demande "Qu'en penses-tu?" ou quelque chose de similaire.

Cependant, ils sont rarement, voire jamais, en désaccord ou demandent pourquoi. Et dernièrement, j'ai remarqué des signes plus flagrants indiquant qu'ils acceptaient aveuglément mes déclarations et ne formaient pas leurs propres opinions.

J'ai besoin d'une équipe capable d'apprendre à bien faire les choses de manière autonome, pas seulement de suivre les instructions. Comment corriger un développeur junior tout en l'encourageant à penser par lui-même?

Edit: Voici un exemple de l'un de ces signes évidents qu'ils ne se forgent pas leur propre opinion:

Moi: J'aime votre idée de créer une méthode d'extension, mais je n'aime pas la façon dont vous avez passé un grand complexe lambda en tant que paramètre. Le lambda force les autres à en savoir trop sur la mise en œuvre de la méthode.

Junior (après m'avoir mal compris): Oui, je suis totalement d'accord. Nous ne devrions pas utiliser les méthodes d'extension ici car elles forcent les autres développeurs à en savoir trop sur la mise en œuvre.

Il y a eu un malentendu et cela a été réglé. Mais il n'y avait même pas une once de logique dans sa déclaration! Il pensait qu'il régurgitait ma logique avec moi, pensant que cela aurait du sens quand il ne savait vraiment pas pourquoi il le disait.

Réponse courte:

Engagez-les (mettez le puzzle dans leur esprit), renforcez-les (faites confiance à leurs réponses).

C'est la question qui nous pousse! - Matrice.

De manière générale, selon mes observations, les juniors ont leur propre monde - leur propre vision limitée de la façon dont ils pensent et, en partie, leur propre enthousiasme / favoris / opinions sur les choses.

Il n'y a rien de mal à leur dire de front que vous avez tort - mais le mieux est de leur faire réfléchir. Pourquoi? Y a-t-il d'autres moyens? Existe-t-il de meilleurs moyens de faire la même chose? Une des anecdotes que j'utilise toujours est la suivante: "Donnez-moi trois solutions (à ce problème)!"

Au moment où ils réfléchissent à ces solutions, ils commencent à comprendre de nombreux problèmes. Cela leur prend un peu de temps - mais avec le temps, ils ont tendance à visualiser les limites et les faiblesses de leur façon de penser. Ils commencent à voir cela plus comme "je n'y ai pas pensé!" ce qui est beaucoup mieux que de rentrer à la maison avec le sentiment que "j'avais tort!" ou même pire "On m'a dit / prouvé que j'avais tort même quand j'avais des points de vue valables" .

En général, les très jeunes enfants ont tendance à être plus habiles en ce qui concerne les problèmes techniques (tels que le modèle de conception le mieux adapté!) Aux problèmes de processus , mais au fil du temps, lorsque vous les coachez, cela fonctionne.

Cependant, ils sont rarement, voire jamais, en désaccord ou demandent pourquoi. Et dernièrement, j'ai remarqué des signes plus flagrants indiquant qu'ils acceptaient aveuglément mes déclarations et ne formaient pas leurs propres opinions.

Ceci est généralement un résultat que vous faites prendre leurs suggestions , mais plus tard , passer outre et ils sont également pas convaincus de votre point de vue; juste parce que vous êtes senior, ils évitent une bagarre!

La meilleure chose que l’un de mes anciens patrons ait apprise: il demandera aux membres de l’équipe de débattre en premier (ils se sentent assez égaux ici) et, après avoir épuisé tous les arguments, il entrerait dans la salle avec une seule question: les points de désaccord? " - Le fait est que les gens aiment toujours participer aux débats et aux discussions, mais si leurs points (valables) ne sont pas mis à profit, la prochaine fois, ils estiment que ce n'est pas la peine de participer à la discussion.

Non seulement dans les logiciels, mais partout en fin de compte, seuls les coéquipiers les plus compétents oseront répondre, sans parler du système.

Si vous voulez que vos juniors pensent par eux-mêmes, ne les corrigez pas: demandez-leur de se corriger eux-mêmes .

Au lieu de leur dire ce que vous pensez être faux avec leur solution, posez-leur des questions pertinentes à ce sujet. Dans votre exemple, vous pouvez leur demander ce que quelqu'un qui utilise la méthode d'extension doit savoir pour créer le lambda. Continuez à poser des questions comme celle-ci jusqu'à ce qu'ils suggèrent que c'est un problème. De cette façon, vous savez qu'ils ont compris pourquoi leur solution pourrait être un problème et qu'ils sont en outre plus susceptibles d'en tirer des enseignements - si vous leur dites simplement que leur solution est fausse, il s'agit d'un jugement externe et facilement ignoré. S'ils parviennent à la réalisation d'eux-mêmes (avec un peu d'inspiration), ils se rendront compte à quel point c'est bien fondé et seront beaucoup plus susceptibles de tirer les leçons de leur erreur.

En outre, cela donne à vos juniors une chance de défendre leur conception. Ils ont peut-être réfléchi au problème et ont une bonne justification qui tient compte de votre préoccupation, ce qui signifie qu’il n’est pas nécessaire que vous fassiez des corrections. Cela réduit toute perception (même involontaire) que vous réglez par décret fictif.

Étant donné que plusieurs développeurs juniors effectuent des révisions de code en tant que groupe, pas 1 1 1.

Ouvrez en demandant au groupe "Comment le problème pourrait-il être résolu?", Et laissez les autres développeurs juniors suggérer d'abord leurs implémentations. N'ajoutez votre implémentation qu'après que les autres membres de l'équipe aient parlé et si aucun n'a suggéré quelque chose de similaire à ce que vous pensez.

Ensuite, organisez une table ronde sur les avantages et inconvénients relatifs de différentes implémentations dans le but de guider les développeurs débutants vers le choix de la meilleure implémentation sans se faire dire ce qu’il en est.

En tant que bâtisseur de confiance pour les développeurs juniors, vous pouvez commencer par certains cas où ils choisissent ce qui vous semble être la meilleure option et transforment votre alternative en homme de paille avec un défaut presque évident et orientez la discussion sur les raisons pour lesquelles la mise en œuvre initiale est la meilleure.

Quand j'ai commencé à travailler dans la programmation, j'ai fait exactement la même chose que celle que vous avez décrite: quand on me disait quelque chose que je pourrais faire, je suis toujours d'accord. C'était principalement parce que je n'avais pas assez d'expérience pour dire le contraire.

Ce qui m'a donné la possibilité de discuter de méthodologies et d'idées, c'est d'apprendre de l'expérience et de lire différentes approches et les nouvelles technologies. Pour que votre équipe puisse penser par elle-même, elle doit savoir quels problèmes peuvent survenir, notamment du code "excessivement complexe et compliqué", et le seul véritable moyen de le découvrir est l'expérience.

Pour faciliter la réflexion individuelle, demandez-leur de consulter des sites Web de programmation tels que Stack Overflow ou Programmers SE. Je sais que cela m'a permis de mieux connaître les différentes techniques existantes et de discuter avec les membres les plus expérimentés de l'équipe au lieu de les accepter aveuglément.

Le fait est que sans expérience, les suggestions des membres les plus âgés leur sembleront toujours justes.

L'interaction de votre message démontre un principe clé pour enseigner à peu près n'importe quoi: demandez-leur d'expliquer ce qu'ils pensent que vous avez dit et écoutez attentivement la réponse: elle vous dira précisément ce qui doit être corrigé.

J'ai volé sans vergogne cette astuce de mon professeur de mathématiques il y a environ 25 ans, et elle ne m'a pas manqué depuis. Je l'ai utilisé en classe lors de mon bref passage en tant qu'assistant d'enseignement, au travail lorsque je parlais de conception de logiciels et avec ma fillette de huit ans quand je parlais de ses devoirs scolaires.

Bien entendu, vous ne pouvez pas toujours leur demander de répéter ce que vous venez de dire. Vous devez donc ajuster votre stratégie. Par exemple, voici comment je reformulerais votre déclaration suivante du PO en tant que question "approfondie":

J'aime votre idée de créer une méthode d'extension, mais je n'aime pas la façon dont vous avez passé un grand complexe lambda en tant que paramètre. Voyez-vous comment ce complexe lambda oblige les autres à en savoir trop sur l’application de la méthode?

Il est impossible de répondre correctement à cette question sans comprendre le problème que vous essayez de mettre en évidence. J'ai trouvé que terminer mes explications par une question nécessitant une analyse de ce que je viens de dire accélère le processus d'apprentissage et me donne les informations nécessaires pour apporter des corrections.

Habituellement, lorsque les gens ne disent pas ce que vous voulez, cela signifie que vous devez travailler sur votre écoute. Écouter signifie entendre les raisons de leur conception avant de porter un jugement. Cela signifie non seulement leur dire qu'il est permis de se dissocier, mais de le prouver en considérant honnêtement ce qu'ils ont à dire, et pas seulement de les corriger. Recherchez les avantages de leur solution et modifiez-la pour l’intégrer.

Vous devez également donner l'exemple. Je ne veux pas dire par écrire du code super génial, je veux dire en leur demandant leur avis sur vos propres conceptions. N'attendez pas les revues de code après coup, mais travaillez ensemble tout au long du processus. Dites des choses comme: "Mon interface semble trop complexe, mais je ne suis pas sûre de la meilleure façon de la simplifier." Et donnez-leur le temps de répondre sans les préjuger de vos propres idées.

Quand j'ai eu à gérer cela, j'ai dit (honnêtement) des choses comme:

Vous savez, c'est une solution vraiment créative à laquelle je n'aurais jamais pensé. Comment cela évolue-t-il? / Pensez-vous qu'il pourrait exister une approche conceptuellement plus simple pour accélérer le développement ou faciliter la maintenance? / Malheureusement, cela ne correspond pas vraiment au reste de l'architecture du projet. la configuration ressemble?

Cela a généralement été suffisant pour orienter les gens dans une nouvelle direction.

La responsabilité est une chose qui peut les aider.

J'ai déjà dirigé une équipe ou deux par le passé et l'un des facteurs qui ont fait briller les juniors était le fardeau de la responsabilité personnelle. Quand on se rend compte que ses actions peuvent l'impliquer à un moment donné, il / elle commet habituellement un tout petit peu plus de lui-même dans ce qu'il fait. Sans compter que quand ils sentent leur travail, les bons résultats sont beaucoup plus satisfaisants.

Je ne m'inquiéterais pas trop du fait qu'ils vous suivent aveuglément, c'est ce qu'ils devraient faire en tant que juniors. Le fait est qu'ils ne comprendront probablement pas les vraies raisons des éléments que vous abordez dans les revues de code jusqu'à ce qu'ils partent et travaillent ailleurs, avec des développeurs de logiciels, une gestion et un code terribles.

À ce moment-là, ils auront appris les bonnes pratiques par habitude et devront surmonter les erreurs de codage et de conception commises par d'autres et ils sont obligés de faire en sorte qu'ils doivent désormais travailler sur des logiciels mal conçus et mal implémentés.

Ce sera une fatalité éventuelle à un moment donné de leur carrière. Vous leur rendez un excellent service en les habituant à de bonnes normes et pratiques de codage. Malheureusement, la plupart d'entre nous ont dû apprendre à la dure.

Sur la base de l’exemple donné, je dirais que la meilleure façon de procéder est probablement de donner suite à vos commentaires. Si vous posez une question en même temps que vos commentaires, cela ne les laisse pas simplement d'accord ou pas, ils doivent au moins réfléchir à la façon dont ils peuvent mettre en œuvre quelque chose.

Par exemple, "j'aime votre idée de créer une méthode d'extension, mais je n'aime pas la façon dont vous avez passé un grand lambda complexe en tant que paramètre. Le lambda force les autres à en savoir trop sur l'implémentation de la méthode. Pouvez-vous penser à une meilleure façon de implémenter cette méthode d'extension qui n'expose pas autant d'informations? "

Cela leur permet de voir les défauts de ce qu’ils développent tout en leur donnant la possibilité de résoudre le problème qu’ils ont introduit dans l’application.