Behandeln Sie Kritik an frühem Code beim Start

Sie haben eine taktische Entscheidung getroffen, einige technische Schulden zu akzeptieren, um ein funktionsfähiges Endprodukt zu liefern. Sie haben von einem leeren Blatt Papier aus gearbeitet und etwas geschaffen, das gut genug ist, dass Kunden und Investoren es verwenden wollen. Seien Sie stolz darauf – es sollte eine der ersten Zeilen in Ihrem Lebenslauf sein.

Jetzt wird das System immer reifer. Sie haben andere Entwickler, die einen objektiven Blick darauf werfen können, was entwickelt wurde, und (vielleicht gültige) Ideen haben, wie es verbessert werden kann.

Ihre Rolle ist jetzt nicht, ein Code-Affe zu sein. Ihre Position ist es, sich zu erheben und Ihre Programmierer zu verwalten. Sie haben Domänenwissen, das sie nicht haben – Sie wissen, warum bestimmte Entscheidungen getroffen wurden. Sie sollten sich frei fühlen, Ideen mit Ihnen zu besprechen, wie das Produkt besser gemacht werden kann – schneller, mehr Funktionalität, sicherer, skalierbarer. Wenn Ihnen ein Entwickler diese Vorschläge nicht macht, ist er vielleicht nicht der richtige Entwickler für die Position.

Es ist schwer, Kritik zu vertragen, wenn es „dein Baby“ ist, aber wenn man es unter dem Gesichtspunkt betrachtet, dass wenn das System gut ist, dann hat jeder einen Job und verdient Geld, dann sieht man, dass die Entwickler alle Druck machen dieselbe Richtung (wenn nicht, stellen Sie sicher, dass es die Ausgangstür ist, gegen die sie drücken). Selbst wenn Ihre gesamte Codebasis neu geschrieben wird, sind Sie immer noch die Person, die die erste Version geschrieben hat.

Ich bezweifle, dass sich das Klima verbessern würde, wenn Sie sagen würden, dass Sie diese Kritik persönlich nehmen und Sie möchten, dass sie aufhört, oder wenn Sie die Angelegenheit eskalieren würden. Sie könnten erreichen, dass sie aufhören, offen zu kritisieren, aber das wird nichts an ihrer Meinung ändern und Ihrer Beziehung als Kollegen schaden.

Die Arbeit des anderen Entwicklers zu kritisieren, gehört ganz und gar zur Entwicklerkultur, und Sie müssen damit klarkommen, dass dies nicht immer konstruktiv oder mit dem größten Fingerspitzengefühl geschieht. Wenn ihnen das Verständnis fehlt, könnten Sie ihnen erklären, warum Sie solche Opfer gebracht haben. Indem Sie sie an die hohen Sterblichkeitsraten von Startups erinnern, könnten Sie ihnen helfen, zu erkennen, dass es Dinge gibt, die über die Codequalität hinausgehen, wie z. B. Gelddruck, die sehr real sind.

Als praktischer Ratschlag versuchen Sie, sich von Ihrer Arbeit zu distanzieren und Bemerkungen auf die leichte Schulter zu nehmen, solange nichts über Ihre Professionalität impliziert wird. Wenn Sie das Gefühl haben, dass sie negativ werden, können Sie versuchen, sie in Richtung Positivität zu führen, indem Sie die Bemerkung „xxx-Code riecht“ mit „wir/Sie werden die Chance haben, das am JJJ-Datum zu verbessern“ beantworten.

Sie können darüber hinwegkommen. Dieser Code, den sie kritisieren, ist derselbe Code, der die Möglichkeit eröffnet hat, dass zusätzliche Entwickler eingestellt werden mussten (auch bekannt als sie). Ohne sie gibt es keinen Grund für sie, dort zu sein.

Kurzgeschichte ist, dass Entwickler da sind, um den Code zu verbessern (dieselbe Geschichte überall sonst). Wenn es etwas nicht tut, was es tun sollte, Code dafür zu erstellen. Wenn es kaputt ist, um es zu reparieren. Wenn sie lange genug warten, werden sie dort Code einfügen, den andere kritisieren können.

Stimme der Antwort von @PeteCon zu.

Möglicherweise wechseln Sie in einen defensiven Modus, da dies Ihr Code ist und in gewisser Weise Ihre Fähigkeiten widerspiegelt. Du sagst, es gibt keine Rücksicht auf die Zwänge, mit denen du zum Zeitpunkt des Schreibens konfrontiert warst, aber das spielt eigentlich keine Rolle. Schlechter Code ist schlechter Code. Wenn Sie etwas funktionsfähiges, aber nicht wartbares erstellt haben, müssen Sie es umgestalten. Das bedeutet nicht, dass es keine Errungenschaft war, in kurzer Zeit etwas herauszubringen, das funktioniert.

