Wut auf Code: Programmierer und Negativität

Ich schaue mir einen Code an. Dies ist möglicherweise der schlechteste Code, den ich je gesehen habe. Um nur einen Datensatz in der Datenbank zu aktualisieren, ruft es alle Datensätze in der Sammlung ab und sendet dann eine Aktualisierungsanforderung an jeden Datensatz in der Datenbank, auch an diejenigen, die nicht aktualisiert werden müssen. Es gibt eine Map-Funktion, die einfach den ihr übergebenen Wert zurückgibt. Es gibt bedingte Tests für Variablen mit scheinbar demselben Wert, die nur in unterschiedlichen Stilen benannt sind (firstName и first_name). Bei jedem UPDATE sendet der Code eine Nachricht an eine andere Warteschlange, die von einer anderen serverlosen Funktion verarbeitet wird, die jedoch die gesamte Arbeit für eine andere Sammlung in derselben Datenbank erledigt. Habe ich erwähnt, dass diese serverlose Funktion aus einer cloudbasierten „serviceorientierten Architektur“ stammt, die über 100 Funktionen in der Umgebung enthält?

Wie war das überhaupt möglich? Ich bedecke mein Gesicht und schluchze sichtbar vor Lachen. Meine Kollegen fragen, was passiert ist, und ich erzähle es in Farben nach Schlimmste Treffer von BulkDataImporter.js 2018. Alle nicken mir mitfühlend zu und sind sich einig: Wie konnten sie uns das antun?

Negativität: ein emotionales Werkzeug in einer Programmiererkultur

Negativität spielt beim Programmieren eine wichtige Rolle. Es ist in unserer Kultur verankert und dient dazu, das Gelernte weiterzugeben („Das tun Sie nicht.“ Du wirst es glauben, wie war das denn für ein Code!“), Mitgefühl durch Frustration auszudrücken („Gott, WARUM das tun?“), sich selbst zur Schau zu stellen („Das würde ich nie tun“) so nicht getan haben“), die Schuld auf jemand anderen zu schieben („wir haben an seinem Code versagt, der unmöglich aufrechtzuerhalten ist“) oder, wie es in den „giftigsten“ Organisationen üblich ist, andere durch ein Gefühl der Selbstverwaltung zu führen Scham („Woran hast du überhaupt gedacht?“ ? richtig“).

Negativität ist für Programmierer so wichtig, weil sie eine sehr effektive Möglichkeit ist, Werte zu vermitteln. Ich habe einmal an einem Programmiercamp teilgenommen, und die übliche Praxis, Studenten eine Industriekultur zu vermitteln, bestand darin, großzügig Memes, Geschichten und Videos bereitzustellen, von denen die beliebtesten ausgenutzt wurden die Frustration der Programmierer, wenn sie mit Missverständnissen der Menschen konfrontiert werden. Es ist gut, emotionale Werkzeuge nutzen zu können, um das Gute, das Schlechte, das Hässliche zu identifizieren. Tun Sie das nicht, niemals. Man muss Neulinge darauf vorbereiten, dass sie von IT-fernen Kollegen wahrscheinlich missverstanden werden. Dass ihre Freunde anfangen, ihnen millionenschwere App-Ideen zu verkaufen. Dass sie mit einem Haufen Minotauren um die Ecke durch endlose Labyrinthe veralteten Codes wandern müssen.

Wenn wir zum ersten Mal das Programmieren lernen, basiert unser Verständnis der Tiefe des „Programmiererlebnisses“ auf der Beobachtung der emotionalen Reaktionen anderer Menschen. Das geht deutlich aus den Beiträgen hervor sabe ProgrammiererHumor, wo sich viele neue Programmierer aufhalten. Viele humorvolle Werke sind bis zu einem gewissen Grad von unterschiedlichen Negativitätsnuancen geprägt: Enttäuschung, Pessimismus, Empörung, Herablassung und andere. Und wenn Ihnen das nicht genug erscheint, lesen Sie die Kommentare.

