Que feriez-vous de ceci; pensez-vous que mon langage n'était pas professionnel?

Oui.

Votre commentaire a franchi la ligne de la correction (qui repose généralement sur des commentaires spécifiques et concrets) à l'insulte ("ceci est terrible et si nous continuons, nous sommes condamnés ").

Peu importe l'expérience que vous avez. Ce n'est pas grave si le code est une poubelle complète. L'honnêteté n'est pas une excuse pour être impoli. C'est l'un des moyens les plus rapides d'arrêter les progrès et l'élan d'une équipe. Peu importe votre expérience ou votre productivité individuelle, vous allez globalement nuire à votre entreprise si l'attitude que vous projetez sur le lieu de travail gêne vos collègues.

La raison pour laquelle cela est particulièrement gênant (et pourquoi votre direction probablement répondu si sévèrement) est parce que cela nuit réellement à votre équipe à long terme. Sachez que si votre objectif est d'améliorer la qualité réelle du code produit par votre équipe, cela nuira activement à vos objectifs. La raison en est que lorsque vous avez la réputation d'être critique et non utile, les gens ne viennent pas vous demander de l'aide (et ne vous écoutent généralement pas lorsque vous essayez de vous aider). En conséquence, toute expérience que vous avez sera perdue avec le temps, car les gens cesseront de vous écouter.

Soyez poli. Offrez de l'aide et des corrections, et non des critiques. Je pense personnellement que dans des situations comme celle-ci, des excuses (à la fois à la personne en question et à l’équipe) sont très raisonnables.

Modifier pour ajouter il est certainement bon qu'il y ait également une critique utile, mais gardez à l'esprit que la perception est aussi importante que la réalité. Dans de nombreux cas, il suffit d'un seul mot mal choisi pour annuler tout bien réel que la révision du code lui-même fait. Un examen du code très instructif qui se termine par (et je comprends que ce n'est pas exactement ce qui s'est passé) "dans l'ensemble, c'est des ordures" va toujours laisser au codeur une très mauvaise impression dans l'ensemble, et il est fort probable qu'il s'arrête écouter tout ce que vous dites. Il est important de garder le tout professionnel, à chaque étape du processus.

C'est le pire du manque de professionnalisme dans la technologie de l'information de se moquer du code d'autrui de cette manière et cela va au-delà de la dérision jusqu'à la façon dont vous avez fait valoir le point.

1. Cela a été fait publiquement , c'est pourquoi vous avez été écarté (virtuellement)
2. Cela perturbe une équipe.
3. Cela engendre du ressentiment.
4. Les codeurs, comme les artistes, prennent la critique TRÈS personnellement.
5. C'était une chose extrêmement démotivante à dire. La productivité de ce codeur va en pâtir.
6. Cela rend les autres moins disposés à prendre des risques, de peur de se faire ridiculiser.

Je dois dire dans les termes les plus forts possibles que c'est une MAUVAISE CHOSE . Il n'y a aucune excuse pour ce comportement. Ne le répétez pas.

J'ai mes propres sentiments et bon nombre d'entre nous ici sont d'accord. Je peux gérer quelqu'un qui a écrit du mauvais code avec beaucoup moins de stress que quelqu'un avec une mauvaise attitude. Je peux toujours vous aider à améliorer votre code, mais l'attitude d'une personne est hors de mon contrôle et je ne traiterai pas avec quelqu'un avec une mauvaise attitude.

Il peut être difficile pour une personne offensée par un langage comme celui-là d'expliquer sa réaction à des personnes qui ne sont pas offensées par un langage comme celui-là. Une règle empirique qui fonctionne généralement: si la déclaration critique porte sur des généralités au-delà d'un incident spécifique, elle est offensante (donc non professionnelle).

En d'autres termes, l'expression la plus professionnelle serait de vous en tenir à votre examen détaillé, qui était spécifique au code particulier en cours d'examen. Vous pourriez expliquer que ce mauvais code va améliorer le score de qualité du code, ce qui signifie que nous devons également travailler sur les métriques de qualité. Les gens sont prêts à travailler et à apprendre d'un incident grave. Tout est dans le contexte.

Mais lorsque vous passez à un contexte global, c'est ce que votre seul commentaire a fait (oui, juste une phrase!) Maintenant vous critiquez les employés eux-mêmes, ou toute l'entreprise, et c'est plus menaçant. Cela conduit (comme d'autres réponses le mentionnent) au ressentiment, à la déconnexion et à une perte d'énergie collaborative.

Vous pouvez trouver cette différence entre la critique globale et la plainte spécifique à une instance dans la littérature sur les relations. L'explication de John Gottman (voir "critique") est un exemple populaire.

