Colère contre le code: programmeurs et négativité

Je regarde un morceau de code. C'est peut-être le pire code que j'aie jamais rencontré. Pour mettre à jour un seul enregistrement de la base de données, il extrait tous les enregistrements de la collection, puis envoie une demande de mise à jour de chaque enregistrement de la base de données, même ceux qui n'ont pas besoin d'être mis à jour. Il existe une fonction de carte qui renvoie simplement la valeur qui lui est transmise. Il existe des vérifications conditionnelles de variables ayant évidemment la même valeur, juste nommées dans des styles différents ( first_name et first_name ). Pour chaque MISE À JOUR, le code envoie un message à une autre file d'attente, qui est traitée par une autre fonction sans serveur, mais qui fait tout le travail pour une autre collection dans la même base de données. Je n'ai pas mentionné que cette fonction sans serveur provient d'une «architecture orientée services» basée sur le cloud contenant plus de 100 fonctions dans l'environnement?

Comment faire une telle chose? Je couvre mon visage et sanglote à travers le rire. Mes collègues demandent ce qui s'est passé, et je raconte en couleur les pires coups de BulkDataImporter.js 2018 . Tout le monde hoche la tête avec sympathie et convient: comment pourraient-ils nous faire ça?

Négatif: un outil émotionnel dans la culture du programmeur

La négativité joue un rôle important dans la programmation. Il fait partie intégrante de notre culture et est utilisé pour partager ce qui est reconnu ("vous ne croirez pas à quoi ressemblait ce code!"), Pour exprimer votre sympathie à travers un bouleversement ("Seigneur, pourquoi faire ça?") à la lumière («je ne ferais jamais ça»), de blâmer les autres («nous avons fait étalage à cause de son code, qui est impossible à accompagner»), ou, comme il est d'usage dans les organisations les plus «toxiques», de gérer les autres par honte ("À quoi pensiez-vous? Correct").



La négativité est si importante pour les programmeurs car c'est un moyen très efficace de transmettre de la valeur. J'avais l'habitude d'étudier dans un camp de programmeurs, et la pratique standard de vacciner les étudiants avec la culture de guilde était de fournir généreusement des mèmes, des histoires et des vidéos, dont les plus populaires exploitaient la déception des programmeurs lorsqu'ils étaient confus par les gens . C'est bien quand vous pouvez utiliser des outils émotionnels pour désigner le bien, le mal, l'horrible, ne faites jamais ça, jamais du tout. Il faut préparer les débutants au fait que leurs collègues, loin de l'informatique, les comprendront probablement à tort. Que leurs amis vont commencer à leur pousser des idées d'applications "dans un million". Ce qu'ils ont à errer dans les dédales sans fin de code obsolète avec un tas de minotaures au coin de la rue.

Lorsque nous commençons à apprendre la programmation pour la première fois, notre compréhension de la profondeur de «l'expérience de programmation» est basée sur des observations des réactions émotionnelles des autres. Cela est clairement visible dans les articles du subwoofer ProgrammerHumor , dans lesquels de nombreux nouveaux programmeurs se retrouvent. De nombreux messages humoristiques, à un degré ou à un autre, sont colorés avec différentes nuances de négatif: déception, pessimisme, ressentiment, indulgence et autres. Et si cela ne vous semble pas suffisant, lisez les commentaires.



J'ai remarqué qu'avec l'accumulation d'expérience, les programmeurs deviennent de plus en plus négatifs. Les débutants, inconscients des difficultés qui les attendent, commencent avec enthousiasme et volonté de croire que la raison de ces difficultés est simplement un manque d'expérience et de connaissances; et à la fin, ils seront confrontés à l'état réel des choses.

Le temps passe, ils acquièrent de l'expérience et acquièrent la capacité de distinguer le bon code du mauvais. Et quand ce moment arrive, les jeunes programmeurs sont bouleversés en travaillant avec un code apparemment mauvais. Et s'ils travaillent en équipe (à distance ou en personne), ils adoptent souvent les habitudes émotionnelles de collègues plus expérimentés. Souvent, cela conduit à une augmentation du négatif, car les jeunes peuvent désormais parler du code de manière réfléchie et le diviser en mauvais et bon, montrant ainsi qu'ils sont «dans le sujet». Cela renforce encore le négatif: en raison de la déception, il est facile de rencontrer des collègues et de faire partie d'un groupe, la critique du Bad Code élève votre statut et votre professionnalisme aux yeux des autres: les personnes qui expriment une opinion négative sont souvent perçues comme plus intelligentes et compétentes .

Renforcer le négatif n'est pas nécessairement une mauvaise chose. La discussion sur la programmation, entre autres, est extrêmement axée sur la qualité du code écrit. Le code détermine entièrement la fonction à laquelle il est destiné (nous jetons l'équipement, le réseau, etc.), il est donc important de pouvoir exprimer votre opinion sur ce code. Presque toutes les discussions se résument à savoir si ce code est assez bon et à condamner le manifeste lui-même du mauvais code dans des expressions dont la coloration émotionnelle caractérise la qualité du code:

