Comment gérer le comportement non professionnel des stagiaires ?

Je ne pense pas que le rire soit la bonne approche. Il faut qu'ils apprennent qu'ils ne sont plus à l'école. Cela étant dit, je ne pense pas non plus que vous devriez aller trop loin dans l'autre sens.

Je vous recommande d'être ferme avec lui/elle et de lui dire quelque chose comme :

La raison pour laquelle nous avons passé en revue les conventions de dénomination est qu'elles sont très importantes. Ce code doit pouvoir être maintenu à l'avenir. Beaucoup de gens ici ont travaillé dur pour en arriver là, et ils n'apprécient peut-être pas ce genre de blagues. Veuillez vous abstenir d'utiliser ce type de noms à l'avenir, car cela pourrait amener les gens à remettre en question votre professionnalisme.

Tout d'abord, cela ressemble à une blague codée dont ils savent bien qu'elle ne sera plus jamais utilisée ou lue. Je pense que vous en savez beaucoup trop sur cet incident. L'important, c'est que vous leur avez parlé de la convention de dénomination et ils ne vous ont pas ignorés, ils ont utilisé des noms plus longs et plus descriptifs (bien que sarcastique).

Après avoir regardé cette vidéo Je peux voir que les travailleurs désirent 3 choses :

1. Autonomie
2. La maîtrise
3. Objectif

Ce que vous leur demandez de faire n'est pas autonome, est probablement d'une difficulté insignifiante pour certains d'entre eux, et ne sert à rien à leurs yeux.

Fixez la mission, et les travailleurs suivront.

Certains exemples :

1. Voici ce projet, travaillez ensemble et faites-le réaliser par [ cette vidéo ], faites-moi savoir si vous êtes bloqué.

2. Je sais que cela ne semble pas important, mais afin d'évaluer vos compétences et de vous attribuer un travail qui vous aidera à vous développer, nous avons besoin que vous terminiez cette tâche.

TL;DR : Je m'oppose au nom de la méthode parce qu'il exprime (à mon avis !) le mépris du patron et/ou des “règles” (ici : directives de style). Sur le lieu de travail, j'attends des gens qu'ils respectent la règle “aimez-le, changez-le ou quittez-le”. Dans ce cas, le stagiaire, qui semble penser que la ligne directrice n'est pas nécessaire, doit soit l'accepter quand même, soit poursuivre la discussion à ce sujet, soit arrêter de faire ce qu'il fait. Ne pas mettre l'équivalent d'un peu de barbouillage sur les toilettes. Je n'aurais eu aucune objection à un nom de méthode vraiment drôle et créatif. Si vous (le PO) trouvez le nom de la méthode juste drôle et pas “mauvais” comme moi, alors ignorez cette réponse, s'il vous plaît.

En guise d'antécédents, j'ai supervisé quelques stagiaires très intelligents et (auto-)motivés dans le passé, et jamais il n'a été question de savoir s'ils se comporteraient professionnellement ou non. Apporter une bêtise de niveau scolaire sur un lieu de travail en tant que stagiaire est tellement hors de propos que je vous conseille de ne pas faire l'idiot. Pour votre propre bien et surtout pour leur bien.

J'aimerais savoir comment gérer correctement une telle situation.

Tout d'abord, oubliez les conventions de codage. Le problème n'est pas lié à l'informatique ou à la programmation.

• Ne mentez pas. Ne mâchez pas vos mots, ne riez pas, parce que ce n'est vraiment pas une question de rire.
• Ne devenez pas personnel. Il ne s'agit pas de vous l'OP, ni de votre relation avec eux. Il s'agit purement et strictement de leur comportement.
• Expliquez les choses telles qu'elles sont. Vous pouvez absolument dire au délinquant que vous comprenez en quelque sorte comment il a eu l'idée de faire ce qu'il a fait, et que vous n'êtes pas personnellement en colère contre lui ou quoi que ce soit d'autre (évitez les émotions), mais que vous considérez le stage comme une projection de qui à prendre à bord plus tard.

Si vous souhaitez transmettre une émotion quelconque à ce sujet, restez loin de la colère. Vous pouvez afficher une légère tristesse (et franchement, ce serait exactement ce que je ressentirais) et leur montrer que vous avez été assez déçu.