Wie in der anderen Antwort erwähnt, müssen Sie aufhören, Vollzeit zu programmieren und in die Verwaltung von Ressourcen übergehen. Außerdem stimme ich Ihnen nicht zu, wenn Sie denken, dass Ihre Entwickler, die an streng getrennten Teilen Ihrer Codebasis arbeiten, eine gute Sache sind - das ist es nicht! Wenn Sie Dinge wie Codeüberprüfungen effektiv übernehmen möchten, bei denen Entwickler damit beginnen können, die Zusammenführungsanfragen der anderen zu überprüfen, sollten sie mit der Codebasis, die sie überprüfen, vertraut sein. Außerdem schaffen Sie Wissensinseln und wenn einer Ihrer Entwickler schließlich geht, wird niemand mehr verstehen, wie ihre Implementierungen funktionieren, weil niemand mit ihrem Teil der Codebasis gearbeitet hat und niemand Qualität, Lesbarkeit und Dokumentation ihres Codes sichergestellt hat über Überprüfung.

Ich möchte eine Erfahrung teilen, weil sie deiner Geschichte sehr ähnlich klingt.

Die Geschichte der technischen Schulden

Damals bin ich einem Tech-Startup beigetreten. Es war mein zweiter Teilzeit-IT-Job, ich war damals noch Student. Das Team war großartig und ich mochte meine Aufgaben, aber es gab einige organisatorische Probleme.

Der leitende Entwickler war einer der größten und erfahrensten Personen, mit denen ich je zusammengearbeitet habe. Sehr kompetent, sehr kenntnisreich. Ihre Projekte waren auch ihr Baby. Ich vermute, sie hätten eine viel bessere Position mit einem viel viel höheren Gehalt einnehmen können, aber sie liebten ihr Projekt und sind meines Wissens bis heute dort geblieben. Es wurde auch mit erstaunlicher Geschwindigkeit herausgepumpt, schneller als ich es hätte tun können, aber es kam mit einer Menge technischer Schulden.

Im Laufe der Zeit schlossen sich mehr Studenten und Nicht-Studenten den Reihen der Entwickler an, aber der Lead arbeitete weiter an der Codebasis, weil sie das gerne taten, und das verstehe ich. Aber mit immer mehr Projekten fingen sie einfach an zu brennen. Später und später abends versuchen, dies zu beenden, versuchen, das zu beenden, Server am Wochenende, im Urlaub, während des Krankenstands zu programmieren und zu warten und so weiter.

In der Zwischenzeit gab es in der Unternehmensrichtlinie keine Überprüfungs- oder Testprotokolle. Mehrere Entwickler, darunter auch ich selbst, baten den Leiter um weniger Codierung und mehr Verwaltung, weil wir eine ordnungsgemäße Versionierungsstruktur, eine ordnungsgemäße Repository-Organisation und so weiter brauchten, aber das kam einfach nicht zustande. Sie haben uns das wirklich versprochen, waren aber immer zu überlastet mit Arbeit, um DevOps zu machen.

Und so entwickelten sich zwei Dinge. Eine Sache waren Inseln. Ich habe mein Projekt, das eine große Einnahmequelle für das Unternehmen darstellte, als Student allein geführt. Ich kannte alle geheimen Pfade, alle Feinheiten des Codes, aber ich hatte nicht genug Zeit, um alles zu tun, was verlangt wurde. Funktionen herausgepumpt, versucht, eine Organisation im Repository zu finden, Kundensupport geleistet und immer wieder Brände gelöscht. Die zweite Sache – unsere Codebasis hat sich verschlechtert. Niemand hat meinen Code überprüft, niemand konnte es irgendwann, es gab null Zeit für Dokumentation und immer Ad-hoc-Patchwork.

Das galt auch für andere Kollegen.

Also verlangsamte sich alles in Bezug auf die Feature-Entwicklung bei allen außer den neuesten Projekten immer mehr , weil immer mehr technische Schulden ihren Tribut forderten und wir unter ständigem Druck des Managements standen. Psychischer Druck. Ich habe einmal einen Kollegen beim Weinen im Badezimmer erwischt, ein bisschen mit ihm geredet, festgestellt, dass ich seit fast einem Jahr meinen Stress auf meine Familie und meinen Partner ablade – und entschieden, dass es Zeit ist zu gehen.

Bis heute schäme ich mich, diese Codebasis in einem so chaotischen Zustand zurückzulassen, weil ich viel daran gearbeitet habe, viel davon ist Zeug, das ich hineingesteckt habe. Aber wenn Sie jemals nur Patchwork, Quick and Dirty-Sachen und so weiter machen , dann wird Ihr Code zu einem unwiederbringlichen Durcheinander. Als ich aufhörte, gingen auch ein paar andere Leute. Zwei weitere Inseln. Niemand war jemals mit ihren Codebasen vertraut, außer dem Lead bis zu einem gewissen Grad.

