Ich habe einige Erfahrungen mit „schlechtem Code“ gemacht. Oft habe ich allein gearbeitet, aber auch in Teams Code geschrieben, der zwar funktionierte, aber nicht optimal war. Wenn ich versucht habe, alten Code zusammen mit neuer Arbeit zu refaktorieren, wurde das häufig abgelehnt; notwendige Refactorings oder Korrekturen wurden zwar als Tickets erfasst, aber meist nach hinten priorisiert oder ignoriert.
Wenn man allein ist, kann man notwendige Arbeit priorisieren, aber im Team bleiben suboptimale Entscheidungen ewig bestehen oder werden bis zum Moment „System down“ liegen gelassen. Wenn man danach in der Postmortem-Analyse auf ein Ticket verweist, in dem man schon Monate zuvor darum gebeten hatte, die Bombe zu entschärfen, wurde das als „Schuldzuweisung“ oder „aggressiv“ aufgefasst. Am Ende schien die Lösung darin zu bestehen, niemals suboptimalen Code zu schreiben, was beim Programmieren Frust und Angst verstärkte.
2017 wurde ich auch kontaktiert, um Code zu reparieren, den ich 2003/2004 geschrieben hatte, und dieser Code lief immer noch in Produktion. Sich kaputten Code und die Kompromisse noch einmal anzusehen und zu erkennen, dass man selbst der Verantwortliche war, ist eine ziemlich demütigende Erfahrung; danach hat sich meine Sicht auf wartbaren Code und Dokumentation stark verändert.
Das hängt vom Team und vom Unternehmen ab. Ich habe viele Teams erlebt, in denen Entwickler ermutigt wurden, Zeit in Code-Wartung und Refactoring zu investieren, manchmal sogar dazu gezwungen wurden, genau das zu tun; in denen engineering-zentrierte Arbeit Vorrang vor zufälligen Produktanforderungen hatte und Zeitpläne angepasst wurden, damit Dinge ordentlich abgeschlossen werden konnten.
Diese Erfahrungen waren für mich ziemlich normal, von großen S&P-500-Unternehmen über Firmen mit 100 Mio. bis 1 Mrd. Dollar Größe bis hin zu Startups. In solchen Fällen gab es erfahrene Software Engineers und Manager, die vernünftige Kompromisse eingehen und zugleich geschäftliche Anforderungen berücksichtigen konnten; außerdem interagierten Engineers häufig direkt mit Kunden.
Entscheidend ist die Balance, und diese Balance entsteht meist durch Menschen, die ausgewogen urteilen können. Wenn man nur nach „Perfektion“ strebt, endet das in endlosem Refactoring und nie veröffentlichten Releases; wenn man technische Schulden oder miserable Qualität ignoriert, kann das Geschäft mit der Zeit zusammenbrechen. Wo man sich positioniert, hängt von Produkt, Branche, Kunden und Business ab.
Entweder man stirbt als Held, oder man lebt lange genug, um seinen Namen in einem zehn Jahre alten git blame zu sehen.
„Funktioniert, ist aber nicht optimal“ ist oft ein akzeptabler Kompromiss, wenn die Zeit knapp ist und viel zu tun bleibt. Auch MBA-Slogans wie „Perfektion ist der Feind des Guten“ sind Formulierungen, die man verwenden kann, wenn etwas fehlt.
Dass du 2017 gerufen wurdest, um Code zu reparieren, den du 2003/2004 geschrieben hast, heißt auch, dass wir alle Zeitreisende sind. Gegenüber meinem früheren Ich bin ich nachsichtig, gegenüber meinem zukünftigen Ich ein bisschen unhöflich.
Mein früheres Ich war jung und naiv, aber produktiv und hat viele Berge überwunden. Es hat zwei Tage gedauert, den Code zu verstehen, aber am Ende war er ziemlich clever; vielleicht liegt es auch nur an meinem schlechten Gedächtnis, dass mein heutiges Ich alles vergessen hat.
Mein zukünftiges Ich wird alle Fehler beheben. Es ist älter und weiser und glaubt, unendlich viel Zeit zu haben, um XXX und TBD durch klugen Code zu ersetzen, gute Ideen umzusetzen und mittelmäßige Ideen noch einmal neu zu implementieren. Mit besseren Kommentaren könnten diese drei vielleicht eins werden.
Ich halte diese rechtschaffene Haltung vom Typ „dieser eine Mensch“ für schädlich. Dass Senior-Entwickler über ihre eigenen Fehler und gescheiterten Dinge sprechen können, ist sehr befreiend und gesund.
Es ist nicht nur eine einfache Lernchance, sondern zeigt auch eine offene Kultur und wirkt dem Impostor-Syndrom entgegen. Eine perfektionistische Haltung bewirkt das Gegenteil: Sie läuft nur auf „streng dich mehr an und mach keine Fehler“ hinaus, daraus lernt man nichts, und es verlangt lediglich mehr individuelle Anstrengung.
Mindestens zweimal habe ich erlebt, dass „dieser eine Mensch“ einen großen Fehler nicht eingeräumt hat, ihn selbst um den Preis eines guten Kunden vermied und vermutlich hinterher schlecht darüber geredet hätte.
Einmal habe ich einen kleinen Fehler auf mich genommen, bei dem ein Junior die falsche Softwareversion in einen Bericht geschrieben hatte. Man hätte dem Kunden einfach sagen können: „Es gab einen Fehler, hier ist der korrigierte Bericht.“ Mein Vorgesetzter dachte aber nur: „Können wir das verbergen und den Anschein wahren, dass wir perfekt sind?“ Dieselbe Person nutzte Fehler anderer als Gelegenheit, Rabatte, Entschädigungen oder kostenlose Leistungen zu verlangen.
Ich denke, die meisten machen einfach ihre Arbeit und werden besser. In unserem Konfigurationsmanagement gibt es einiges, das ich geschrieben habe und das funktional gut funktioniert, aber nachdem ich ein bis zwei Jahre mit den Tools gearbeitet hatte, würde ich es aus mehreren Gründen als ziemlich schlechte Qualität bezeichnen.
Das ist trotzdem in Ordnung. Wenn es einen Grund gibt, es zu ändern, räumen wir es auf; bis dahin bleibt es als Beispiel für schlechte Praktiken und bessere Ansätze bestehen.
Wenn man an sich selbst nichts zu kritisieren findet, bedeutet das, dass man sich nicht weiterentwickelt. Wenn man solche Selbstkritik teilt, können andere aus meinen Fehlern lernen und sehen, dass es in Ordnung ist, aus den eigenen Fehlern zu lernen.
In Code Reviews höre ich oft Dinge wie „Warum machst du diesen Fehler nicht einfach nicht?“ oder „Warum machst du es nicht einfach so?“
Heutzutage antworte ich: „Wahrscheinlich ist Ihr IQ höher als meiner. Da meiner niedrig ist, muss ich dümmere und einfachere Dinge tun.“ Dann merkt die andere Person manchmal, wie sehr sie sich wie ein wenig reflektierter, herabsetzender Sonderling verhalten hat, und wird rot.
Gegen Fragen, die mit „Warum nicht einfach …?“ anfangen, habe ich eine gewisse Allergie. Sobald ich diese drei Wörter höre, kann ich meist schon ahnen, welcher Vorschlag folgt — nicht weil er unglaublich komplex wäre, sondern weil es in der Regel die naheliegendste Methode ist, die einem als Erstes einfällt, und sie bereits sorgfältig geprüft oder ausprobiert wurde.
Die Frage an sich ist nicht schlecht, aber die Annahmen „Meine Idee ist so einfach“ und „Du bist nicht auf diesen offensichtlichen und einfachen Gedanken gekommen“ wirken ärgerlich oder beleidigend. Umgekehrt versuche ich, wenn ich andere frage, „warum nicht einfach“ zu vermeiden und eher zu formulieren: „Kann ich davon ausgehen, dass es einen Grund gibt, warum X nicht gemacht wurde?“ Oder ich frage einfach freundlich nach dem Grund.
Wenn die Frage aus fehlendem Kontext entsteht, kann man dem vorbeugen, indem man vor der Erklärung der eigenen Arbeit zuerst darlegt, warum die offensichtlichsten Methoden nicht funktioniert haben, oder indem man schwierige Anforderungen und problematische Eingaben nennt. Wenn der Code bereits committed ist, besteht das Ziel darin, nachträgliche Einwürfe durch Kommentare im Commit oder Merge Request zu reduzieren. Manchmal ist es auch hilfreich, nicht zu widersprechen, sondern direkt zu erklären, dass man diesen Ansatz ausprobiert hat und warum er nicht funktioniert hat, und ehrlich zu fragen, ob es andere Ideen gibt.
Wenn es wirklich ein Vorschlag ist, an den ich nicht gedacht habe und der das Problem lösen könnte, sage ich, dass es eine gute Idee ist, und bitte um Hilfe bei der Umsetzung. In solchen Momenten ist die Versuchung da, gegen die Annahmen oder den Tonfall der anderen Person anzugehen, aber ich versuche, es einfach anzunehmen und mich kurz zu schämen.
Das ist ein sehr gutes Beispiel für die Anwendung von grug brain: https://grugbrain.dev/
„Wenn grug zwischen Komplexität und einem Eins-gegen-eins-Kampf mit einem Tyrannosaurus wählen müsste, würde grug den Tyrannosaurus wählen. Zumindest kann grug den Tyrannosaurus sehen.“
Wenn das kein Witz ist, ist die erste Frage nicht hilfreich und fast schon gemein. Jeder macht manchmal Fehler.
Die zweite Frage kann in der Regel durchaus gutes Feedback sein. Die Fähigkeiten und das Wissen von Menschen überschneiden sich nicht immer. Was für A wahnsinnig kompliziert ist, muss es für B nicht sein, und umgekehrt; das heißt nicht unbedingt, dass jemand klüger ist. A kennt vielleicht kein SQL, B kennt vielleicht kein pandas.
Wenn man annimmt, dass im Tech-Stack bereits sowohl SQL als auch pandas vorhanden sind, kann es manchmal sinnvoll sein, Code von SQL nach pandas zu verlagern oder umgekehrt. Manche Menschen finden objektorientierten Stil leichter, andere funktionalen Stil. Was sinnvoller ist, ist nicht immer offensichtlich, daher kann die Frage eine gute Frage sein. Wenn der Vorschlag schlecht ist, erklärt man, warum er schlecht ist; wenn er gut ist, wägt man ab, ob es sich lohnt, ihn jetzt umzusetzen. Liegt er irgendwo dazwischen oder fehlt die Zeit, kann man das anerkennen und weitermachen.
Eine andere Möglichkeit ist, einfach klar zuzustimmen. Man kann antworten: „Stimmt, das war dumm, oder?“, „Stimmt, vielleicht hätten wir das nicht tun sollen“ oder „Ich denke darüber nach“.
Dann wird es für die andere Person schwer, einen dafür zu beschämen oder einem Schuldgefühle zu machen, dass man etwas Suboptimales getan hat. Der Zweck solcher Aussagen ist meiner Ansicht nach oft, durch Beschämung Überlegenheit herzustellen. Man entscheidet sich, bei diesem Spiel nicht mitzuspielen, und das ist meistens der Gewinnzug.
Wenn es aus Unwissenheit gesagt wurde, muss man es nicht unbedingt als Angriff auffassen, die andere Person bloßstellen und sie dafür bezahlen lassen.
Ich kann den Blogpost oder Artikel, den ich früher gesehen habe, nicht mehr finden, aber die Botschaft war: „Wenn du in Code etwas Nicht-Optimales siehst, geh nicht von Inkompetenz aus.“ Die Person, die den Code geschrieben hat, hatte vielleicht enge Deadlines, andere Prioritäten oder sonstige Gründe, aus denen sie nicht sofort „das Richtige“ tun konnte.
Selbst wenn der Code zum Zeitpunkt seiner Entstehung perfekt war, können Wachstum der Codebase und veränderte Anforderungen ihn schlecht werden lassen.
Wenn man zum Beispiel 10 Einträge speichern muss, kann eine einfache Datei eine pragmatische Wahl sein; bei 10.000 Einträgen braucht man vielleicht eine Datenbank. Hätte man aber von Anfang an für 10 Einträge eine Datenbank verwendet, hätten sich Leute über Overengineering beschwert.
Bei 2 Klassen reicht if/else, bei 20 Klassen braucht man vielleicht ein Factory Pattern; hätte man es von Anfang an eingebaut, hätte es wie Architektur-Astronautik ausgesehen. Wenn man versucht, solches Wachstum vorherzusagen, und falsch liegt, erzeugt man komplizierten Code. Projekte, die weiterentwickelt werden, wachsen systematisch über sich selbst hinaus.
Es gibt auch Chestertons Zaun. Etwas Dummes im Code kann früher tatsächlich wichtig gewesen sein. Schlimmer noch: Vielleicht ist es auch heute noch für einen seltenen Edge Case wichtig, aber man sieht den Grund noch nicht.
Ich habe hier und auf reddit ein paar Mal bösartige Kommentare zu Blogposts bekommen. In solchen Fällen nutze ich die Methode, ohne Wertung einen Link zu diesem bösartigen Kommentar in den Beitrag aufzunehmen und so Licht darauf zu werfen. Meist passiert nichts, aber manchmal lenkt es die Diskussion in eine gesündere Richtung.
Ich habe auch ziemlich viele davon bekommen. Einige davon waren vielleicht verdient, die meisten vermutlich nicht. Manche waren in gewissem Maße richtig, aber nicht hilfreich oder direkt schädlich für die Community. Wenn man etwas Richtiges auf die falsche Weise sagt, sagt man immer noch etwas Falsches.
Bösartige Kommentare ohne Wertung zu verlinken, ist keine schlechte Idee. Wenn ein Kommentar als tot markiert wird, geht das nicht immer, aber ich schlage jedenfalls nicht in derselben Weise zurück. Ich könnte das auch, aber ich habe gelernt, dass Benzin kein wirksames Löschmittel ist.
Wenn ich falschliege, versuche ich, den Fehler direkt an derselben Stelle einzugestehen, an der er passiert ist. Private Entschuldigungen nach öffentlichen Angriffen mag ich besonders wenig.
Es gibt Grenzen. Ich habe das Gefühl, dass ich ziemlich gute Arbeit leiste; ich mache das seit etwa 40 Jahren und habe in der Zeit viel gelernt. Ich habe auch in anspruchsvollen Umgebungen gearbeitet, in denen minderwertige Arbeit nicht akzeptiert wurde, sodass es mir zur Gewohnheit geworden ist, ordentliche Arbeit zu leisten.
Im Allgemeinen vermeide ich es, andere öffentlich zu beurteilen. Es hilft nicht, und ich habe auch nicht immer recht. Anders kann es sein, wenn ich mit jemandem zusammenarbeite oder etwas von dieser Person nutze. Ich bin schon heftig angegriffen worden, weil ich keinen Schrott akzeptiere, aber ich verhalte mich nicht wie Linus Torvalds. Wenn möglich, sage ich respektvoll, dass diese Arbeit für mich nicht akzeptabel ist.
Trotzdem kann man sich immer verbessern und Neues lernen, und manchmal lernt man an völlig unerwarteten Stellen. Für solches Lernen offen zu sein, ist grundsätzlich eine gute Strategie. Ich werde richtig, indem ich falschliege und lerne. „Gutes Urteilsvermögen kommt aus Erfahrung, und Erfahrung kommt aus schlechtem Urteilsvermögen.“
Einer meiner Lieblingspodcasts, „well there's your problem“ auf YouTube, pinnt fast immer einen Kommentar an, der sich über den Podcast beschwert. Meist laufen die Beschwerden darauf hinaus: „Ich mag diesen Podcast nicht, also sollte er ein anderer Podcast sein“, und der angepinnte Kommentar ist jedes Mal nahe an der dümmstmöglichen Interpretation der jeweiligen Folge.
Ich weiß nicht, ob das solche Kommentare reduziert, aber es hat schon den Sinn, Leuten, die sich auf diese Weise am Diskurs beteiligen, metaphorisch eine Trottelmütze aufzusetzen.
Ich stimme zu, dass manche Engineers eine schlechte Haltung haben. Jeder kann schlechten Code schreiben, und an der Logik, dass jeder Code schlecht und Schuld ist, ist etwas dran.
Dieser Beitrag ist interessant zusammen mit „No more pink mustache“ zu lesen. Darin wird Lyft als „in unglaublichem Ausmaß kaputt“ beschrieben; die Ursache für Qualität liegt oft nicht bei der Person auf dem Stuhl, sondern bei der Organisation. :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Ich habe diesen Beitrag 2018 gelesen und freue mich, dass er wieder aufgetaucht ist. Es war einer der Texte, die mich dazu gebracht haben, mir Fragen zu stellen. Wenn man Absolutismus oder Extremität nicht beseitigen kann: Welche Filter kann man entwickeln, wenn man solchen Gesprächen oder Menschen begegnet? Ich habe mein Modell, bin aber neugierig, welche Strategien andere nutzen.
Solche Menschen versuchen, emotionalen Raum einzunehmen, der ihnen nicht gehört. Normalerweise haben sie vorher kalkuliert, dass sie „damit durchkommen“, was bedeutet, dass sie ihr Gegenüber als schwach ansehen.
Es gibt drei Optionen. Aufgeben, ihnen diesen Raum überlassen und mit dem Leben weitermachen; je weniger Schlaf man wegen der Ungerechtigkeit verliert, desto besser. Sich direkt entgegenstellen; sie sind zwar auf einen Kampf vorbereitet, aber ihre Position ist im Kern irrational, und je weniger man in ihren Denkraum hineingezogen wird, desto eher „gewinnt“ man. Von oben kommen: sozialen Beweis, dass sie falschliegen, in ihren Raum bringen. Im Fall des Originalbeitrags wären das produktive Programmierer, die die Arbeit der anderen respektieren und nicht kleinlich herumkritteln.
Wenn jemand den Rat gibt: „So hätte es besser sein können“, ist das nicht immer ein Angriff auf mich oder eine Beleidigung meiner Fähigkeiten.
Der Ratgebende kann ein sozial unbeholfener Idiot sein – oder einfach ein kompletter Idiot. Es ist in Ordnung, wenn ein Teil der Welt nicht meiner Meinung ist. Wenn Menschen widersprechen oder anderer Meinung sind, bedroht mich das nicht.
Ein seltsamer Text. Er klingt wie ein Tweet, hat wenig Substanz, und der Titel spiegelt den Inhalt nicht wider, sodass er wie Clickbait wirkt.
Ich widerspreche der Kernaussage nicht, aber es gibt auch die andere Seite. Man braucht auch die Fähigkeit, Feedback anzunehmen.
Die meisten Menschen können Feedback annehmen und umsetzen. Manche geben Feedback jedoch miserabel und glauben dann, die andere Person könne kein Feedback annehmen.
Solche Menschen halten ihre bevorzugte Art von Feedback für die beste und meinen, alle müssten das genauso empfinden; andernfalls müsse sich die andere Person ändern. Das ist natürlich falsch. Wenn man ihnen das aber sagt, zeigen sie selbst, warum im ersten Satz „die meisten“ stand.
1 Kommentare
Meinungen auf Hacker News
Wenn man allein ist, kann man notwendige Arbeit priorisieren, aber im Team bleiben suboptimale Entscheidungen ewig bestehen oder werden bis zum Moment „System down“ liegen gelassen. Wenn man danach in der Postmortem-Analyse auf ein Ticket verweist, in dem man schon Monate zuvor darum gebeten hatte, die Bombe zu entschärfen, wurde das als „Schuldzuweisung“ oder „aggressiv“ aufgefasst. Am Ende schien die Lösung darin zu bestehen, niemals suboptimalen Code zu schreiben, was beim Programmieren Frust und Angst verstärkte.
2017 wurde ich auch kontaktiert, um Code zu reparieren, den ich 2003/2004 geschrieben hatte, und dieser Code lief immer noch in Produktion. Sich kaputten Code und die Kompromisse noch einmal anzusehen und zu erkennen, dass man selbst der Verantwortliche war, ist eine ziemlich demütigende Erfahrung; danach hat sich meine Sicht auf wartbaren Code und Dokumentation stark verändert.
Diese Erfahrungen waren für mich ziemlich normal, von großen S&P-500-Unternehmen über Firmen mit 100 Mio. bis 1 Mrd. Dollar Größe bis hin zu Startups. In solchen Fällen gab es erfahrene Software Engineers und Manager, die vernünftige Kompromisse eingehen und zugleich geschäftliche Anforderungen berücksichtigen konnten; außerdem interagierten Engineers häufig direkt mit Kunden.
Entscheidend ist die Balance, und diese Balance entsteht meist durch Menschen, die ausgewogen urteilen können. Wenn man nur nach „Perfektion“ strebt, endet das in endlosem Refactoring und nie veröffentlichten Releases; wenn man technische Schulden oder miserable Qualität ignoriert, kann das Geschäft mit der Zeit zusammenbrechen. Wo man sich positioniert, hängt von Produkt, Branche, Kunden und Business ab.
Mein früheres Ich war jung und naiv, aber produktiv und hat viele Berge überwunden. Es hat zwei Tage gedauert, den Code zu verstehen, aber am Ende war er ziemlich clever; vielleicht liegt es auch nur an meinem schlechten Gedächtnis, dass mein heutiges Ich alles vergessen hat.
Mein zukünftiges Ich wird alle Fehler beheben. Es ist älter und weiser und glaubt, unendlich viel Zeit zu haben, um XXX und TBD durch klugen Code zu ersetzen, gute Ideen umzusetzen und mittelmäßige Ideen noch einmal neu zu implementieren. Mit besseren Kommentaren könnten diese drei vielleicht eins werden.
Es ist nicht nur eine einfache Lernchance, sondern zeigt auch eine offene Kultur und wirkt dem Impostor-Syndrom entgegen. Eine perfektionistische Haltung bewirkt das Gegenteil: Sie läuft nur auf „streng dich mehr an und mach keine Fehler“ hinaus, daraus lernt man nichts, und es verlangt lediglich mehr individuelle Anstrengung.
Einmal habe ich einen kleinen Fehler auf mich genommen, bei dem ein Junior die falsche Softwareversion in einen Bericht geschrieben hatte. Man hätte dem Kunden einfach sagen können: „Es gab einen Fehler, hier ist der korrigierte Bericht.“ Mein Vorgesetzter dachte aber nur: „Können wir das verbergen und den Anschein wahren, dass wir perfekt sind?“ Dieselbe Person nutzte Fehler anderer als Gelegenheit, Rabatte, Entschädigungen oder kostenlose Leistungen zu verlangen.
Das ist trotzdem in Ordnung. Wenn es einen Grund gibt, es zu ändern, räumen wir es auf; bis dahin bleibt es als Beispiel für schlechte Praktiken und bessere Ansätze bestehen.
Heutzutage antworte ich: „Wahrscheinlich ist Ihr IQ höher als meiner. Da meiner niedrig ist, muss ich dümmere und einfachere Dinge tun.“ Dann merkt die andere Person manchmal, wie sehr sie sich wie ein wenig reflektierter, herabsetzender Sonderling verhalten hat, und wird rot.
Die Frage an sich ist nicht schlecht, aber die Annahmen „Meine Idee ist so einfach“ und „Du bist nicht auf diesen offensichtlichen und einfachen Gedanken gekommen“ wirken ärgerlich oder beleidigend. Umgekehrt versuche ich, wenn ich andere frage, „warum nicht einfach“ zu vermeiden und eher zu formulieren: „Kann ich davon ausgehen, dass es einen Grund gibt, warum X nicht gemacht wurde?“ Oder ich frage einfach freundlich nach dem Grund.
Wenn die Frage aus fehlendem Kontext entsteht, kann man dem vorbeugen, indem man vor der Erklärung der eigenen Arbeit zuerst darlegt, warum die offensichtlichsten Methoden nicht funktioniert haben, oder indem man schwierige Anforderungen und problematische Eingaben nennt. Wenn der Code bereits committed ist, besteht das Ziel darin, nachträgliche Einwürfe durch Kommentare im Commit oder Merge Request zu reduzieren. Manchmal ist es auch hilfreich, nicht zu widersprechen, sondern direkt zu erklären, dass man diesen Ansatz ausprobiert hat und warum er nicht funktioniert hat, und ehrlich zu fragen, ob es andere Ideen gibt.
Wenn es wirklich ein Vorschlag ist, an den ich nicht gedacht habe und der das Problem lösen könnte, sage ich, dass es eine gute Idee ist, und bitte um Hilfe bei der Umsetzung. In solchen Momenten ist die Versuchung da, gegen die Annahmen oder den Tonfall der anderen Person anzugehen, aber ich versuche, es einfach anzunehmen und mich kurz zu schämen.
„Wenn grug zwischen Komplexität und einem Eins-gegen-eins-Kampf mit einem Tyrannosaurus wählen müsste, würde grug den Tyrannosaurus wählen. Zumindest kann grug den Tyrannosaurus sehen.“
Die zweite Frage kann in der Regel durchaus gutes Feedback sein. Die Fähigkeiten und das Wissen von Menschen überschneiden sich nicht immer. Was für A wahnsinnig kompliziert ist, muss es für B nicht sein, und umgekehrt; das heißt nicht unbedingt, dass jemand klüger ist. A kennt vielleicht kein SQL, B kennt vielleicht kein pandas.
Wenn man annimmt, dass im Tech-Stack bereits sowohl SQL als auch pandas vorhanden sind, kann es manchmal sinnvoll sein, Code von SQL nach pandas zu verlagern oder umgekehrt. Manche Menschen finden objektorientierten Stil leichter, andere funktionalen Stil. Was sinnvoller ist, ist nicht immer offensichtlich, daher kann die Frage eine gute Frage sein. Wenn der Vorschlag schlecht ist, erklärt man, warum er schlecht ist; wenn er gut ist, wägt man ab, ob es sich lohnt, ihn jetzt umzusetzen. Liegt er irgendwo dazwischen oder fehlt die Zeit, kann man das anerkennen und weitermachen.
Dann wird es für die andere Person schwer, einen dafür zu beschämen oder einem Schuldgefühle zu machen, dass man etwas Suboptimales getan hat. Der Zweck solcher Aussagen ist meiner Ansicht nach oft, durch Beschämung Überlegenheit herzustellen. Man entscheidet sich, bei diesem Spiel nicht mitzuspielen, und das ist meistens der Gewinnzug.
Wenn man zum Beispiel 10 Einträge speichern muss, kann eine einfache Datei eine pragmatische Wahl sein; bei 10.000 Einträgen braucht man vielleicht eine Datenbank. Hätte man aber von Anfang an für 10 Einträge eine Datenbank verwendet, hätten sich Leute über Overengineering beschwert.
Bei 2 Klassen reicht if/else, bei 20 Klassen braucht man vielleicht ein Factory Pattern; hätte man es von Anfang an eingebaut, hätte es wie Architektur-Astronautik ausgesehen. Wenn man versucht, solches Wachstum vorherzusagen, und falsch liegt, erzeugt man komplizierten Code. Projekte, die weiterentwickelt werden, wachsen systematisch über sich selbst hinaus.
Bösartige Kommentare ohne Wertung zu verlinken, ist keine schlechte Idee. Wenn ein Kommentar als tot markiert wird, geht das nicht immer, aber ich schlage jedenfalls nicht in derselben Weise zurück. Ich könnte das auch, aber ich habe gelernt, dass Benzin kein wirksames Löschmittel ist.
Wenn ich falschliege, versuche ich, den Fehler direkt an derselben Stelle einzugestehen, an der er passiert ist. Private Entschuldigungen nach öffentlichen Angriffen mag ich besonders wenig.
Es gibt Grenzen. Ich habe das Gefühl, dass ich ziemlich gute Arbeit leiste; ich mache das seit etwa 40 Jahren und habe in der Zeit viel gelernt. Ich habe auch in anspruchsvollen Umgebungen gearbeitet, in denen minderwertige Arbeit nicht akzeptiert wurde, sodass es mir zur Gewohnheit geworden ist, ordentliche Arbeit zu leisten.
Im Allgemeinen vermeide ich es, andere öffentlich zu beurteilen. Es hilft nicht, und ich habe auch nicht immer recht. Anders kann es sein, wenn ich mit jemandem zusammenarbeite oder etwas von dieser Person nutze. Ich bin schon heftig angegriffen worden, weil ich keinen Schrott akzeptiere, aber ich verhalte mich nicht wie Linus Torvalds. Wenn möglich, sage ich respektvoll, dass diese Arbeit für mich nicht akzeptabel ist.
Trotzdem kann man sich immer verbessern und Neues lernen, und manchmal lernt man an völlig unerwarteten Stellen. Für solches Lernen offen zu sein, ist grundsätzlich eine gute Strategie. Ich werde richtig, indem ich falschliege und lerne. „Gutes Urteilsvermögen kommt aus Erfahrung, und Erfahrung kommt aus schlechtem Urteilsvermögen.“
Ich weiß nicht, ob das solche Kommentare reduziert, aber es hat schon den Sinn, Leuten, die sich auf diese Weise am Diskurs beteiligen, metaphorisch eine Trottelmütze aufzusetzen.
Dieser Beitrag ist interessant zusammen mit „No more pink mustache“ zu lesen. Darin wird Lyft als „in unglaublichem Ausmaß kaputt“ beschrieben; die Ursache für Qualität liegt oft nicht bei der Person auf dem Stuhl, sondern bei der Organisation. :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Es gibt drei Optionen. Aufgeben, ihnen diesen Raum überlassen und mit dem Leben weitermachen; je weniger Schlaf man wegen der Ungerechtigkeit verliert, desto besser. Sich direkt entgegenstellen; sie sind zwar auf einen Kampf vorbereitet, aber ihre Position ist im Kern irrational, und je weniger man in ihren Denkraum hineingezogen wird, desto eher „gewinnt“ man. Von oben kommen: sozialen Beweis, dass sie falschliegen, in ihren Raum bringen. Im Fall des Originalbeitrags wären das produktive Programmierer, die die Arbeit der anderen respektieren und nicht kleinlich herumkritteln.
Der Ratgebende kann ein sozial unbeholfener Idiot sein – oder einfach ein kompletter Idiot. Es ist in Ordnung, wenn ein Teil der Welt nicht meiner Meinung ist. Wenn Menschen widersprechen oder anderer Meinung sind, bedroht mich das nicht.
Solche Menschen halten ihre bevorzugte Art von Feedback für die beste und meinen, alle müssten das genauso empfinden; andernfalls müsse sich die andere Person ändern. Das ist natürlich falsch. Wenn man ihnen das aber sagt, zeigen sie selbst, warum im ersten Satz „die meisten“ stand.