Néanmoins, leur performance pendant le stage aura une incidence sur leurs chances d'être embauché et des situations comme celle-ci peuvent jouer un rôle plus tard.

Absolument ! Ne faites pas l'imbécile avec “peut jouer un rôle plus tard”. Un tel comportement peut, doit et va réduire à zéro leurs chances de recevoir une offre après le stage. Vous pouvez dire cela de la manière dont vous leur parlez normalement, clairement et simplement.

Essayez de trouver la cause profonde. Si vous découvrez que…

• …ils sont ici contre leur gré (peut-être que leurs parents, ou leur école ou autre, les ont obligés à choisir un stage et qu'ils ont choisi votre entreprise par hasard)…
• …ils ne sont pas du tout intéressés par le développement de logiciels de type “commercial”…

…alors proposer d'annuler le stage ne serait pas le pire que vous puissiez faire. Le problème n'est pas que votre temps soit perdu (vous aviez prévu beaucoup de votre temps pour les superviser de toute façon, ils n'ont pas vraiment aggravé votre situation), le problème est que leur temps est perdu.

Ou je devrais leur dire quelque chose dans ce sens pour les motiver davantage à apprendre quelque chose ?

Je dirais “tout humain peut apprendre, mais aucun humain ne peut être enseigné”. Je pense que vous trouverez très difficile de motiver cette personne à apprendre l'utilité des conventions de codage puisqu'elle a déjà démontré qu'elle ne s'y intéresse pas du tout. Vous pouvez enseigner à ceux qui sont intéressés par ce que vous avez à dire ; mais si quelqu'un est désintéressé, il n'y a rien que vous puissiez faire, vraiment.

Si vous voulez vraiment aider cette personne à “voir la lumière”, alors demandez-lui d'essayer de jouer le jeu pour son propre bien, peut-être apprendront-ils à apprécier ce que vous pouvez leur offrir, plus tard. Les stages sont un échange de tous les services limités qu'ils peuvent offrir, contre l'expérience d'un travail sur un lieu de travail réel. S'ils ne sont pas intéressés à assimiler l'expérience, alors il n'y a vraiment aucun intérêt. Il est probable que votre entreprise ne dépende pas de sa “force de travail” pour un projet réel.

Nous détestons tous le faire, mais parfois il suffit de régler les problèmes en utilisant l'autorité. Appelez les stagiaires à une réunion, et demandez leur pourquoi les conventions de dénomination n'ont pas été suivies.

J'ai expliqué les conventions de dénomination à suivre lors de notre précédente réunion. Je suis tombé sur un certain nombre de cas où la convention de dénomination n'a pas été respectée. Par exemple, convertToMillilitersBecauseIAmUsingSuchCleanCode. Pourriez-vous expliquer pourquoi ce nom a été choisi ?

Leur “réponse” n'est pas pertinente, cela devrait suffire comme “premier avertissement” que le fait d'aller à l'encontre des directives de leur superviseur (que vous êtes, je suppose) et de faire des blagues à ses dépens n'est pas acceptable dans un environnement professionnel. Cela cadre même bien avec l'un des objectifs du stage, qui est de montrer aux étudiants comment travailler dans un environnement professionnel.

S'ils continuent à avoir un comportement enfantin, alors eh bien, je pense que vous êtes arrivés à la conclusion suivante :

Certains des stagiaires seront embauchés dans l'entreprise à l'avenir en fonction de leurs performances.

Oh, un tas de ratés, hein ?

Prenez un code de travail et faites quelque chose pour le casser délibérément. Puis passez-le dans un obfuscateur qui change tous les noms de classe, de variable et de méthode en “a___1318798_” et “xy23_7a963” ; ou pire, des noms de variables avec beaucoup de lettres O, de lettres I, de chiffres 0 et de chiffres 1. Faites en sorte qu'ils aient pour mission de documenter ce que fait le code, et réparez-le.

Cela remédiera à cette plaisanterie.

Je sais que ce n'est probablement pas si grave, mais c'est la première fois que j'aide les stagiaires et j'aimerais savoir comment gérer correctement une telle situation. Il n'en reste pas moins que leur performance pendant le stage aura une incidence sur leurs chances d'être embauchés et que des situations comme celle-ci peuvent jouer un rôle plus tard. Ou bien je devrais leur dire quelque chose de ce genre pour les motiver davantage à apprendre quelque chose ?

Lorsque vous rencontrez de telles sottises pendant vos révisions de code, riez, arrêtez la révision de code et dites-leur de revenir une fois qu'ils auront retiré l'humour.

Je suppose qu'ils ne sont pas stupides et qu'ils savent déjà que le nom trop long est inapproprié, même s'ils en rient. Si ce n'est pas le cas, expliquez pourquoi une fois.

Avec un peu de chance, vous gardez une trace de leur performance et pouvez noter la fréquence à laquelle cela se produit.

J'aurais un tête-à-tête avec chacun d'eux, en privé, sur un ton franc et sérieux mais pas sévère, quelque chose comme ceci :

“Interne, j'ai vu le nom de votre méthode de blague. Je comprends pourquoi tu l'as fait, mais je n'ai pas trouvé cela très drôle moi-même. Alors, il me vient à l'esprit de vous demander, que faites-vous ici ? Si le stagiaire dit qu'il n'est là que pour faire des bêtises, alors parlez-en à la direction pour mettre fin à son stage. Vous perdez votre temps.

S'il dit qu'il est là pour apprendre, alors dites quelque chose comme ceci :

"Je me rends compte qu'il peut être difficile de prendre au sérieux quelque chose dont vous savez qu'il ne sera pas utilisé en production. Mais sachez que vous ne faites pas que prendre votre temps, vous prenez aussi mon temps. Le stage qui vous est proposé par l'entreprise est, en substance, une sorte d'entretien. La seule chose qui l'empêche d'être carrément caritative de notre part est l'espoir de trouver de bons candidats. Cela vaut donc la peine que j'y consacre du temps, mais seulement si vous êtes sérieux”

“Si vous ne pouvez pas prendre cela au sérieux et travailler comme si vous écriviez un code de production important, comment pouvons-nous vous évaluer correctement et décider de vous offrir un emploi ? Et même si nous ne vous offrons pas d'emploi, si vous ne le prenez toujours pas au sérieux, comment allez-vous acquérir ces compétences et être capable de vous exercer sous la direction de quelqu'un qui a plus d'expérience que vous ?”

“Si j'étais vous, je ferais de mon mieux pour suivre l'exemple des personnes qui vous guident et qui, de manière quelque peu charitable, prennent du temps non rentable sur leur travail pour s'investir dans votre travail. Considérez que vous bénéficierez de ce stage, que nous vous engagions ou non ! Personnellement, j'apprécierais que vous preniez cela un peu plus au sérieux. Faites-le pour vous ! Si vous ne voulez pas le faire pour vous-même, faites-le par respect, ou simplement par gratitude, pour le temps que j'ai pris sur mon travail productif normal pour investir dans vous et votre avenir”

Il est probablement approprié d'aborder un peu directement le comportement lui-même, et pourquoi vous en faites un peu tout un plat. Vous pourriez envisager quelque chose comme ceci :

“Pour ce que ça vaut, ce genre d'action est considéré comme un manque de respect, voire une moquerie, dans le monde de l'entreprise. Je suis sûr que ce n'est pas ce que vous vouliez dire [même si vous n'y croyez pas, dites-le], mais s'il vous plaît, suivez simplement mes instructions à l'avenir sans mettre des choses douteuses dans le code”

Donner le “out” du stagiaire en disant “oh, oui, je ne voulais pas manquer de respect” lui permet de sauver la face et de réparer la relation de la manière la plus indolore possible. Il n'est pas nécessaire de lui faire avouer qu'il l'a fait de manière irrespectueuse ou de lui demander de s'excuser. Il ne s'agit pas ici de power-over mais de stage réussi.

Si, après tout cela, le comportement négatif continue, vous pouvez l'aborder plus frontalement. Il n'y a aucune raison pour laquelle vous ne pouvez pas donner un objectif de performance à un stagiaire tout comme vous le feriez pour un employé à problèmes, ou utiliser toute autre stratégie que vous utiliseriez avec un employé ordinaire. Mais n'oubliez pas que les stagiaires n'ont PAS d'expérience dans le monde du travail et qu'il faut leur accorder une pause ou deux pendant que vous les habituez doucement, mais fermement, aux normes du monde du travail professionnel.

Les stagiaires en question vous font perdre votre temps et votre patience. Votre temps et votre patience sont des ressources limitées et coûteuses pour l'entreprise et les stagiaires profitent de l'investissement de l'entreprise dans ces ressources, un investissement qui est limité par les ressources de l'entreprise.

Leur volonté de gaspiller inutilement les ressources de l'entreprise est un élément pertinent de leur évaluation de performance et peut conduire à une cessation prématurée de leur stage afin de dépenser les ressources de l'entreprise uniquement pour les stagiaires réellement intéressés à apprendre comment être un élément précieux, responsable et fiable du lieu de travail qui peut se voir confier à la fois des tâches et des instructions.

Je dirais ceci à tous les stagiaires, en montrant un exemple de code, sans mentionner son auteur, sans y consacrer plus de 2 minutes et, si le code est corrigé par la suite et que des incidents similaires ne se répètent pas, sans le mentionner à nouveau.

Si le coup de semonce reste sans effet, l'étape suivante consiste à avoir une discussion ouverte avec le stagiaire en question et éventuellement avec un de vos supérieurs (assurez-vous cependant qu'il est dans votre bateau). Ensuite, vous devez décider si vous devez aux autres stagiaires d'éliminer celui qui sabote leurs chances de réussite.