Mir ist aufgefallen, dass Programmierer mit zunehmender Erfahrung immer negativer werden. Anfänger, die sich der Schwierigkeiten, die sie erwarten, nicht bewusst sind, beginnen mit Begeisterung und der Bereitschaft zu glauben, dass die Ursache dieser Schwierigkeiten einfach ein Mangel an Erfahrung und Wissen ist; und irgendwann werden sie mit der Realität der Dinge konfrontiert.

Die Zeit vergeht, sie sammeln Erfahrung und werden in der Lage, guten Code von schlechtem zu unterscheiden. Und wenn dieser Moment kommt, spüren junge Programmierer die Frustration, mit offensichtlich schlechtem Code zu arbeiten. Und wenn sie im Team arbeiten (remote oder persönlich), übernehmen sie häufig die emotionalen Gewohnheiten erfahrenerer Kollegen. Dies führt häufig zu einer Zunahme der Negativität, da junge Menschen jetzt nachdenklich über Code sprechen und ihn in schlecht und gut einteilen können, wodurch sie zeigen, dass sie „auf dem Laufenden“ sind. Dies verstärkt das Negative noch weiter: Aus Enttäuschung kommt man leicht mit Kollegen aus und wird Teil einer Gruppe; die Kritik an Bad Code steigert Ihren Status und Ihre Professionalität in den Augen anderer: Menschen, die negative Meinungen äußern, werden oft als intelligenter und kompetenter wahrgenommen.

Zunehmende Negativität ist nicht unbedingt eine schlechte Sache. Diskussionen über Programmierung konzentrieren sich unter anderem stark auf die Qualität des geschriebenen Codes. Was der Code ist, definiert vollständig die Funktion, die er erfüllen soll (Hardware, Netzwerk usw. abgesehen), daher ist es wichtig, dass Sie Ihre Meinung zu diesem Code äußern können. Bei fast allen Diskussionen geht es darum, ob der Code gut genug ist, und um die Verurteilung der eigentlichen Erscheinungsformen von schlechtem Code mit Begriffen, deren emotionale Konnotation die Qualität des Codes charakterisiert:

• „In diesem Modul gibt es viele logische Inkonsistenzen, es ist ein guter Kandidat für eine deutliche Leistungsoptimierung.“
• „Dieses Modul ist ziemlich schlecht, wir müssen es umgestalten.“
• „Dieses Modul macht keinen Sinn, es muss neu geschrieben werden.“
• „Dieses Modul ist scheiße, es muss gepatcht werden.“
• „Das ist ein Stück RAM, kein Modul, es musste überhaupt nicht geschrieben werden, was zum Teufel hat sich sein Autor gedacht?“

Übrigens ist es diese „emotionale Veröffentlichung“, die Entwickler dazu bringt, den Code „sexy“ zu nennen, was selten fair ist – es sei denn, man arbeitet bei PornHub.

Das Problem ist, dass Menschen seltsame, ruhelose, emotionale Wesen sind und die Wahrnehmung und der Ausdruck jeglicher Emotionen uns verändert: zunächst subtil, aber mit der Zeit dramatisch.

Ein unruhiger, schlüpfriger Abhang der Negativität

Vor ein paar Jahren war ich informeller Teamleiter und habe einen Entwickler interviewt. Wir mochten ihn wirklich: Er war klug, stellte gute Fragen, war technisch versiert und passte gut zu unserer Kultur. Besonders beeindruckt hat mich seine positive Einstellung und sein Unternehmungsgeist. Und ich habe ihn eingestellt.

Zu diesem Zeitpunkt arbeitete ich bereits seit einigen Jahren im Unternehmen und hatte das Gefühl, dass unsere Kultur nicht sehr effektiv war. Wir haben vor meiner Ankunft zweimal, dreimal und noch ein paar Mal versucht, das Produkt auf den Markt zu bringen, was zu hohen Kosten für Nacharbeiten führte, bei denen wir außer langen Nächten, engen Fristen und Produkten, die funktionierten, nichts vorzuweisen hatten. Und obwohl ich immer noch hart arbeitete, war ich skeptisch gegenüber der letzten Frist, die uns das Management gesetzt hatte. Und er fluchte beiläufig, als er mit meinen Kollegen einige Aspekte des Codes besprach.