• «Il y a beaucoup d'incohérences logiques dans ce module, qui est un bon candidat pour une optimisation significative des performances.»
• "Ce module est assez mauvais, nous devons le refactoriser."
• "Ce module n'a pas de sens, il doit être réécrit."
• "Ce module est nul, il doit être corrigé."
• "C'est un morceau de bélier, pas un module, il n'avait pas du tout besoin d'être écrit, ce que l'enfer pensait l'auteur."

Soit dit en passant, c'est cette «libération émotionnelle» qui oblige les développeurs à appeler le code «sexy», ce qui est rarement juste - à moins que vous ne travailliez dans PornHub.

Le problème est que les gens sont étranges, troublés, remplis d'émotions de création, et la perception et l'expression de toutes les émotions nous changent: au début, à peine perceptibles, mais au fil du temps - de façon spectaculaire.

Piste glissante agitée de la négativité

Il y a quelques années, j'étais chef d'équipe informelle et j'ai interviewé un développeur. Nous l'aimions beaucoup: il était intelligent, posait de bonnes questions, était techniquement averti et s'intégrait parfaitement à notre culture. J'ai été particulièrement impressionné par sa positivité et son caractère aventureux. Et je l'ai engagé.

À cette époque, j'ai travaillé dans l'entreprise pendant quelques années et j'ai estimé que la culture adoptée dans notre pays n'était pas très efficace. Nous avons essayé de lancer le produit deux fois, trois fois et deux fois avant mon arrivée, ce qui a entraîné de grosses dépenses de retouches, au cours desquelles nous n'avions rien à montrer, sauf pour les longues nuits, les délais courts et les produits de typographie. Et même si je travaillais dur, j'étais sceptique quant au dernier délai qui nous avait été attribué par la direction. Et il a maudit nonchalamment en discutant avec mes collègues de certains aspects du code.

Il n'y avait donc rien de surprenant dans le fait - bien que j'étais surpris - que quelques semaines plus tard, le même nouveau développeur ait parlé de la même manière négative que moi (y compris en jurant). J'ai réalisé qu'il aurait agi différemment dans une entreprise différente avec une culture différente. Il s'est seulement adapté à la culture que j'ai créée. La culpabilité m'a submergé. En raison de mon expérience subjective, j'ai inculqué du pessimisme au novice, que je percevais comme complètement différent. Même s'il n'était vraiment pas comme ça et essayait juste de montrer qu'il pouvait rejoindre l'équipe, je lui ai imposé mon attitude de merde. Et tout ce qui a été dit, même en plaisantant ou en passant, a une mauvaise manière de transformer ce en quoi on croit.

Façons de négativité

Revenons à nos anciens programmeurs novices qui ont acquis un peu de sagesse et d'expérience: ils ont appris à mieux connaître l'industrie de la programmation et à comprendre qu'un mauvais code est partout, il ne peut pas être évité. On le retrouve même dans les entreprises les plus avancées axées sur la qualité (et laissez-moi noter: il semble que la modernité ne nous sauve pas du tout du mauvais code).

Bon script. Au fil du temps, les développeurs commencent à accepter le fait que le mauvais code est la réalité du logiciel et que leur travail consiste à l'améliorer. Et si un mauvais code ne peut être évité, il n'y a aucun intérêt à faire du bruit à cause de cela. Ils se lancent sur le chemin du Zen, se concentrent sur la résolution des problèmes ou des tâches qui les confrontent. Ils apprennent à mesurer avec précision et à fournir la qualité des logiciels aux propriétaires d'entreprise, sur la base de leurs nombreuses années d'expérience, à rédiger des estimations parfaitement justifiées et, en fin de compte, à recevoir de généreuses récompenses pour leur valeur incroyable et immuable pour l'entreprise. Ils font si bien leur travail qu'ils reçoivent des bonus de 10 millions de dollars, et ils prennent leur retraite pour faire ce qu'ils veulent pour le reste de leur vie (s'il vous plaît, ne le croyez pas).



Un autre scénario est le chemin de l'obscurité. Au lieu d'accepter le mauvais code comme inévitable, les développeurs se chargent d'annoncer tous les mauvais dans le monde de la programmation afin de pouvoir le vaincre. Ils refusent d'améliorer le mauvais code existant pour de nombreuses bonnes raisons: «les gens devraient en savoir plus et ne pas être aussi stupides»; "C'est désagréable"; «C'est mauvais pour les affaires»; «Cela prouve à quel point je suis intelligent»; "Si je ne vous dis pas ce qu'est un code pourri, c'est toute l'entreprise qui plongera dans l'océan", et ainsi de suite.

