Post-réponse à l'article "Allez! @ # Avec votre" toxicité " . "
Si je suivais les conseils de cet article, il me suffirait de montrer de l’émotion et de dire à l’auteur "Allez-y ... vous ne comprenez rien!".
Cependant, cela n'aiderait pas à transmettre mon idée. Par conséquent, regardons de plus près.
Quote 1:
Si une personne est incompétente, vous devez lui faire clairement comprendre cela et ne pas protéger ses sentiments tendres au détriment de tout le monde.
Je ne suis pas d'accord avec la base de cette déclaration. Je crois qu'une personne ne peut pas être compétente ou incompétente. Une telle approche généralisée en noir et blanc ne fonctionne pas dans la pratique. Même l'aîné le plus avancé peut ne pas savoir certaines choses. Et vice versa, les juniors ont parfois de bonnes idées.
Passer à des personnalités («vous n'êtes pas compétent!») Il est trop facile de coder la révision au lieu d'arguments spécifiques. Si vous êtes une personne âgée si intelligente, travaillez dur, expliquez pourquoi à cet endroit du code, tout devrait être différent. Vous ne pouvez pas expliquer - il vaut mieux ne rien écrire, car il est possible que vous-même ne compreniez pas complètement.
En même temps, bien sûr, il est nécessaire de parler de problèmes spécifiques dans le code.
Une personne normale est heureuse de discuter d'une position raisonnée. Et il prendra des émotions négatives d'hostilité. Qui voudrait jamais travailler avec un membre toxique de l'équipe?
Quote 2:
Une personne peut-elle vous envoyer un code avec les mêmes erreurs encore et encore et doit répondre avec politesse et sourire?
Si une personne fait des erreurs encore et encore et n'essaie pas de grandir d'une manière ou d'une autre, alors elle doit être renvoyée. Parlez-en au chef d'équipe. Mais l'hystérie n'est pas nécessaire de toute façon. Eh bien, tout simplement parce que cela n'aidera pas.
Les émotions négatives ne peuvent que donner lieu à des émotions négatives. Et cela ne résoudra pas les erreurs dans le code.
Quote 3:
Plus la responsabilité dans la profession est grande, plus la résistance au stress devrait être grande.
Je travaillais avec l'environnement de production et je résolvais les problèmes la nuit. Souvent, c'était du stress (surtout lorsque vous dirigez ces départements et êtes responsable de toute cette ferme collective).
Et je veux déclarer en toute responsabilité: personne n'aime le stress, même s'il est capable de le supporter. Tout le monde essaie toujours de réduire le stress.
Par exemple:
- configurer la surveillance, l'alerte en temps opportun des serveurs, qu'il y a des problèmes
- vérification du code par des tests automatiques et manuels
- sauvegardes de bases de données pour vérifier la récupérabilité
- etc.
En bref, nous réduisons les problèmes potentiels dès que possible.
C'est-à-dire le stress est mauvais en fait . Même pour les personnes les plus tolérantes au stress.
Juste la même personne qui n'aime pas le stress, très probablement fera tout bien, revérifiera tout, posera la paille et ne fera pas d'erreurs fatales.
Quote 4:
Sans aucun doute, il est inacceptable d'insulter un collègue par manque de connaissances, mais le format évident "Votre code est mauvais, je vais maintenant expliquer les raisons en détail et donner des conseils" est déjà considéré comme un comportement toxique.
Eh bien oui, ça l'est. «Votre code est mauvais» est une phrase dénuée de sens, il serait possible de commencer tout de suite avec des conseils, et encore mieux de clarifier les questions, pourquoi cela a été fait et pas autrement.
Postface
Le stress interfère avec les performances. Lorsqu'un employé a peur de donner un code pour une revue, il ne travaillera pas avec enthousiasme, il ne générera pas d'idées, il ne sera pas fidèle à l'entreprise, etc.
Des études facilement googlées qui montrent qu'en dépassant un certain niveau de stress, les performances diminuent fortement.
En général, la politesse quand on travaille en groupe n'est pas inventée maintenant, bien avant que la révision du code et la programmation ne deviennent à la mode en général. Un tas d'articles sur les "compétences de travail d'équipe" qui ne sont en aucun cas liées à l'informatique.
Les meilleures idées naissent dans une atmosphère favorable.
Prenons, par exemple, les règles du brainstorming: au début, tout le monde jette des idées, et vous ne pouvez pas du tout les critiquer. Et alors seulement vient une discussion détaillée.
Eh bien, c'est que nous sommes tous des gens. Les gens n'aiment pas quand quelqu'un souligne leurs erreurs. Même le code de révision le plus correct ressemble souvent à une flagellation publique. Eh bien, n'aggrave pas!
Dans les équipes où j'étais chef d'équipe, j'ai entré un bon code de conduite pour la révision du code (avant même que ce troupeau ne soit à la mode). A savoir: politesse, interdiction du ton de commandement, interdiction de discuter des qualités personnelles, seuls les commentaires motivés sont autorisés, etc. Dans les situations litigieuses, la majorité décide.
Au fait, c'est la majorité, pas le timlid / techlide. Étant donné que la lisibilité du code et d'autres choses sont importantes pour toute l'équipe, c'est l'équipe qui travaillera avec ce code à l'avenir. Et pas celui qui se considère le plus intelligent.
Ces mesures simples ont considérablement amélioré l'atmosphère de l'équipe.
Pourquoi tout le monde parle maintenant de CoC et de travail d'équipe? Parce qu'en général, le temps des génies célibataires passe. Une équipe soudée grâce à la synergie résoudra tout problème. J'ai parlé à l'un, à l'autre - et le fond du problème est résolu. Les compétences générales deviennent de plus en plus importantes chaque jour.
Il y a des gens qui n'ont jamais travaillé dans une équipe soudée et qui n'imaginent pas à quel point c'est excitant.
Oui, en fait je crucifie ici, allez-y ...
(PS l'émoticône à la fin de la dernière phrase a été supprimée par les modérateurs. Je ne veux offenser personne, c'est juste une blague)