Daher war es nicht verwunderlich – obwohl ich überrascht war –, dass derselbe neue Entwickler ein paar Wochen später die gleichen negativen Dinge sagte wie ich (einschließlich Fluchen). Mir wurde klar, dass er sich in einem anderen Unternehmen mit einer anderen Kultur anders verhalten würde. Er hat sich einfach an die Kultur angepasst, die ich geschaffen habe. Mich überkam ein Schuldgefühl. Aufgrund meiner subjektiven Erfahrung löste ich bei einem Neuankömmling, den ich als völlig anders wahrnahm, Pessimismus aus. Auch wenn er wirklich nicht so war und nur so tat, als würde er zeigen, dass er dazupasste, habe ich ihm meine beschissene Einstellung aufgezwungen. Und alles, was gesagt wird, selbst im Scherz oder beiläufig, hat die schlechte Art, sich in etwas zu verwandeln, was geglaubt wird.

Negative Wege

Kehren wir zu unseren ehemaligen Neuprogrammierern zurück, die ein wenig Weisheit und Erfahrung gesammelt haben: Sie sind mit der Programmierbranche vertrauter geworden und verstehen, dass schlechter Code überall ist und sich nicht vermeiden lässt. Es kommt sogar in den fortschrittlichsten Unternehmen vor, die sich auf Qualität konzentrieren (und lassen Sie mich anmerken: Offensichtlich schützt Modernität nicht vor schlechtem Code).

Gutes Drehbuch. Mit der Zeit beginnen Entwickler zu akzeptieren, dass fehlerhafter Code eine Realität von Software ist und dass es ihre Aufgabe ist, ihn zu verbessern. Und wenn schlechter Code nicht vermieden werden kann, hat es keinen Sinn, darüber Aufsehen zu erregen. Sie gehen den Weg des Zen und konzentrieren sich auf die Lösung von Problemen oder Aufgaben, mit denen sie konfrontiert sind. Sie lernen, die Softwarequalität genau zu messen und den Geschäftsinhabern mitzuteilen, fundierte Kostenvoranschläge auf der Grundlage ihrer jahrelangen Erfahrung zu erstellen und erhalten letztendlich großzügige Belohnungen für ihren unglaublichen und dauerhaften Wert für das Unternehmen. Sie machen ihre Arbeit so gut, dass sie 10 Millionen US-Dollar an Prämien erhalten und sich zurückziehen, um für den Rest ihres Lebens das zu tun, was sie wollen (bitte betrachten Sie das nicht als selbstverständlich).

Ein anderes Szenario ist der Weg der Dunkelheit. Anstatt schlechten Code als unvermeidlich zu akzeptieren, nehmen Entwickler es auf sich, alles Schlechte in der Programmierwelt anzuprangern, damit sie es überwinden können. Sie lehnen es aus vielen guten Gründen ab, bestehenden schlechten Code zu verbessern: „Die Leute sollten mehr wissen und nicht so dumm sein“; „es ist unangenehm“; „Das ist schlecht fürs Geschäft“; „Das beweist, wie schlau ich bin“; „Wenn ich Ihnen nicht sage, was für ein mieser Code das ist, wird das ganze Unternehmen in den Ozean fallen“ und so weiter.