N'ayant sûrement pas la possibilité de mettre en œuvre les changements souhaités, car malheureusement, les entreprises doivent continuer à se développer et ne peuvent pas passer du temps à se soucier de la qualité du code, ces personnes se font une réputation de plaignants. Ils sont détenus pour des compétences élevées, mais sont chassés dans l'arrière-cour de l'entreprise, où ils ne dérangeront pas beaucoup, mais en même temps, ils soutiendront le fonctionnement des systèmes critiques. Ayant perdu l'accès à de nouvelles opportunités de développement, ils perdent leurs compétences et cessent de répondre aux exigences de l'industrie. Leur négativité se transforme en une amertume féroce, et en conséquence, ils amusent leur ego, discutant avec des étudiants de vingt ans sur le chemin que leur ancienne technologie bien-aimée a suivi et pourquoi il est toujours net. En fin de compte, ils se retirent et vivent la vieillesse, maudissant les oiseaux.

Probablement, la réalité se situe quelque part entre ces deux extrêmes.

Certaines entreprises ont extrêmement bien réussi à créer des cultures extrêmement négatives, isolées et à forte volonté (comme Microsoft avant sa décennie perdue ) - il s'agit souvent de sociétés dont les produits correspondent parfaitement au marché et qui ont besoin de croître le plus rapidement possible; ou des entreprises avec une hiérarchie de gestion et de contrôle (Apple dans les meilleures années de Jobs), où chacun fait ce qu'il commande. Cependant, la recherche commerciale moderne (et le bon sens) suggèrent que pour une ingéniosité maximale, conduisant à l'innovation de l'entreprise et à une productivité élevée des individus, un faible niveau de stress est nécessaire pour maintenir une pensée créative et méthodique continue. Et il est extrêmement difficile de faire un travail créatif, qui est basé sur des discussions si vous êtes constamment inquiet de ce que vos collègues auront à dire sur chaque ligne de votre code.

Négatif est l'ingénierie de la culture pop

Aujourd'hui, plus d'attention que jamais est accordée à l'attitude des ingénieurs. Dans les organisations d'ingénierie, la règle « No Ovuk » devient de plus en plus populaire. Sur Twitter, il y a de plus en plus de blagues et d'histoires sur des personnes qui ont quitté cette profession parce qu'elles ne pouvaient pas (ne voulaient pas) continuer à supporter l'hostilité et l'hostilité envers les étrangers. Même Linus Torvalds s'est récemment excusé au cours des années de son hostilité et de ses critiques envers d'autres développeurs Linux - cela a conduit à une discussion sur l'efficacité de cette approche.

Quelqu'un défend toujours le droit de Linus d'être très critique - ceux qui ont besoin d'en savoir beaucoup sur les avantages et les inconvénients de la «négativité toxique». Oui, l'exactitude est extrêmement importante (même fondamentale), mais si nous résumons les raisons pour lesquelles beaucoup d'entre nous permettent à l'expression d'opinions négatives de se transformer en «toxicité», alors ces raisons semblent paternalistes ou adolescentes: «elles le méritent parce qu'elles sont idiotes», «il Je dois être sûr qu'ils ne le répéteront pas, "" s'ils ne l'avaient pas fait, il n'aurait pas à leur crier dessus ", et ainsi de suite. Un exemple de la façon dont les réactions émotionnelles du leader affectent la communauté de programmation est l'abréviation MINASWAN dans la communauté Ruby - «Matz est sympa donc nous sommes gentils» (Matz [créateur de la langue] est bon, donc nous sommes bons).

J'ai remarqué que de nombreux ardents partisans de l'approche «tuer les imbéciles» prennent souvent grand soin de la qualité et de l'exactitude du code, s'identifiant à leur travail. Malheureusement, ils confondent souvent dureté et rigidité. L'inconvénient de cette position provient d'un simple désir humain, mais improductif, de se sentir supérieur aux autres. Les gens qui sont plongés dans ce désir sont coincés dans le chemin des ténèbres.



Le monde de la programmation se développe rapidement et dépasse les frontières de son conteneur - le monde de la non-programmation (ou est-ce le monde de la programmation un conteneur pour le monde de la non-programmation? Bonne question).

À mesure que notre industrie se développe à un rythme croissant et que la programmation devient plus accessible, la distance entre les «technophiles» et les «normaux» diminue rapidement. Le monde de la programmation est de plus en plus exposé à la communication interpersonnelle entre des gens qui ont grandi dans une culture isolée de «nerds» du début du boom technologique, et ce sont eux qui formeront le nouveau monde de la programmation. Et indépendamment de tout argument concernant la sphère sociale ou les générations, l'efficacité au nom du capitalisme se manifestera dans la culture des entreprises et les approches de l'embauche: les meilleures entreprises n'embaucheront tout simplement pas celles qui ne peuvent pas interagir avec les autres de manière neutre, sans parler de bonnes relations.

