Zwei Strategien

1. Sokratisch . Sprechen Sie mit Ihrem Kollegen über den Code und bitten Sie ihn um Erklärungen zu den verwirrenden Teilen. Sie müssen sich taktvoll "dumm stellen", was ohnehin eine notwendige Fähigkeit für einen guten Programmierer ist. Stellen Sie Fragen, die Selbstoffenbarung hervorrufen, wie „Ist das eine schnelle Art, Unterabfragen durchzuführen?“, „Wie behalten Sie den Überblick über all diese kurzen und ähnlichen Variablennamen?“, „Können wir eine Hilfsfunktion verwenden, um diese drei zu ersetzen Teile wiederholen?" usw. Der Trick besteht darin, ihnen vorzumachen, sie hätten eine Idee, wie man es besser machen könnte, was Sie dann mit Äußerungen wie "Ja, das wäre wirklich schön/schnell/klar" belohnen.

2. Humor . Kritik kann sich hinter Sarkasmus und Witzen verstecken. Dumme Namen und Analogien sind Kupplung. „Können Sie diesen Variablen aussagekräftigere Namen geben, wir sind nicht alle Johnny Mnemonic wie Sie“, „Ist Ihre Tabulatortaste kaputt?“, „Holy Repetition Batman!“ usw. Wenn Sie offensichtlich scherzen, können Sie das einfacher mit Kritik durchkommen, solange sie ziemlich indirekt ist. Mischen Sie auch etwas Selbstironie ein, z. B.: „Oh, ich hasse diese Art von Adapterroutinen, sie haben mich immer wie einen Noob aussehen lassen, wenn diese komplizierte Verschachtelung eine unbehandelte Ausnahme hatte, also glätte ich jetzt die Warteschlange, bevor ich sie gebe Rückruf durch...". Stellen Sie sicher, dass Sie dies nicht vor anderen Arbeitern ausprobieren, da dies mit den sozialen Aspekten zusätzlich zum ankommenden Futter einschüchternd sein könnte.

Egal wie leise Sie die schlechten Nachrichten überbringen, erwarten Sie eine gewisse Abwehrhaltung und Gegenreaktion. Programmierer sind unsicher, weil sich ihre ganze Arbeit darauf konzentriert, Entscheidungen zu treffen, also setzen sie sich hundert- bis tausendmal in die Entwicklung einer bestimmten Anwendung ein. Sei freundlich und versöhnlich und bereit, Dinge wie „Nicht das Ende der Welt“, „Ich habe Schlimmeres gesehen“ und so weiter anzubieten, falls nötig.

Warten Sie auf einen weiteren Fehler. Nach Ihrer Geschichte wird es passieren. Dann bitten Sie ihn um Hilfe, bitten Sie ihn zu erklären, was er getan hat, wie und warum, weil Sie den Fehler nicht verstehen.

Erkläre dann deine Meinung und zeige ihm, was er deiner Meinung nach hätte tun sollen. Tun Sie es mit Respekt und vergessen Sie nicht, dass der Codestil persönlich ist, und weil Sie es anders gemacht hätten, bedeutet das nicht, dass Ihr Weg besser ist (selbst wenn er es ist, wird er das nicht glauben).

Fragen Sie, ob Sie für kurze Zeit mit ihnen arbeiten können. Sie möchten ihnen etwas zeigen, mit dem Sie Schwierigkeiten haben, und mit ihnen und ihrem Code arbeiten, damit Sie gemeinsam zu einer Lösung kommen. (Mit anderen Worten, Sie kritisieren ihren Code nicht im Voraus, sondern bitten sie um Hilfe.)

Machen Sie dann Paarprogrammierung, zeigen Sie ihnen, was Sie tun müssen, und wenn Sie auf einen ihrer Codes treffen, der Ihnen Schmerzen bereitet, erklären Sie die Schmerzen. Sagen Sie ihnen, was Ihrer Meinung nach eine gute Lösung wäre, und fragen Sie, ob sie Gründe dafür sehen, warum Ihre Lösung Probleme hat.

Gehen Sie dies als Teamproblem an, das es zu lösen gilt, und nicht als etwas, bei dem Sie die Lösung haben, sondern bei dem Sie ihre Hilfe benötigen, um zu einer Lösung zu kommen, mit der Sie beide leben können. Seien Sie offen für Gründe, warum sie so codieren, wie sie es tun, was es ihnen leichter macht, offen für Ihre Probleme zu sein.

Am Ende können sie sich ändern. Oder Sie können sich ändern. Oder vielleicht ändert sich nichts. Aber Sie werden besser kommunizieren (vorausgesetzt, Sie hören ihnen immer zu), und es wird einfacher sein, Vorschläge zu machen und zusammenzuarbeiten, wenn Sie dies zuvor getan haben.