Il semble qu'il y ait deux problèmes principaux ici : 1) Ils sont irrévérencieux et 2) Le nom de la fonction est toujours nul même s'il est maintenant plus long.

Les réprimander pour avoir plaisanté ne va probablement pas les amener à respecter davantage votre autorité, donc je me concentrerais sur la question comme s'il s'agissait de n'importe quelle autre fonction mal nommée. Je ne ferais pas nécessairement l'idiot en prétendant que je ne me rends pas compte que c'est une blague, mais je les interrogerais sur la raison pour laquelle ils ont choisi ce nom :

“Il semble qu'il y ait des mots superflus dans ce nom de fonction qui n'aident pas à expliquer ce que fait la fonction”

De cette façon, c'est une occasion pour eux d'apprendre ce qui fait un bon nom de fonction et vous ne les confrontez pas directement. De plus, ils peuvent avouer qu'ils ont juste fait des bêtises et peuvent avoir honte de faire perdre du temps à tout le monde.

Si vous devez rappeler aux gens que vous êtes le responsable, alors vous ne l'avez jamais été.

Il serait préférable d'effectuer une visite du code où le développeur doit expliquer son code aux personnes en autorité.

1. Cela confère une responsabilité personnelle pour le résultat du projet
2. Cela permet un retour d'information professionnel immédiat
3. Donne au développeur un sentiment d'urgence pour l'achèvement du projet