Les mots que vous choisissez comptent, mais le contexte compte plus. Il est tout à fait normal (dans la plupart des magasins de logiciels que je connais) de dire «garbage in, garbage out» parce que cela a une signification spécifique et que vous utilisez l'expression pour décrire pourquoi une conception particulière ne convient pas. Allez comprendre.

direct, honnête et simple.

Dit autrement: dur, abrasif, non diplomatique.

La chose difficile à apprendre pour nous les programmeurs est que les êtres humains ne sont pas des machines. Ils ne sont pas intéressés par la vérité nue. Les êtres humains sont des animaux sociaux et nécessitent un bon niveau de diplomatie pour communiquer.

Certains vont même jusqu'à dire que le véritable but de la communication n'est pas de transmettre des informations, mais de renforcer l'amitié. Je n'irais pas aussi loin, surtout dans un cadre professionnel, mais c'est quelque chose que vous ne devez jamais oublier: même dans des circonstances où rien n'est dit sur vous, "direct, honnête et direct" peut en fait laisser les gens mécontents de vous , ce qui peut nuire à vos relations de travail plus tard. Idéalement, vous voudriez toujours prendre en sandwich une couche de critique entre les couches de compliments.

Ce qui est considéré comme un langage approprié pour un commentaire dépendrait entièrement de la culture de votre entreprise, mais appeler simplement le code de quelqu'un "poubelle" (et les crochets suggèrent que vous avez en fait utilisé un autre mot moins poli) n'est certainement pas très constructif. Cela n'aidera personne à s'améliorer.

Quel était le problème avec le code? Comment auraient-ils pu l'améliorer? Que devrait faire le développeur différemment? C'est la seule information que vous auriez dû inclure. Si c'était si mauvais que d'aller au-delà de la portée d'un commentaire, vous auriez dû écarter le développeur et en discuter en personne.

En tant que chef d'équipe, et celui qui a de l'expérience, il vous incombe d'aider votre équipe s'améliore. C'est ton travail. Les rabaisser dans un commentaire de révision de code n'apporte rien de bon.

Que feriez-vous de ceci; pourquoi pensez-vous que mon langage n'était pas professionnel?

Alors ... voici l'affaire:

• Vous êtes le chef d'équipe; cela signifie que vous êtes censé constituer l'équipe, pas la battre.

• Le code est le travail du développeur; le qualifier de poubelle par écrit devant ses pairs est un coup dur.

D'accord, c'est la partie qui répond directement à la question. OK pour arrêter de lire maintenant. Partie suivante ... qu'auriez-vous pu faire différemment?

• Gardez les suggestions détaillées, elles sont bonnes

• Dans le ' dans l'ensemble ', disons que ce fichier ne suit pas les meilleures pratiques selon les notes détaillées ci-dessous

• Faites une pause, soit 1-1 avec le gars, soit une session de formation avec le l'équipe pour passer par les meilleures pratiques. En d'autres termes, transformez cette erreur en opportunité

Juste mes deux éléments, yo.

Cela dépend beaucoup de la culture d'entreprise. Cependant, il y a quelques éléments généraux à considérer. Il y a principalement deux raisons pour lesquelles appeler du code garbage peut être considéré comme non professionnel:

1. Cela ne donne pas - en soi - un aperçu de ce qui est mauvais ou comment améliorer la situation, il donne juste ce code une valeur (faible), alors que généralement vous voulez regarder ses avantages et ses inconvénients plutôt que de la considérer comme généralement mauvaise ou bonne
2. cela peut être offensant pour un collègue, c'est-à-dire la personne qui a écrit ce code

Quant à 1), cela peut être atténué en fournissant des détails concrets sur ce que vous pensez être mauvais et comment y remédier. En règle générale, il y a des raisons pour lesquelles les choses sont telles qu'elles sont et ce n'est pas que quelqu'un voulait simplement écrire des ordures. Le code était peut-être parfait pour le travail auquel il était destiné lorsqu'il a été écrit, mais le contexte a changé.

Comme pour 2), si le code auquel vous faites référence est un commit récent d'une personne en particulier, cette personne pourrait se sentir offensée. Surtout s'il avait des raisons d'écrire quelque chose d'objectivement mauvais, comme des contraintes de temps, dont vous ne tenez pas compte. Et souvent, ce qui est une poubelle pour vous est parfait pour quelqu'un d'autre, le qualifier de poubelle ne fait qu'apporter des émotions dans ce qui autrement aurait pu être une discussion objective bien fondée. À l'autre bout du spectre - si vous reprenez une ancienne base de code volumineuse que personne dans l'équipe actuelle ne considère déjà comme «son code», il est assez impersonnel d'appeler ce gros tas de déchets de code probablement alambiqués (ne traite toujours pas 1 Cependant, et vous feriez mieux de le sauvegarder) .Un autre problème est de savoir comment vous livrez une ligne contenant des jurons. Le plus chargé émotionnellement (et accusant) le pire, le plus léger, peut-être ironiquement dirigé contre vous-même, le plus acceptable.