Eine Sache, die Sie im Hinterkopf behalten sollten: Nur weil Sie in einer großen Organisation sind, die Dinge nur langsam annimmt, heißt das nicht, dass Ihr Team auch nur langsam ankommen muss. Ich arbeite in einer großen Organisation, die keine formellen Code-Reviews hat (und wahrscheinlich noch einige Jahre lang nicht tun wird) ... aber ich habe es geschafft, unseren Chef davon zu überzeugen, Code-Reviews nur für unser Team durchzuführen. Vielleicht möchten Sie mit Ihrem Chef sprechen, um zu sehen, ob Sie einen provisorischen Überprüfungsprozess nur für Ihren Bereich einrichten können?

Was die Handhabung der Dinge jetzt angeht? Der erste Schritt besteht darin, sich ein Bild davon zu machen, wie der Kollege Kritik interpretieren wird. Ich habe einen Kollegen, der Veränderungen rundweg ablehnt. Und ich mache mir nicht die Mühe, ihm Code-Feedback zu schicken - es wäre völlig sinnlos. Aber ein anderer meiner Kollegen liebt es, seine Fähigkeiten zu verbessern, und ich würde nicht zögern.

Hier ist auch meine allgemeine Empfehlung: Machen Sie es zwanglos und schließen Sie die guten Dinge ein, die Ihnen aufgefallen sind (denken Sie daran, positives Feedback ist wichtiger als negatives Feedback; Sie würden es hassen, wenn sie aufhören würden , die guten Dinge zu tun, oder?) Hier ist zum Beispiel eine E-Mail, die ich diesem zweiten Kollegen senden könnte.

John,

Hallo - Ich habe ein bisschen nach Fehlern gesucht und ein paar Dinge in Something.cs gefunden

Erstens sind Ihre Funktionsnamen großartig – sie haben mir genau mitgeteilt, was sie tun, und es hat meine Zeit für die Fehlersuche um einiges verkürzt. Dasselbe gilt für die Variablennamen.

Aber mir ist aufgefallen, dass Sie eine Schleife in der Funktion GetPermissions() haben, die nicht korrekt beendet wird, wenn der Benutzer auf VPN ist. Könnten Sie sich ansehen, wie Sie diese while()-Schleife geschrieben haben, insbesondere den Teil, in dem sie bei einigen Bedingungen zurückkehrt, anstatt zu brechen? Vielleicht wird der Schleifencode kompliziert genug, um es zu rechtfertigen, ihn in seine eigene Funktion zu zerlegen?

- Kevin

Bleiben Sie objektiv und urteilsfrei

Stellen Sie sich nicht dumm, versuchen Sie nicht, Humor zu verwenden, diskutieren Sie einfach die objektiven Fakten, ohne irgendeine Art von Urteil abzugeben.

Wenn es um einen Fehler geht, den Sie beheben, so etwas wie

Hey X, ich habe nach der Lösung für Fehler Nr. 123 gesucht und ich glaube, ich habe sie gefunden. Würde es dir etwas ausmachen, sie uns gemeinsam anzusehen?

Wenn die Antwort eine Variante von "Ich will nicht" ist, lassen Sie es in Ruhe und hoffen, dass bald formelle Code-Review-Praktiken eingeführt werden.

Wenn die Antwort bejahend ist, besprechen Sie einfach die Fakten noch einmal ohne jegliches Urteil:

Wenn ich diesen Code richtig gelesen habe, täuschen wir hier die Bar, indem wir das Summen zischen. Ich denke, wenn der foo X und der Balken Y ist, könnte dies zu dem Ergebnis führen, das wir im Fehler sehen. Sind Sie einverstanden?

Das hält die Sache offen. Die Antwort könnte sein, dass Sie tatsächlich falsch gedacht haben und die Ursache des Fehlers nicht gefunden haben, oder dass die Dinge komplizierter sind, als Sie dachten. Es macht es auch für die andere Partei wirklich einfach, Ihnen zuzustimmen und über die Lösung zu sprechen, anstatt sich mit dem Problem zu beschäftigen.

Bei allgemeinen Codeproblemen ist die Vorlage ähnlich.

Hey X, ich habe an Feature #123 gearbeitet und bin auf den Code für Y gestoßen. Würde es dir etwas ausmachen, wenn wir uns das zusammen anschauen?

und

Im Moment täuschen wir die Bar, indem wir für Aufregung sorgen. Ich mache mir Sorgen, dass [Bedenken hier einfügen], denkst du, es wäre besser, wenn wir stattdessen den Blurble nähren?