Diese Leute sind sicherlich nicht in der Lage, die gewünschten Änderungen umzusetzen, weil sich das Unternehmen leider weiterentwickeln muss und keine Zeit damit verbringen kann, sich über die Qualität des Codes Gedanken zu machen. Dadurch geraten sie in den Ruf, sich zu beschweren. Sie werden wegen ihrer hohen Kompetenz beibehalten, aber an den Rand des Unternehmens gedrängt, wo sie nicht viele Leute stören, aber dennoch den Betrieb kritischer Systeme unterstützen. Ohne Zugang zu neuen Entwicklungsmöglichkeiten verlieren sie ihre Fähigkeiten und können den Anforderungen der Branche nicht mehr gerecht werden. Ihre Negativität verwandelt sich in bittere Bitterkeit, und als Folge davon nähren sie ihr Ego, indem sie mit zwanzigjährigen Schülern darüber streiten, welche Reise ihre alte Lieblingstechnologie zurückgelegt hat und warum sie immer noch so beliebt ist. Am Ende ziehen sie sich zurück und verbringen ihr Alter damit, Vögel zu beschimpfen.

Die Realität liegt wahrscheinlich irgendwo zwischen diesen beiden Extremen.

Einige Unternehmen waren äußerst erfolgreich bei der Schaffung extrem negativer, abgeschotteter und willensstarker Kulturen (wie zuvor Microsoft). verlorenes Jahrzehnt) – oft handelt es sich dabei um Unternehmen mit Produkten, die perfekt zum Markt passen und die so schnell wie möglich wachsen müssen; oder Unternehmen mit einer Befehlshierarchie (Apple in den besten Jahren von Jobs), in denen jeder tut, was man ihm sagt. Die moderne Unternehmensforschung (und der gesunde Menschenverstand) legen jedoch nahe, dass maximaler Einfallsreichtum, der zu Innovationskraft in Unternehmen und hoher Produktivität bei Einzelpersonen führt, ein geringes Maß an Stress erfordert, um kontinuierliches kreatives und methodisches Denken zu unterstützen. Und es ist äußerst schwierig, kreative, diskussionsbasierte Arbeit zu leisten, wenn Sie sich ständig Gedanken darüber machen, was Ihre Kollegen zu jeder Zeile Ihres Codes sagen werden.

Negativität ist die Entwicklung der Popkultur

Der Einstellung von Ingenieuren wird heute mehr Aufmerksamkeit geschenkt als je zuvor. In Ingenieurorganisationen gilt die Regel „Keine Hörner". Auf Twitter tauchen immer mehr Anekdoten und Geschichten über Menschen auf, die diesen Beruf aufgegeben haben, weil sie die Feindseligkeit und Feindseligkeit gegenüber Außenstehenden nicht länger ertragen konnten (wollen). Sogar Linus Torvalds habe mich kürzlich entschuldigt wegen seiner jahrelangen Feindseligkeit und Kritik gegenüber anderen Linux-Entwickler - dies führte zu einer Diskussion über die Effektivität dieses Ansatzes.

Einige verteidigen immer noch das Recht von Linus, sehr kritisch zu sein – diejenigen, die viel über die Vor- und Nachteile der „toxischen Negativität“ wissen sollten. Ja, Höflichkeit ist äußerst wichtig (sogar grundlegend), aber wenn wir die Gründe zusammenfassen, warum viele von uns zulassen, dass die Äußerung negativer Meinungen in „Toxizität“ umschlägt, erscheinen diese Gründe paternalistisch oder jugendlich: „Sie haben es verdient, weil sie Idioten sind.“ „, „Er muss sicher sein, dass sie es nicht noch einmal tun“, „Wenn sie das nicht getan hätten, müsste er sie nicht anschreien“ und so weiter. Ein Beispiel für den Einfluss, den die emotionalen Reaktionen einer Führungskraft auf eine Programmiergemeinschaft haben, ist das Akronym MINASWAN der Ruby-Community – „Matz is nice, also sind wir nett.“

Mir ist aufgefallen, dass viele glühende Befürworter des „Kill a Fool“-Ansatzes oft großen Wert auf die Qualität und Korrektheit des Codes legen und sich mit ihrer Arbeit identifizieren. Leider verwechseln sie oft Härte mit Steifigkeit. Der Nachteil dieser Position ergibt sich aus dem einfachen menschlichen, aber unproduktiven Wunsch, sich anderen überlegen zu fühlen. Menschen, die sich diesem Verlangen hingeben, bleiben auf dem Weg der Dunkelheit stecken.