Ce que j'ai appris sur le négatif

Si vous autorisez un excès de négativité à contrôler votre esprit et votre communication avec les gens, ce qui se transforme en «toxicité», cela est dangereux pour les équipes de produits et coûteux pour les entreprises. J'ai vu une myriade de projets (et j'en ai entendu parler) qui se sont effondrés et ont été complètement refaits à un coût élevé, car l'un des développeurs de confiance a affûté la technologie, un autre développeur, ou même le seul fichier sélectionné pour représenter la qualité de la base de code entière .

La négativité démorale et détruit également les relations. Je n'oublierai jamais comment un collègue m'a réprimandé pour avoir mis CSS dans le mauvais fichier, cela m'a bouleversé et m'a empêché de rassembler mes pensées pendant plusieurs jours. Et à l'avenir, il est peu probable que je permette à une telle personne d'être proche de l'une de mes équipes (cependant, qui sait, les gens changent).

Enfin, la négativité nuit littéralement à votre santé .


Il me semble qu'une master class sur le sourire devrait ressembler à ça.

Bien sûr, ce n'est pas un argument en faveur du bonheur, de l'insertion de dix milliards de smileys dans chaque demande de tirage ou d'aller à une classe de maître avec des sourires (non, eh bien, si c'est ce que vous voulez, alors pas de question). La négativité est une partie extrêmement importante de la programmation (et de la vie humaine), signalant la qualité, vous permettant d'exprimer des sentiments et des condoléances aux gens-frères. Preuve négative de la perspicacité et du caractère raisonnable, de la profondeur du problème. Je remarque souvent qu'un développeur a atteint un nouveau niveau lorsqu'il commence à exprimer sa méfiance envers ce qu'il était timide et incertain. Avec leurs opinions, les gens font preuve de prudence et de confiance. On ne peut pas rejeter l'expression de la négativité, ce serait dans le style orwellien.

Cependant, le négatif doit être dosé et équilibré avec d'autres qualités humaines importantes: l'empathie, la patience, la compréhension et l'humour. Vous pouvez toujours dire à une personne qu'elle a foiré sans crier et maudire. Ne sous-estimez pas cette approche: si vous êtes complètement sans émotion, ils disent que vous avez sérieusement gâché, cela fait vraiment peur.

Il y a plusieurs années, le PDG m'a parlé. Nous avons discuté de la situation actuelle du projet, puis il m'a demandé comment je me sentais. J'ai répondu que tout allait bien, le projet avançait, nous travaillions lentement, j'avais peut-être manqué quelque chose et devais être revu. Il a dit qu'il m'avait entendu partager des considérations plus pessimistes avec des collègues du bureau, et que d'autres l'avaient également remarqué. Il a expliqué que si j'ai des doutes, je peux les exprimer pleinement aux dirigeants, mais pas pour les "baisser". En tant qu'ingénieur principal, je dois me souvenir de la façon dont mes paroles affectent les autres, car j'ai une grande influence, même si je ne m'en rends pas compte. Et tout cela, il m'a dit très gentiment, et a finalement dit que si je ressens vraiment de tels sentiments, alors j'ai probablement besoin de penser à ce que je veux pour moi et ma carrière. Ce fut une conversation incroyablement douce dans le style de «vous ressaisir ou de sortir». Je l'ai remercié pour les informations sur la façon dont mon attitude, qui a changé au cours des six derniers mois, affecte imperceptiblement les autres pour moi.

C'était un exemple de gestion merveilleuse et efficace et la puissance d'une approche douce. J'ai réalisé qu'il me semblait seulement que je croyais totalement en l'entreprise et en sa capacité à atteindre ses objectifs, mais en réalité j'ai parlé et communiqué avec les autres d'une manière complètement différente. J'ai également réalisé que même en étant sceptique à l'égard du projet sur lequel je travaillais, je n'aurais pas dû montrer mon attitude envers mes collègues et répandre le pessimisme comme une infection, réduisant ainsi nos chances de succès. Au lieu de cela, j'ai pu diffuser agressivement la situation réelle à ma direction. Et si je sentais qu'ils ne m'écoutaient pas, je pouvais exprimer mon désaccord avec le départ de l'entreprise.

J'ai eu une nouvelle opportunité en occupant le poste de responsable de l'évaluation du personnel. En tant qu'ancien ingénieur en chef, je surveille attentivement mon opinion sur notre code hérité (en constante amélioration). Pour approuver le changement, vous devez imaginer la situation actuelle, mais vous n’arriverez à rien si vous vous enlisez dans les gémissements, les attaques ou quelque chose du genre. , , , , , .

, , , , . (« »), . , , (?) (« , , »). , .

, : , .