Wenn der Unterschied zwischen Ihrer Lösung und ihrer Lösung nur stilistischer Natur ist, es keine vereinbarten Codestilrichtlinien gibt, gegen die die aktuelle Lösung verstößt, und die aktuelle Lösung keine Probleme verursacht, lassen Sie es einfach. Das bedeutet nicht, dass Sie es immer loslassen sollten, wenn der Code schwer lesbar ist. „Ich hatte Probleme, diesen Code zu interpretieren, ich mache mir Sorgen, dass dies in Zukunft während der Wartung zu einem Problem wird“ ist eine berechtigte Sorge.

Arbeiten Sie mit Ihrem Vorgesetzten zusammen, um einen formellen Prozess zur Überprüfung des Codes einzurichten . Es gibt viele kostenlose Softwareanwendungen, oder Sie können es als Teil des Pull-Request-Prozesses erstellen, wenn Sie git verwenden.

Seien Sie bei einer Codeüberprüfung nicht pedantisch . Kümmern Sie sich nicht um kleine, triviale Details wie Leerzeichen oder Ausrichtung. Sie sollten einen automatischen Codeformatierer verwenden, der ausgelöst wird, wenn der Code in der ID oder als Teil eines Precommit-Hooks gespeichert wird. Dazu gehören auch Linters mit automatischen Korrekturen (wenn Sie beispielsweise gemischte Anführungszeichen verwenden, sollten sie alle automatisch in denselben Typ konvertiert werden. Reduzieren Sie den Stress für Ihre Entwickler, sich alles zu merken).

Ermutigen Sie Ihr Team, mehr Peer-Programmierung oder "beobachtete" Code-Sitzungen durchzuführen. Man kann viel lernen, indem man einfach beobachtet, wie einige das Terminal verwenden, wie neue Befehle und Techniken. Erlaube ihnen, dich zu unterbrechen und Fragen zu stellen wie „Was ist Joe“ oder wie hast du es geschafft, dass dein Git-Log das anzeigt?

Nehmen Sie dies zum Anlass, gemeinsam einen kritischen Denkprozess zu durchlaufen. Als würde man die Schritte durchgehen, die man durchläuft, um ein Problem zu lösen.

Seien Sie nicht herablassend : Die meisten Entwickler haben bereits das Hochstapler-Syndrom, sie zu beschimpfen und herabzusetzen verstärkt es nur und demotiviert Ihren Kollegen.

Feiern Sie die kleinen Siege : Es mag dumm oder unverdient klingen, aber machen Sie Ihren Kollegen regelmäßig Komplimente für kleine Erfolge und erkennen Sie an, wie wichtig sie im Team sind. Sie sagen vielleicht: „Aber ich mache Menschen nur dann Komplimente, wenn sie es wirklich verdienen, oder die Leute denken, es sei falsch.“ Zahlreiche Studien zur Managementtheorie zeigen das Gegenteil, die Produktivität steigt und die Menschen gehen noch einen Schritt weiter, um Ihre Anforderungen zu erfüllen.

Denken Sie wie ein Mentor, nicht wie ein Lehrer. Denken Sie darüber nach, wie wir diesen Kollegen wie ein Team mit diesem Mitglied verbessern können. Seien Sie bereit, eine Quelle für Informationen oder eine Referenz zu sein. Weisen Sie sie auf die Zeilennummer der Dokumentation hin, die sie sich ansehen sollten. Zeigen Sie ihnen, wie sie sich selbst beibringen können, besser zu werden (Blogs, die Sie lesen, reddit-Beiträge teilen, Tutorial-Videos oder O'reilly-Bücher, die Sie wirklich lesenswert fanden). Es mag pedantisch erscheinen, aber setzen Sie sich mit ihnen zusammen und zeigen Sie ihnen geduldig, wie Sie Ihren Denkprozess zum Googeln von Problemen durchlaufen. Starten Sie eine büroweite „Liste der besten Programmierbücher“ und bringen Sie Ihren Manager dazu, sie zu kaufen und in einer Bürobibliothek zu haben. Definieren Sie klare Kodierungspraktiken, an die sich Ihr Büro hält.

Wenn alles andere fehlschlägt, suchen Sie sich einen neuen Job. Vielleicht ist es ein Spiegelbild Ihres Arbeitsumfelds und dass Sie ihm entwachsen sind und vielleicht Zeit für Sie, sich nach neuen Arbeiten umzusehen. Wenn Sie das Gefühl haben, die klügste Person im Raum zu sein, ist es an der Zeit, einen neuen Raum zu finden.