Je regarde un morceau de code. C'est peut-être le pire code que j'ai jamais vu. Pour mettre à jour un seul enregistrement de la base de données, il récupère tous les enregistrements de la collection, puis envoie une demande de mise à jour à chaque enregistrement de la base de données, même à ceux qui n'ont pas besoin d'être mis à jour. Il existe une fonction map qui renvoie simplement la valeur qui lui est transmise. Il existe des tests conditionnels pour les variables ayant apparemment la même valeur, simplement nommées dans des styles différents (firstName и first_name). Pour chaque MISE À JOUR, le code envoie un message à une file d'attente différente, qui est gérée par une fonction sans serveur différente, mais qui fait tout le travail pour une collection différente dans la même base de données. Ai-je 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 était-il possible de faire cela ? Je me couvre le visage et sanglote visiblement à travers mon rire. Mes collègues demandent ce qui s'est passé, et je le raconte en couleurs Pires succès de BulkDataImporter.js 2018. Tout le monde me fait un signe de tête sympathique et est d'accord : comment ont-ils pu nous faire ça ?
Négativité : un outil émotionnel dans une culture de programmeur
La négativité joue un rôle important dans la programmation. Il est ancré dans notre culture et est utilisé pour partager ce que nous avons appris (« on ne sait pas tu le croiras, à quoi ressemblait ce code ! »), pour exprimer sa sympathie à travers la frustration (« Dieu, POURQUOI faire ça ? »), pour se montrer (« Je ne ferais jamais si ne l'avons pas fait »), rejeter la faute sur quelqu'un d'autre (« nous avons échoué à cause de son code, qui est impossible à maintenir »), ou, comme c'est l'habitude dans les organisations les plus « toxiques », de gérer les autres avec un sentiment de honte (« À quoi pensais-tu ? » ? correct »).
La négativité est si importante pour les programmeurs car c'est un moyen très efficace de transmettre de la valeur. Une fois, j'ai participé à un camp de programmation, et la pratique standard pour inculquer une culture industrielle aux étudiants consistait à fournir généreusement des mèmes, des histoires et des vidéos, dont les plus populaires exploitaient . C'est bien de pouvoir utiliser des outils émotionnels pour identifier le Bon, la Brute, le Truand, Ne fais pas ça, Jamais du tout. Il est nécessaire de préparer les nouveaux arrivants au fait qu'ils seront probablement mal compris par des collègues éloignés de l'informatique. Que leurs amis commenceront à leur vendre des idées d'applications valant des millions de dollars. Qu'ils devront errer dans des labyrinthes sans fin de code obsolète avec une bande de minotaures au coin de la rue.
Lorsque nous apprenons à programmer pour la première fois, notre compréhension de la profondeur de « l'expérience de programmation » est basée sur l'observation des réactions émotionnelles des autres. Cela ressort clairement des messages publiés dans , où se retrouvent de nombreux programmeurs débutants. De nombreux humoristiques sont, à un degré ou à un autre, colorés de différentes nuances de négativité : déception, pessimisme, indignation, condescendance et autres. Et si cela ne vous semble pas suffisant, lisez les commentaires.
J'ai remarqué qu'à mesure que les programmeurs acquièrent de l'expérience, ils deviennent de plus en plus négatifs. Les débutants, ignorant les difficultés qui les attendent, commencent avec enthousiasme et avec la volonté de croire que la cause de ces difficultés est simplement un manque d'expérience et de connaissances ; et finalement ils seront confrontés à la réalité des choses.
Le temps passe, ils acquièrent de l’expérience et deviennent capables de distinguer le Bon code du Mauvais. Et lorsque ce moment arrive, les jeunes programmeurs ressentent la frustration de travailler avec un code manifestement mauvais. Et s’ils travaillent en équipe (à distance ou en présentiel), ils adoptent souvent les habitudes émotionnelles de collègues plus expérimentés. Cela conduit souvent à une augmentation de la négativité, car les jeunes peuvent désormais parler de manière réfléchie du code et le diviser en mauvais et en bon, montrant ainsi qu’ils sont « au courant ». Cela renforce encore le négatif : à partir d’une déception, il est facile de s’entendre avec des collègues et de faire partie d’un groupe ; critiquer Bad Code augmente son statut et son professionnalisme aux yeux des autres : .
Augmenter la négativité n’est pas nécessairement une mauvaise chose. Les discussions sur la programmation, entre autres, sont extrêmement axées sur la qualité du code écrit. Ce qu'est le code définit complètement la fonction qu'il est censé remplir (matériel, réseau, etc. mis à part), il est donc important de pouvoir exprimer votre opinion sur ce code. Presque toutes les discussions se résument à savoir si le code est suffisamment bon et à condamner les manifestations mêmes d'un mauvais code dans des termes dont la connotation émotionnelle caractérise la qualité du code :
- "Il y a beaucoup d'incohérences logiques dans ce module, c'est un bon candidat pour une optimisation significative des performances."
- "Ce module est plutôt mauvais, nous devons le refactoriser."
- "Ce module n'a pas de sens, il faut le réécrire."
- "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, qu'est-ce que pensait son auteur."
D'ailleurs, c'est cette "version émotionnelle" qui fait que les développeurs qualifient le code de "sexy", ce qui est rarement juste - à moins que vous ne travailliez chez PornHub.
Le problème est que les gens sont des créatures étranges, agitées et émotionnelles, et la perception et l'expression de toute émotion nous changent : d'abord subtilement, mais au fil du temps, de façon spectaculaire.
Une pente glissante troublée de négativité
Il y a quelques années, j'étais chef d'équipe informel et j'ai interviewé un développeur. Nous l’aimions vraiment : il était intelligent, posait de bonnes questions, connaissait bien la technologie et s’intégrait bien à notre culture. J'ai été particulièrement impressionné par sa positivité et son esprit d'entreprise. Et je l'ai embauché.
À cette époque, je travaillais dans l’entreprise depuis quelques années et je sentais que notre culture n’était pas très efficace. Nous avons essayé de lancer le produit deux, trois fois et encore quelques fois avant mon arrivée, ce qui a entraîné de grosses dépenses de retouche, pendant lesquelles nous n'avions rien à montrer à part de longues nuits, des délais serrés et des produits qui fonctionnaient. Et même si je travaillais encore dur, j'étais sceptique quant au dernier délai que nous avait fixé la direction. Et il a juré avec désinvolture en discutant de certains aspects du code avec mes collègues.
Il n'était donc pas surprenant (même si j'ai été surpris) que quelques semaines plus tard, ce même nouveau développeur ait dit les mêmes choses négatives que moi (y compris des jurons). J'ai réalisé qu'il se comporterait différemment dans une entreprise différente avec une culture différente. Il s'est simplement adapté à la culture que j'ai créée. J'ai été submergé par un sentiment de culpabilité. En raison de mon expérience subjective, j’ai insufflé le pessimisme à un nouveau venu que je percevais comme complètement différent. Même s'il n'était vraiment pas comme ça et qu'il faisait juste semblant de montrer qu'il pouvait s'intégrer, je lui ai imposé mon attitude de merde. Et tout ce qui est dit, même en plaisantant ou en passant, a la mauvaise manière de se transformer en ce qu'on croit.
Manières négatives
Revenons à nos anciens programmeurs débutants, qui ont acquis un peu de sagesse et d'expérience : ils se sont familiarisés avec l'industrie de la programmation et comprennent que le mauvais code est partout, il ne peut être évité. Cela se produit même dans les entreprises les plus avancées et axées sur la qualité (et je le précise : apparemment, la modernité ne protège pas contre le mauvais code).
Bon scénario. Au fil du temps, les développeurs commencent à accepter que le mauvais code est une réalité des logiciels et que leur travail consiste à l'améliorer. Et que si un mauvais code ne peut être évité, cela ne sert à rien d’en faire toute une histoire. Ils empruntent le chemin du Zen, en se concentrant sur la résolution des problèmes ou des tâches auxquels ils sont confrontés. Ils apprennent à mesurer avec précision et à communiquer la qualité des logiciels aux propriétaires d'entreprise, à rédiger des estimations bien fondées basées sur leurs années d'expérience et, en fin de compte, à recevoir de généreuses récompenses pour leur valeur incroyable et continue pour l'entreprise. Ils font si bien leur travail qu'ils reçoivent 10 millions de dollars de primes et prennent leur retraite pour faire ce qu'ils veulent pour le reste de leur vie (s'il vous plaît, ne le prenez pas pour acquis).
Un autre scénario est le chemin des ténèbres. Au lieu d’accepter le mauvais code comme une fatalité, les développeurs prennent sur eux de dénoncer tout ce qui est mauvais dans le monde de la programmation afin de pouvoir les surmonter. 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 à quel point ce code est nul, toute l'entreprise tombera dans l'océan", et ainsi de suite.
Sûrement incapables de mettre en œuvre les changements qu'ils souhaitent car l'entreprise doit malheureusement continuer à se développer et ne peut pas passer du temps à se soucier de la qualité du code, ces personnes acquièrent une réputation de râleur. Ils sont retenus pour leur haute compétence, mais sont poussés aux marges de l'entreprise, où ils ne gêneront pas grand monde, mais soutiendront néanmoins le fonctionnement des systèmes critiques. Sans accès à de nouvelles opportunités de développement, ils perdent des compétences et cessent de répondre aux demandes de l’industrie. Leur négativité se transforme en amertume amère et, par conséquent, ils nourrissent leur ego en discutant avec des étudiants de vingt ans sur le chemin parcouru par leur ancienne technologie préférée et pourquoi elle est toujours aussi chaude. Ils finissent par prendre leur retraite et vivre leur vieillesse en injuriant les oiseaux.
La réalité se situe probablement quelque part entre ces deux extrêmes.
Certaines entreprises ont extrêmement bien réussi à créer des cultures extrêmement négatives, insulaires et volontaires (comme Microsoft avant son lancement). ) - il s'agit souvent d'entreprises dont les produits sont parfaitement adaptés au marché et à la nécessité de se développer le plus rapidement possible ; ou des entreprises avec une hiérarchie de commandement et de contrôle (Apple dans les meilleures années de l'emploi), où chacun fait ce qu'on lui dit. Cependant, la recherche commerciale moderne (et le bon sens) suggère qu’une ingéniosité maximale, qui conduit à l’innovation dans les entreprises et à une productivité élevée chez les individus, nécessite de faibles niveaux de stress pour soutenir une réflexion créative et méthodique continue. Et il est extrêmement difficile de réaliser un travail créatif basé sur la discussion si vous vous inquiétez constamment de ce que vos collègues auront à dire sur chaque ligne de votre code.
La négativité est une ingénierie de la culture pop
Aujourd’hui, on accorde plus d’attention que jamais à l’attitude des ingénieurs. Dans les organismes d'ingénierie, la règle «". De plus en plus d'anecdotes et d'histoires apparaissent sur Twitter concernant des personnes qui ont quitté cette profession parce qu'elles ne pouvaient pas (ne voulaient pas) continuer à supporter l'hostilité et la mauvaise volonté envers les étrangers. Même Linus Torvalds des années d'hostilité et de critiques envers les autres développeurs Linux - cela a conduit à un débat sur l'efficacité de cette approche.
Certains défendent encore le droit de Linus d'être très critique - ceux qui devraient en savoir beaucoup sur les avantages et les inconvénients de la « négativité toxique ». Oui, la civilité est extrêmement importante (voire fondamentale), mais si l'on résume les raisons pour lesquelles beaucoup d'entre nous laissent l'expression d'opinions négatives se transformer en « toxicité », ces raisons semblent paternalistes ou adolescentes : « ils le méritent parce qu'ils sont idiots ». », « il doit être sûr qu’ils ne recommenceront pas », « s’ils n’avaient pas fait ça, il n’aurait pas à leur crier dessus », et ainsi de suite. Un exemple de l'impact des réactions émotionnelles d'un leader sur une communauté de programmation est l'acronyme de la communauté Ruby MINASWAN - "Matz est gentil donc nous sommes gentils".
J'ai remarqué que de nombreux ardents partisans de l'approche « tuer un imbécile » se soucient souvent beaucoup 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 vient du simple désir humain, mais improductif, de se sentir supérieur aux autres. Les personnes qui s’immergent dans ce désir se retrouvent coincées sur le chemin des ténèbres.
Le monde de la programmation se développe rapidement et repousse les limites de son conteneur - le monde de la non-programmation (ou le monde de la programmation est-il un conteneur pour le monde de la non-programmation ? Bonne question).
À mesure que notre industrie se développe à un rythme toujours plus rapide et que la programmation devient plus accessible, la distance entre les « techniciens » et les « normaux » se réduit rapidement. Le monde de la programmation est de plus en plus exposé aux interactions interpersonnelles de personnes qui ont grandi dans la culture des nerds isolés du début du boom technologique, et ce sont eux qui façonneront le nouveau monde de la programmation. Et quels que soient les arguments sociaux ou générationnels, l’efficacité au nom du capitalisme se manifestera dans la culture d’entreprise et les pratiques de recrutement : les meilleures entreprises n’embaucheront tout simplement pas quelqu’un qui ne peut pas interagir de manière neutre avec les autres, et encore moins entretenir de bonnes relations.
Ce que j'ai appris sur la négativité
Si vous permettez à trop de négativité de contrôler votre esprit et vos interactions avec les gens, se transformant en toxicité, alors cela est dangereux pour les équipes produit et coûteux pour les entreprises. J'ai vu (et entendu parler) d'innombrables projets qui se sont effondrés et ont été complètement reconstruits à grands frais parce qu'un développeur de confiance avait une rancune contre la technologie, un autre développeur ou même un seul fichier choisi pour représenter la qualité de l'ensemble de la base de code.
La négativité démoralise et détruit également les relations. Je n'oublierai jamais comment un collègue m'a grondé pour avoir mis CSS dans le mauvais fichier, cela m'a bouleversé et ne m'a pas permis de rassembler mes pensées pendant plusieurs jours. Et à l’avenir, il est peu probable que je permette à une telle personne d’être à proximité d’une de mes équipes (mais qui sait, les gens changent).
Enfin, le négatif .
Je pense que c'est à cela que devrait ressembler une master class sur les sourires.
Bien sûr, ce n’est pas un argument pour rayonner de bonheur, insérer dix milliards d’émoticônes dans chaque pull request, ou assister à une master class sur le sourire (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é, permettant d'exprimer des sentiments et de compatir avec les autres humains. La négativité indique la perspicacité et la prudence, la profondeur du problème. Je remarque souvent qu'un développeur a atteint un nouveau niveau lorsqu'il commence à exprimer son incrédulité face à ce dont il était auparavant timide et incertain. Les gens font preuve de caractère raisonnable et de confiance dans leurs opinions. Vous ne pouvez pas écarter l’expression de négativité, ce serait orwellien.
Cependant, la négativité doit être dosée et équilibrée 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 fait une erreur sans crier ni jurer. Ne sous-estimez pas cette approche : si quelqu’un vous dit sans aucune émotion que vous avez sérieusement raté, cela fait vraiment peur.
Cette fois-là, il y a plusieurs années, le PDG m'a parlé. Nous avons discuté de l'état actuel du projet, puis il m'a demandé comment je me sentais. J'ai répondu que tout allait bien, que le projet avançait, que nous travaillions lentement, que j'avais peut-être raté quelque chose et que j'avais besoin d'être reconsidéré. Il a dit qu'il m'avait entendu partager des pensées plus pessimistes avec des collègues du bureau et que d'autres l'avaient également remarqué. Il m'a expliqué que si j'avais des doutes, je pouvais les exprimer pleinement à la direction, mais pas les « éliminer ». En tant qu'ingénieur en chef, je dois être conscient de la façon dont mes paroles affectent les autres car j'ai beaucoup d'influence même si je ne m'en rends pas compte. Et il m'a raconté tout cela très gentiment et a finalement dit que si je ressentais vraiment cela, alors je devrais probablement réfléchir à ce que je veux pour moi et pour ma carrière. C'était une conversation incroyablement douce, à faire ou à sortir de votre siège. Je l'ai remercié pour l'information sur la façon dont mon changement d'attitude au cours des six mois affectait les autres sans que je m'en aperçoive.
C’était un exemple de gestion remarquable et efficace et de la puissance d’une approche douce. J'ai réalisé que je semblais avoir une confiance totale dans l'entreprise et dans sa capacité à atteindre ses objectifs, mais en réalité, je parlais et communiquais avec les autres d'une manière complètement différente. J'ai également réalisé que même si j'étais sceptique quant au projet sur lequel je travaillais, je ne devais pas montrer mes sentiments à mes collègues et répandre le pessimisme comme une contagion, réduisant ainsi nos chances de succès. Au lieu de cela, je pourrais transmettre de manière agressive la situation réelle à ma direction. Et si je sentais qu’ils ne m’écoutaient pas, je pouvais exprimer mon désaccord en quittant l’entreprise.
J'ai reçu une nouvelle opportunité lorsque j'ai accepté le poste de responsable de l'évaluation du personnel. En tant qu'ancien ingénieur en chef, je fais très attention à exprimer mes opinions sur notre code existant (en constante amélioration). Pour approuver un changement, vous devez imaginer la situation actuelle, mais vous n’arriverez à rien si vous vous vautrez dans les gémissements, les attaques, etc. En fin de compte, je suis ici pour accomplir une tâche et je ne devrais pas me plaindre du code pour le comprendre, l'évaluer ou le corriger.
En fait, plus je contrôle ma réaction émotionnelle face au code, plus je comprends ce qu’il pourrait devenir et moins je ressens de confusion. Lorsque je m’exprimais avec retenue (« il doit y avoir encore place à l’amélioration ici »), je faisais plaisir à moi-même et aux autres et je ne prenais pas la situation trop au sérieux. J'ai réalisé que je pouvais stimuler et réduire la négativité chez les autres en étant parfaitement (ennuyeux ?) raisonnable (« tu as raison, ce code est plutôt mauvais, mais nous allons l'améliorer »). Je suis heureux de voir jusqu'où je peux aller sur le chemin du Zen.
Essentiellement, j’apprends et réapprends constamment une leçon importante : la vie est trop courte pour être constamment en colère et souffrir.
Source: habr.com