Donc, si vous n'êtes pas sûr, n'appelez jamais quelque chose d'ordures. Si vous voulez tester les eaux, commencez à utiliser un langage de valorisation pour le code auquel personne ne se sent attaché (ou à votre propre code) et sauvegardez-vous avec quelques détails sur ce que vous n'aimez pas.

Que les gens réagissent offensés et vous considèrent comme (non) professionnel uniquement en fonction des mots que vous utilisez dépend de la culture de l'entreprise. Cependant, universellement, les gens vous jugeront en fonction de la façon dont vous utilisez vos mots. Si vous appelez simplement stuff garbage sans discuter de votre point de vue, sans accepter un autre argument des développeurs expliquant pourquoi le code est bon tel quel, les gens penseront que vous êtes déraisonnable et critique. Et donc peu professionnel. Surtout si vous blâmez explicitement ou implicitement vos collègues pour ce que vous considérez comme un mauvais code. Cela est vrai que vous utilisiez des jurons ou non, c'est-à-dire dire "ce code est juste mauvais", sans autre commentaire, n'est pas non plus professionnel, mais plus vous utilisez des mots chargés d'émotion (et plus vous les présentez émotionnellement), plus cela empire.

Cela étant dit, si vous utilisez des mots grossiers de manière raisonnable sans les diriger vers votre collègue -travailleurs mais plutôt pour donner du poids à vos impressions ou évacuer une certaine frustration, cela peut être tout à fait correct. J'ai travaillé dans un environnement où le ton était très direct, ludique et les phrases souvent pleines de jurons. Mais typiquement, un tel juron était dirigé vers des problèmes techniques, la façon dont certains frameworks se comportaient de manière imprévisible ou même à son propre code ("Regardez les ordures que j'ai faites là-bas, c'est incroyable que j'ai écrit ce truc!"). D'un autre côté, j'ai rarement vu une équipe travailler avec autant de professionnalisme - se respecter mutuellement, toujours chercher comment résoudre le problème et non comment répartir le blâme.