Utilise votre leadership en tant que membre de l'équipe pour faire respecter les normes de votre organisation. Ensuite, aidez les jeunes employés à respecter ces normes et évitez de leur présenter un travail de qualité inférieure.

Dites simplement au délinquant (personnellement ou par e-mail) que le stage n'est pas un endroit approprié pour de telles blagues et qu'il doit le prendre au sérieux s'il veut commencer une carrière.

Demandez-leur de corriger le code, ou (si vous voulez faire preuve d'un peu d'autorité) de simplement annuler leurs changements dans le contrôle de version.

Je sais que la règle des 80 caractères par ligne n'est pas une règle absolue, mais essayer de la respecter est une bonne pratique, et avoir un nom de variable de 48 caractères est assez stupide. Je leur suggérerais de suivre cette règle à partir de maintenant, mais de ne pas les autoriser à changer les noms de variable qu'ils ont choisis. Vous allez essayer de leur imposer une nouvelle pratique (en supposant qu'ils ne font pas déjà des lignes courtes), les stagiaires qui ne comprennent pas pourquoi les noms de variables longs sont mauvais vont le découvrir, et les stagiaires “intelligents” découvriront bientôt qu'ils ne sont pas aussi intelligents qu'ils le pensaient.

Il est évident pour les codeurs plus expérimentés pourquoi convertToMillilitersBecauseIAmUsingSuchCleanCode est particulièrement mauvais, mais plutôt que de leur dire “c'est mauvais”, forcez-les à découvrir pourquoi. Je parie que vous rencontrerez beaucoup moins de noms verbeux et, avec de la chance, moins de tentatives futures de s'énerver également.

Il ne s'agit pas forcément d'une “taille unique”. Toutes les tailles conviennent à certains:

Chacune des approches proposées peut fonctionner à merveille et peut être la meilleure approche selon les circonstances. Voici ma réponse à chacune des approches demandées :

Dois-je réagir par

• en riant (“Oui, c'est drôle mais enlevez ça s'il vous plaît”)

C'est une excellente idée quand : Vous avez un excellent rapport avec ces collègues, qui sont devenus de bons amis de

• en demandant poliment de le retirer

This is a great idea when : Vous voulez être direct pour qu'il n'y ait pas de malentendu

• en disant que je n'aime pas quand quelqu'un me fait perdre mon temps et qu'il devrait prendre la révision du code plus au sérieux

C'est une bonne idée quand Vous souhaitez communiquer la gêne, et vous en tenir à une approche autoritaire

(je suis enclin à penser que vous pourriez combiner toutes ces approches en une manière non offensante, polie, drôle qui communique qu'il y a un peu de gêne réelle. “Ce genre de choses doit cesser parce que cela me fait juste aller [mock-scream] ” pourrait être une façon humoristique d'accomplir cela).

Personnellement, j'aime la méthode amicale. Je crois en cette façon de faire. Cependant, j'admets volontiers qu'il y a des moments où de telles approches sont moins efficaces.

**Mais qu'est-ce qui est le mieux ? Votre question de base est : “Comment dois-je réagir face à cela ?”

En gros, cette question revient à dire “J'ai besoin d'aller quelque part. Dois-je utiliser un monocycle, un pogostick, un vélo ou un bus ?”

N'importe lequel de ces moyens de transport peut être le meilleur. De même, pour répondre à la question de savoir comment vous devez réagir : “Votre meilleure réaction pourrait ne pas être ma meilleure réaction”

C'est une raison essentielle pour laquelle, même si les différentes réponses semblent convenir que le comportement des stagiaires n'est pas adapté aux résultats de la production, les différentes réponses semblent favoriser des approches différentes. Comme indiqué, il se peut que nous n'ayons pas une seule approche “taille unique” qui fonctionnera universellement au mieux pour tout le monde.

Nous avons affaire à des gens ici, donc ce qui fonctionne le mieux dans certains scénarios peut ne pas fonctionner aussi bien dans d'autres. L'un des facteurs clés, c'est vous. Pouvez-vous être sévère sans brûler les ponts ? Pouvez-vous vous lier d'amitié avec eux en faisant preuve de légèreté, tout en leur assurant suffisamment de respect et d'inspiration pour obtenir les résultats souhaités ? Ce qui fonctionne le mieux pour moi peut être atrocement terrible pour vous. En fin de compte, vous devez décider laquelle de ces approches adopter.

Enseignement flexible: Ne vous engagez pas dans une seule approche.

Choisissez simplement la méthode avec laquelle vous vous sentez le plus à l'aise. Veillez à ne pas en faire trop (mauvaise humeur/offensive, ou création d'un environnement inconfortablement menaçant dans un effort de rigueur).