Die Welt des Programmierens wächst rasant und stößt an die Grenzen ihres Containers – der Welt des Nicht-Programmierens (oder ist die Welt des Programmierens ein Container für die Welt des Nicht-Programmierens? Gute Frage).

Da unsere Branche immer schneller wächst und Programme immer zugänglicher werden, verringert sich die Kluft zwischen „Technikfreaks“ und „Normalen“ rapide. Die Welt des Programmierens ist zunehmend den zwischenmenschlichen Interaktionen von Menschen ausgesetzt, die in der isolierten Nerd-Kultur des frühen Tech-Booms aufgewachsen sind, und sie sind es, die die neue Welt des Programmierens prägen werden. Und unabhängig von sozialen oder generationsbezogenen Argumenten wird sich Effizienz im Namen des Kapitalismus in der Unternehmenskultur und den Einstellungspraktiken zeigen: Die besten Unternehmen stellen einfach niemanden ein, der nicht neutral mit anderen umgehen kann, geschweige denn gute Beziehungen pflegen kann.

Was ich über Negativität gelernt habe

Wenn Sie zulassen, dass zu viel Negativität Ihren Geist und Ihre Interaktionen mit Menschen kontrolliert und sich in Toxizität verwandelt, ist das gefährlich für Produktteams und teuer für das Unternehmen. Ich habe unzählige Projekte gesehen (und davon gehört), die auseinanderfielen und mit großem Aufwand komplett neu aufgebaut wurden, weil ein vertrauenswürdiger Entwickler einen Groll gegen die Technologie, einen anderen Entwickler oder sogar eine einzelne Datei hatte, die ausgewählt wurde, um die Qualität der gesamten Codebasis darzustellen.

Negativität demoralisiert und zerstört auch Beziehungen. Ich werde nie vergessen, wie ein Kollege mich beschimpfte, weil ich CSS in die falsche Datei eingefügt hatte. Das hat mich verärgert und mir mehrere Tage lang nicht erlaubt, meine Gedanken zu ordnen. Und in Zukunft werde ich einer solchen Person wahrscheinlich nicht erlauben, in der Nähe eines meiner Teams zu sein (aber wer weiß, die Leute ändern sich).

Zum Schluss noch das Negative schadet buchstäblich Ihrer Gesundheit.

Ich denke, so sollte ein Meisterkurs zum Thema Lächeln aussehen.

Das ist natürlich kein Argument dafür, vor Glück zu strahlen, zehn Milliarden Emoticons in jeden Pull-Request einzubauen oder einen Meisterkurs zum Thema Lächeln zu besuchen (nein, wenn du das willst, dann keine Frage). Negativität ist ein äußerst wichtiger Teil der Programmierung (und des menschlichen Lebens), sie signalisiert Qualität und ermöglicht es einem, Gefühle auszudrücken und Mitgefühl mit Mitmenschen zu empfinden. Negativität weist auf Einsicht und Besonnenheit hin, auf die Tiefe des Problems. Ich bemerke oft, dass ein Entwickler ein neues Niveau erreicht hat, wenn er anfängt, Unglauben an das zu äußern, worüber er vorher schüchtern und unsicher war. Menschen zeigen mit ihren Meinungen Vernünftigkeit und Selbstvertrauen. Man kann den Ausdruck von Negativität nicht abtun, das wäre orwellianisch.

Negativität muss jedoch dosiert und mit anderen wichtigen menschlichen Eigenschaften in Einklang gebracht werden: Empathie, Geduld, Verständnis und Humor. Man kann einer Person immer sagen, dass sie es vermasselt hat, ohne zu schreien oder zu fluchen. Unterschätzen Sie diesen Ansatz nicht: Wenn Ihnen jemand emotionslos sagt, dass Sie einen großen Fehler gemacht haben, ist das wirklich beängstigend.