TLDR : utiliser des jurons pour décrire du code n'est pas nécessairement non professionnel en soi. Dans certains contextes culturels, cependant, toute utilisation de jurons est considérée comme non professionnelle / offensive. C'est votre travail de déterminer si c'est le cas dans votre environnement avant de les utiliser, ne pas faire cela en premier n'est pas professionnel. Si le code (d'une autre personne) est absolument valorisé, en utilisant des jurons ou non, sans a) donner des détails et b) sans séparer cette critique de la personne et c) sans savoir que l'autre personne peut séparer la critique de son code et la critique d'elle-même, ce n'est pas non plus professionnel. Dans votre entreprise actuelle, les gens ne sont évidemment pas habitués aux jurons / jurons et considèrent qu'il s'agit d'un mauvais comportement - alors ne le faites pas.

Vous avez envoyé ce commentaire dans la mauvaise direction

Lors de la première lecture de votre message, j'ai supposé qu'il s'agissait d'un commentaire adressé à votre direction, et ma première réaction a été "Eh bien, si n'aime pas la vérité - ils devraient cesser de forcer votre équipe à utiliser des métriques aussi stupides. "

Et si c'était la situation réelle (que le commentaire remontait dans la chaîne ) - ça irait bien. Peut-être un peu peu professionnel , mais de manière réaliste, c'est le moyen le plus simple d'alerter la direction qu'elle est en train de foutre votre équipe.

Cependant, il semble que ce ne soit pas là le commentaire est allé. Au lieu de vous battre au nom de votre équipe contre la direction - pour supprimer des métriques stupides qui, selon votre équipe, provoquent l'écriture d'ordures - vous avez fait le contraire et mettez votre équipe dans un "damné si vous le faites, damné si vous ne le faites pas "situation.

Les métriques pour la qualité du code, je doute qu'elles aient été créées par votre équipe. Ils ont probablement déjà l'impression que ce sont des cerceaux idiots qu'ils sont obligés de franchir.

Leur dire que le code qu'ils écrivent est "garbage"; à cause d'un système sur lequel ils n'ont aucun contrôle - cela signale simplement que vous n'avez pas le dos et que vous ne vous souciez pas de mener leurs batailles.

Le manque de professionnalisme, et où le problème a provient de, n'est pas simplement le libellé du commentaire. C'est le sentiment que vous allez baiser votre équipe dans les deux sens.

À juste titre, ils vous ont tenu tête à ce sujet. Leur réponse est en fait "essayez de nous blâmer pour cela, et nous expliquerons très clairement en quoi cette situation est de votre faute."

Le langage que vous avez utilisé leur a peut-être donné plus de arguments pour vous combattre sur - mais ce n'est absolument pas la raison principale pour laquelle vous obtenez un rejet.

Outre le langage offensant, votre commentaire contient également zéro contenu sur ce qui ne va pas dans le code et contient un sous-texte qui s'oppose aux objectifs de votre équipe.

Si l'amélioration du score de qualité du code

L'objectif collectif est donc d'améliorer la qualité du code. Pourquoi ne dites-vous pas "Nous voulons améliorer la qualité du code" alors? Pourquoi prenez-vous cet extrait de code comme un argument pour ne pas améliorer la qualité du code.

Pour moi (en tant que développeur moins expérimenté que vous), cela ressemble à un commentaire de quelqu'un qui est habitué à ses anciennes méthodes et qui n'accepte pas le changement (même s'il est surnommé "la qualité du code").

nous devons introduire des ordures comme ci-dessous

Vous avez peut-être déjà compris qu'appeler des choses que d'autres personnes écrivent "garbage" n'est pas un bon moyen d'obtenir l'approbation, vous ne fournissez absolument aucune information sur les raisons pour lesquelles quelque chose pourrait être faux avec les "ordures comme ci-dessous", à part le fait que cela vous a frotté dans le mauvais sens.

Un développeur LEADING avec 15 ans d'expérience devrait être en mesure de fournir plus d'informations que d'appeler quelque chose de "garbage".

alors nous avons de sérieux problèmes.

Pourquoi? Pourquoi? Pourquoi? Utilisez votre expérience pour identifier le problème au lieu de simplement dire qu'il y en a un. Et si vous êtes vraiment aussi bon dans votre travail, indiquez une meilleure solution, afin que votre équipe sache où elle se dirige.

Désolé, mais votre commentaire (extrait) est vraiment nul. De par sa définition même, il peut être jeté dans la poubelle.

Concernant la mise à jour 1 : si votre commentaire complet était détaillé et fournissait toutes les informations. Pourquoi était-il nécessaire d'insulter le développeur (et de remettre en question les objectifs de votre équipe) en plus?

Si l'amélioration du score de qualité du code signifie que nous devons introduire des déchets comme ci-dessous, alors nous avons de sérieux problèmes.

Il y a certaines situations où le code peut être appelé «garbage». Tels que l'allocation de mémoire ou le code inaccessible. Cependant, je ne pense pas que vous le pensiez de cette manière.

Cependant, je pense que vous devriez utiliser les termes appropriés lorsque vous vous référez à certains styles de programmation. Les choses que je vois principalement sont des conditions de course, des vérifications conditionnelles de boucle racontent le tableau chaque boucle quand elle ne change pas, etc. Je voudrais commenter spécifiquement ce qui ne va pas, ou si des fonctions alternatives peuvent être utilisées pour l'écrire.

La plupart des autres réponses étaient antérieures à votre modification concernant ce code suggéré par un outil automatique, alors laissez-moi aborder cette partie spécifiquement.

Vous avez estimé que ce code était un jeu juste pour des critiques plus sévères car il provient d'un outil, pas d'un humain, mais vous n'avez pas pensé:

• Un ou plusieurs humains ont pris la décision de donner à cet outil un rôle important dans l'évaluation de la qualité du code.
• Un humain a décidé de copier / coller la suggestion de l'outil au lieu de résoudre le problème de qualité d'une manière plus lisible, soit parce que cela ne lui venait pas à l'esprit, cela pourrait être mieux fait, soit il ne savait pas comment pour mieux le faire.

En d'autres termes, il y a encore des décisions humaines dans la boucle qui sont prises dans le dénigrement. Je formulerais plutôt votre objection comme suit:

Je ne pense pas que la suggestion de l'outil de qualité soit très utile dans ce cas particulier, et cela me frustre que l'outil soit si souvent trompeur comme celui-ci. Ce n'est pas évident, mais le problème sous-jacent pourrait être résolu de manière plus lisible en…

Cela montre clairement que votre frustration provient de l'outil de qualité et non de l'auteur du code, et émet votre critique constructif en offrant un moyen de résoudre le problème.