Peu importe laquelle de vos excellentes suggestions vous décidez de mettre en œuvre pour aller de l'avant, gardez un œil sur les résultats.

Il est très possible que vous portiez un jugement qui ne fonctionne pas comme vous l'espériez. Tant que vous n'avez pas causé de problèmes majeurs, vous pouvez vous en remettre, à condition de le gérer de manière positive et rapide. C'est l'une des raisons pour lesquelles vous ne devriez pas trop vous soucier d'essayer de prendre la décision la plus parfaite. Si les choses ne se passent pas bien, votre situation peut s'arranger. Les gens sont différents, et l'apprentissage peut être imprévisible, et il ne faut pas avoir honte d'une première approche à modifier. Tant que vous vous rétablissez rapidement, cela peut ne pas être un problème.

L'essentiel est d'apporter des changements dès que vous commencez à trouver des résultats indésirables. Attendez-vous à devoir vous adapter rapidement. Lorsqu'une approche ne fonctionne pas, soyez très prêt à la modifier rapidement, voire à la jeter par la fenêtre. Si ce que vous faites ne fonctionne pas, déterminez si vous êtes sur le point de faire une percée ou si vous devez essayer quelque chose de différent. Si vous avez besoin d'essayer autre chose, faites-le. Tant que vous agissez rapidement (avant que des sentiments à long terme comme l'amertume ne commencent à s'installer), les petites imperfections peuvent facilement être écartées comme étant insignifiantes par rapport aux résultats positifs que vous obtenez globalement. (Assurez-vous simplement que si les choses se passent imparfaitement, les problèmes sont mineurs. Les erreurs majeures peuvent être un peu plus difficiles à oublier. Par exemple, une tentative d'humour peut être dangereuse).

Par exemple, si vous constatez qu'ils commencent à vous haïr, à redouter l'environnement, etc. Assurez leur que vous êtes de leur côté. Encouragez le comportement souhaité. etc.

Il y a deux ans, j'occupais un poste similaire à celui des stagiaires de votre entreprise. Je peux imaginer un scénario dans lequel j'aurais fait quelque chose de similaire. Je pense que certains stagiaires ont un problème avec votre autorité ; étant pédant et\ou non professionnel. Cela est principalement dû au manque de respect de ma génération envers les anciens et les personnes occupant des postes plus élevés. J'essaierais les méthodes suivantes pour résoudre la situation.

• Gagner le respect des stagiaires en déjouant le “leader”, “alpha”.

• Utiliser le nom de fonction pédant comme une leçon pour tout le monde, longueur optimale du nom de fonction : la zone de Boucle d'or.

• Signalez une faille dans la fonction “convertToMillilitersBecauseIAmUsingSuchCleanCode” et suggérez un renommage approprié (/démoralisant)

• Ne faites pas attention, ignorez le nom de la fonction ; concentrez votre temps sur les personnes qui veulent apprendre.

Je noterais les noms des stagiaires non professionnels par précaution.

Devrais-je réagir d'ici à

• en riant (“Ouais, c'est drôle mais enlevez ça s'il vous plaît”)
• en demandant poliment d'enlever
• en disant que je n'aime pas quand quelqu'un me fait perdre mon temps et qu'il devrait prendre la révision du code plus au sérieux

Que diriez-vous de “ *Comprendre pourquoi ils ont fait ça ? *”

Chaque fois que quelqu'un fait quelque chose que vous n'attendez pas ou ne souhaitez pas qu'il fasse, vous pouvez soit réagir afin de lui faire faire la chose que vous voulez ou vous pouvez essayer de comprendre pourquoi il a fait exactement cela.

Il pourrait être utile de comprendre pourquoi. S'ils sont de nature enjouée mais qu'ils n'arrivent pas à exprimer leurs frustrations à propos de quelque chose, c'est ainsi que quelqu'un peut le canaliser. Nous sommes tous d'accord sur le fait que ce n'est pas une façon positive de la canaliser.

Une approche alternative

Alors qu'est-ce qui est une façon positive de canaliser la frustration et l'enjouement ? J'ai travaillé dans des entreprises où les gens faisaient parfois des projets 10 % du temps, comme programmer un microcontrôleur pour prendre un selfie avec un dslr. Non seulement ils étaient libres de le faire, mais ils avaient aussi la responsabilité de transformer cela en un produit livrable. Il est passé d'un hackathon d'une journée à des exemples de codes qui sont maintenant publiés sur le site web de l'entreprise. Les gens peuvent prendre cet exemple et le transformer en une télécommande pour les caméras de haute mer qui peut être mise en marche d'un simple clic.

Ce que je veux dire, c'est que des farces comme celle-ci peuvent être l'indication d'un potentiel inexploité. Si vous voulez des stagiaires conformes aux normes de votre entreprise, ce potentiel n'est pas pour vous et dans ce cas, envisagez de les laisser partir. Cependant, si vous voyez l'intérêt de secouer les choses, demandez à ces farceurs de créer quelque chose d'utile avec leurs farces. En fin de compte, c'est à vous de décider. **Qui voulez-vous que ces stagiaires soient ?

En tant que professionnel depuis près de 30 ans maintenant, je dirais que les réponses les mieux notées ont pour la plupart raison.

Cependant, en tant que développeur de logiciels professionnel depuis près de 30 ans maintenant, je dirais que les directives de codage sont presque toujours sur-prescriptives. Pire encore, elles sont souvent saisies par des personnes plus soucieuses de leur Autoritah que de la production d'un code lisible. Ce genre de comportement passif-agressif de la part des ingénieurs débutants est exactement ce que l'on voit généralement lorsque cela se produit.

Mettre des choses idiotes dans les commentaires de code, ou même le nom des identificateurs, est vraiment une tradition bien ancrée chez les développeurs de logiciels. Voici un exemple de dénomination de protestation induite par les normes de my own junior days (qui a reçu 48 votes positifs).

S'il y a un problème ici, c'est qu'il y a des problèmes légitimes de lisibilité/maintenabilité de leur code source dans votre environnement. Je ne dis pas que les principales réponses sont fausses. Elles ne le sont pas. Mais quand vous voyez ce genre de comportement de la part de plusieurs ingénieurs juniors, alors après avoir nettoyé les corps, vous devriez vraiment chercher à savoir si il pourrait y avoir une raison sous-jacente pour laquelle vos canaris continuent de mourir.

Le but final doit être la qualité du code. Les directives de codage devraient être simplement leur outil pour les aider à y parvenir, construites par des développeurs pour des développeurs, et non pas une sorte de programme autoritaire sur la façon d'écrire des programmes.

Il semble que vous ayez un très bon exemple pour leur montrer pourquoi l'utilisation de ce type de convention de codage est inappropriée, même pour de petits projets comme celui-ci.

Vous l'avez vu.

Même si leur projet n'est pas utilisé directement par l'entreprise, il est censé servir d'évaluation de leurs compétences et, en partie, d'expérience d'apprentissage pour ces stagiaires qui cherchent à faire leur chemin dans votre entreprise.

Je ne serais pas trop dur avec eux - après tout, ce n'est qu'un essai pour eux - mais je tiens à souligner qu'à l'avenir, de telles pratiques de codage pourraient leur attirer des ennuis, surtout si leur prochain patron n'est pas aussi patient avec eux que vous.

Tout d'abord, je ne pense pas que ce soit c'est mauvais. Ils ont mis une blague dans le code sur un sujet (les conventions de noms) qu'ils ne saisissent probablement pas complètement. Placer des blagues internes dans le code n'est pas quelque chose de nouveau. De plus, ils peuvent considérer le code comme une “feuille interne”.

Je ne suis pas non plus d'accord avec l'idée qu'ils vous fassent perdre votre temps avec cela. S'ils font un commit juste pour renommer une méthode, alors oui, ils vous font perdre votre temps, et le changement devrait être rejeté. Mais s'ils avaient besoin d'une nouvelle méthode et choisissaient un nom médiocre, le temps de révision serait similaire avec l'un ou l'autre nom. Je ne sais pas si vous examinez un pré-commit ou un post-commit, mais lorsque quelqu'un veut faire approuver/fusionner du code, ce qu'il fait va en fait à son encontre, car il ajoute simplement des allers-retours pour faire accepter le code. Il est également trivial pour vous de donner une note négative avec de mauvais noms, sans vraiment regarder ce que fait le code. Le problème, c'est que vous vous sentez ennuyé par ces noms.

Maintenant, pour en venir à la question de savoir quoi faire, je recommande de leur dire qu'ils ont eu des problèmes avec les conventions de noms et de leur demander de revoir le travail de la semaine dernière pour voir s'ils ont utilisé des noms propres et de penser s'ils le comprendraient facilement dans quelques années / s'ils étaient nouveaux dans ce projet. Demandez-leur de préparer un bref rapport sur les fonctions qu'ils ont ajoutées cette semaine et de le justifier brièvement.

Dans l'idéal, cela devrait être environ une ligne par fonction, par exemple

convertGalToml : Convertit les gallons en millilitres. L'abréviation “Camel case” n'a pas été utilisée pour les millilitres afin d'éviter toute confusion avec les mégalithes.

On s'attend à ce que, lors de la révision du code, les utilisateurs remarquent de nouveaux problèmes ou trouvent un meilleur nom, par exemple renommer convertGalToml en convertGal2ml.

Je pense que votre joker comprendra et renommera en silence.

Le fait est que les noms de fonctions sont des documents. Bien qu'il s'agisse d'un public plus technique que, par exemple, le manuel d'utilisation, ils devraient être à l'aise pour justifier leur choix devant leurs pairs.

En commençant par supposer la bonne foi, mon instinct me dit que les stagiaires ont fait cela parce qu'ils ne voient vraiment aucun problème avec des noms comme convert. Je parierais une petite somme d'argent que les noms sarcastiques ne viennent pas d'un désir d'être rebelle mais de la frustration qu'ils ne savent pas comment trouver un meilleur nom, seulement un plus long nom. Et c'est un peu ce que vous leur avez dit, non ? Si vous voulez que ces personnes s'améliorent, vous devez simplement discuter, lors de la réunion quotidienne, des raisons pour lesquelles le nom de convert est mauvais et celui de convertInchesToCentimeters est meilleur. Si vous avez un exemple, tiré de votre expérience, de mauvais choix de nom causant des problèmes, cela les aidera. Ce “pourquoi” leur permettra de choisir de bons noms à partir de maintenant - que ces bons noms soient longs ou courts.

Faites-leur également savoir qu'il est normal de vous demander de l'aide ou de consulter leurs pairs dans la limite du raisonnable, qu'il ne s'agit pas d'un test où chacun doit travailler seul, mais d'une collaboration. (J'espère que c'est vrai !) Peut-être que cela leur permettra de poser des questions et de se parler, et de résoudre leurs frustrations rapidement, plutôt que d'attendre que des choses passives-agressives comme celles-ci se manifestent lors de la révision du code.

Ce n'est que si un tel comportement se poursuit que je trouverais nécessaire d'expliquer, oui ce n'est pas une véritable application, mais cet exercice et les directives de style devraient être pris au sérieux pour de multiples raisons :

• Cela vaut la peine que je passe du temps avec vous sur cet effort, alors que je pourrais travailler sur de “vraies” candidatures, alors faites aussi de votre mieux
• Cet exercice vous prépare à travailler sur un projet réel qui est sérieux et dans lequel vous devez suivre les directives de style
• Cet exercice nous permet de décider à qui de vous, le cas échéant, adresser des offres d'emploi après la fin de votre stage

Bien que ce ne soit pas exactement faux, je pense que les accuser de manque de respect, etc. à ce stade fera probablement taire le comportement, mais ne les aidera pas non plus à comprendre pourquoi ils ont besoin de meilleurs noms ou comment trouver de meilleurs noms. Si vous suivez cette voie, vous risquez de les trouver en train de trouver des noms plus longs et de ne pas vous laisser guider par votre regard d'acier.

Vous n'êtes pas leur manager, peu importe que vous les interrogiez ou non. Vous êtes un ingénieur comme moi,

Donc vous savez quoi faire, parlez à votre manager et proposez-lui une révision de code. Ensuite, conseillez-lui de ne pas écrire de code de cette manière via un système comme le code collaborateur. Vous n'avez même pas besoin de leur envoyer un e-mail, d'interagir avec eux ou de prendre ces choses personnellement. Introduisez un système de notation basé sur cette révision de code. N'essayez pas de les contrôler ou d'être leur manager, ni d'essayer de gérer les gens. Ce n'est pas votre affaire.

Parlez à votre manager et gardez pour vous le privilège de rejeter ou d'approuver les engagements après une révision. Supposons que chaque stagiaire ait 10 points au départ et qu'il obtienne 100 points grâce à votre notation. S'il veut vraiment rejoindre votre équipe, il sera motivé pour le faire. Si j'étais un stagiaire et que je travaille sous vos ordres et que vous n'êtes qu'un ingénieur supérieur, même si je déteste que vous vous occupiez de la gestion de mon personnel. Ce n'est pas ton travail.

Il me semble que tu es allé trop loin et que c'est devenu incontrôlable. Apprenez cette leçon en tant qu'ingénieur. Vous êtes un ingénieur, pas un gestionnaire de personnes pour les gérer.

Si le comportement des stagiaires peut être peu professionnel, il est également peu professionnel pour la direction de ne pas considérer qu'ils pourraient avoir tort. Il est clair que convert est peut-être trop court ou trop ambigu dans de nombreux contextes, mais convertGallonsToMilliliters est beaucoup trop long pour un nom d'identification. Plutôt que d'imposer des exigences arbitraires en matière de verbosité des noms à tous les niveaux, vous devriez demander à vos stagiaires de justifier lorsqu'un nom qu'ils choisissent est vraiment ambigu (ce qu'ils ne pourront pas faire) et de trouver quelque chose de raisonnable qui améliore la lisibilité du programme plutôt que de l'entraver.

Cela me semble vraiment être un cas du schéma commun “pourquoi mes subordonnés ne me respectent-ils pas ?” étant en réalité une question de “qu'en est-il de ma propre attitude qui fait que les gens ne respectent pas ma position ?