Damals, vor einigen Jahren, sprach der CEO mit mir. Wir besprachen den aktuellen Stand des Projekts, dann fragte er, wie es mir ginge. Ich antwortete, dass alles in Ordnung sei, das Projekt voranschreite, wir langsam arbeiteten, vielleicht habe ich etwas verpasst und müsse es mir noch einmal überlegen. Er sagte, er habe gehört, wie ich mit Kollegen im Büro pessimistischere Gedanken geäußert habe, und dass dies auch anderen aufgefallen sei. Er erklärte mir, wenn ich Zweifel hätte, könne ich diese dem Management gegenüber deutlich äußern, sie aber nicht „zerstreuen“. Als leitender Ingenieur muss ich darauf achten, wie meine Worte andere beeinflussen, denn ich habe großen Einfluss, auch wenn ich mir dessen nicht bewusst bin. Und er erzählte mir das alles sehr freundlich und sagte schließlich, wenn ich wirklich so fühle, dann müsste ich wahrscheinlich darüber nachdenken, was ich für mich und meine Karriere will. Es war ein unglaublich sanftes Gespräch, bei dem es darum ging, ob man es schafft oder aufsteht. Ich dankte ihm für die Information, wie sich meine über sechs Monate veränderte Einstellung auf andere auswirkte, ohne dass ich es bemerkte.

Es war ein Beispiel für bemerkenswertes, effektives Management und die Kraft eines sanften Ansatzes. Mir wurde klar, dass ich nur scheinbar volles Vertrauen in das Unternehmen und seine Fähigkeit hatte, seine Ziele zu erreichen, aber in Wirklichkeit habe ich auf ganz andere Weise mit anderen gesprochen und kommuniziert. Mir wurde auch klar, dass ich, selbst wenn ich dem Projekt, an dem ich arbeitete, skeptisch gegenüberstand, meine Gefühle gegenüber meinen Kollegen nicht zeigen und Pessimismus wie eine Ansteckung verbreiten sollte, die unsere Erfolgschancen schmälerte. Stattdessen könnte ich meinem Management offensiv die reale Situation vermitteln. Und wenn ich das Gefühl hätte, dass sie mir nicht zuhören, könnte ich meine Meinungsverschiedenheit zum Ausdruck bringen, indem ich das Unternehmen verlasse.

Eine neue Chance erhielt ich mit der Übernahme der Leitung Personalbeurteilung. Als ehemaliger Chefingenieur bin ich sehr vorsichtig, wenn es darum geht, meine Meinung zu unserem (sich ständig verbessernden) Legacy-Code zu äußern. Um einer Änderung zuzustimmen, muss man sich die aktuelle Situation vorstellen, aber wenn man sich in Gejammer, Angriffen oder Ähnlichem suhlt, kommt man nicht weiter. Letztlich bin ich hier, um eine Aufgabe zu erledigen und sollte mich nicht über den Code beschweren, um ihn zu verstehen, zu bewerten oder zu reparieren.

Je besser ich meine emotionale Reaktion auf den Code kontrolliere, desto besser verstehe ich, was daraus werden könnte, und desto weniger Verwirrung verspüre ich. Wenn ich mich zurückhaltend ausdrückte („Hier muss es Raum für weitere Verbesserungen geben“), wollte ich mich und andere glücklich machen und die Situation nicht zu ernst nehmen. Mir wurde klar, dass ich Negativität bei anderen anregen und reduzieren kann, indem ich völlig (nervig?) vernünftig bin („Sie haben Recht, dieser Code ist ziemlich schlecht, aber wir werden ihn verbessern“). Ich bin froh zu sehen, wie weit ich auf dem Zen-Weg kommen kann.

Im Wesentlichen lerne und lerne ich ständig eine wichtige Lektion: Das Leben ist zu kurz, um ständig wütend zu sein und Schmerzen zu haben.

Source: habr.com