Das Fazit dieser Geschichte – diese Projekte sind größtenteils tot. Das Unternehmen verdient immer noch Geld damit, aber es gab keine Weiterentwicklung, außer einigen Dingen, die sich möglicherweise in der Führung geändert haben. Die Stellen blieben unbesetzt, neu eingestellte Entwickler waren offenbar nicht in der Lage, die jeweiligen Codebasen weiter zu pflegen.

Jetzt arbeite ich in einem Unternehmen mit ordnungsgemäßen Codeüberprüfungen, Tests, automatisierten Pipelines, Prozessen ... es ist so gut. Sicher, wir haben unsere Spezialitäten in der Codebasis, aber es gibt praktisch überhaupt kein Inselwissen, außerdem gibt es Code-Reviews, also erreicht kein Code jemals den Master-Zweig, der nicht von jemand anderem gesehen wurde. Meine geistige Gesundheit in Bezug auf meinen Arbeitsplatz hat sich ebenfalls verbessert und meine Fähigkeiten sind jetzt auch viel besser.

Ich verstehe, dass es schwierig ist, mit Kritik an Ihrer Arbeit emotional umzugehen, aber Sie sollten Kritik als eine gute Sache ansehen, das bedeutet, dass Ihre Entwickler die Codebasis verbessern können, weil sie Dinge sehen, die anders sein könnten. Erstellen Sie keine Codebase-Inseln, denn Sie werden irgendwann Leute verlieren und versuchen nicht, alles selbst zu reparieren, Sie werden sich in die Intensivstation hineinarbeiten.

Um voranzukommen, schlage ich ein Strategiemeeting mit Ihnen und den anderen beiden Entwicklern vor. Ziel sollte es sein, die nächsten Phasen zu planen. Es gibt mindestens drei Dinge, die abgedeckt werden müssen:

1. Alle neuen Funktionen, die benötigt werden.
2. Cross-Training.
3. Den frühen Quick-Out-Code auf volle Produktionsqualität bringen.

Die Themen sollten beinhalten, wie man die Arbeit an diesen Zielen ausbalanciert, welches Test- und Dokumentationsniveau in der nächsten Entwicklungsrunde anzustreben ist und wie man dorthin gelangt. Wenn einer von ihnen anfängt, über die Mängel des frühen Codes zu sprechen, kehren Sie zur Planung dessen zurück, was zu tun ist.

Wieso interessiert dich das überhaupt?!
Sie können alles kritisieren, was sie wollen, solange sie auch gute, gültige Korrekturen veröffentlichen.
Wie andere sagten, ist der Code, den sie reparieren, das Geld, um sie überhaupt einzustellen.
Vielleicht möchten Sie sie daran erinnern. Täglich.

Im Ernst, lass sie sich aus vollem Herzen beschweren, seitenlange Commit-Nachrichten schreiben, den ganzen Kram.
Stellen Sie einfach sicher, dass sie als ihr technischer Gutachter gute Arbeit leisten, indem sie Ihre alte Codebasis übernehmen und sie verbessern.

Die einzige Ausnahme ist, wenn sie mit ihrer Kritik frech und/oder schlicht unhöflich werden. Es ist eine Sache zu denken „Oh Junge, dieser Code ist scheiße!“, und eine andere Sache, es in genau diesen Worten auszudrücken.
In diesem Fall feuern Sie ihnen auf der Stelle den Arsch ab.
Aber ansonsten... Alter, du hast den Prototyp gebaut. Sie sind „der Woz“ Ihres Unternehmens.
Warum kümmert es dich überhaupt, was sie denken?!

Bring sie zu einem kleinen Gespräch zusammen. Sagen Sie ihnen, wie es ist: Sie haben diesen Code schnell zusammengestellt , um das Unternehmen an einen Punkt zu bringen, an dem es Mittel erhält, die zur Zahlung ihrer Gehälter verwendet werden. Ohne den Code, über den sie sich beschweren, würden sie dort nicht arbeiten.

Sag ihnen: Wenn es dir nicht gefällt, repariere es. Ruhig. Ohne sich bei mir zu beschweren.

PS. Wenn sie "Korrekturen" anstelle von Korrekturen produzieren, dann ist eine große Abmahnung angebracht. Wenn Sie Ihre Arbeit durch Backlogs organisieren, müssen Sie alles tun, ohne dass es im Backlog ist. JEDOCH ist es absolut angemessen und bewährte Methode, wenn Sie eine Aufgabe ausführen, um den damit verbundenen Code zu verbessern.