Wie geht man damit um, dass ein Entwickler defensiv wird, wenn er mit brechendem Code konfrontiert wird?

"Hey, Sie haben diese X-Änderung an dieser Y-Funktion vorgenommen. Diese Änderung macht meinen Code kaputt, weil er Z nicht berücksichtigt, und Z ist das, was auf meiner Seite passiert. Ist es für Sie in Ordnung, K zu tun, um das Problem zu beheben?"

Sie müssen dies weniger persönlich machen. Es gibt keinen Mein Code und Ihren Code . Sie beide sind Mitarbeiter eines Unternehmens, und dieses Unternehmen besitzt den Code. Sie haben es lediglich geschrieben, aber geistiges Eigentum an Ihren Arbeitgeber weitergegeben. Eigenverantwortung zu übernehmen ist wichtig, aber sprechen Sie nicht so darüber.

Stellen Sie sich stattdessen den gesamten Code als unseren Code vor und formulieren Sie ihn so. Oder lass es weg. Wenn Sie sich nicht darauf konzentrieren, was sie getan haben, sondern auf den aktuellen Stand, wird es sich viel weniger wie ein persönlicher Angriff anfühlen.

Als Ergebnis der Änderung von X zu Y brach diese andere Funktionalität zusammen. Ich habe es mir angeschaut und gesehen, dass wir auch an Z denken müssen.

Sie können dann sehen, was sie sagen. Sie könnten mit etwas wie „Zeig es mir“ oder „Mach weiter und repariere es“ oder „Oh, daran habe ich nicht gedacht“ antworten und anbieten, es selbst zu reparieren.

Im Idealfall ist es aber egal, wer das Problem behebt. Es ist wichtig, dass es einen Dialog gibt und alle zusammenarbeiten, um das Gesamtprodukt stabil und funktionsfähig zu machen. Es ist an sich schon gefährlich , nur eine Person für einen bestimmten Teil des Produkts verantwortlich zu haben, und diese Art von Situation ist eine gute Chance, um sicherzustellen, dass jeder die anderen Teile des Produkts kennt.

Technisch gesehen klingt es so, als ob Sie wirklich Unit-Tests oder eine andere Form des automatisierten Testens für mindestens diese bestimmte Software wollen. Wenn es eine allgemeine Infrastruktur gibt, die sie ausführt und die Ergebnisse anzeigt, ist es offensichtlich, wenn etwas (nicht jemand (!), obwohl es natürlich einen gibt git blame) die Tests gebrochen hat. Sie sind als Sicherheitsnetz da und damit jeder es merkt, wenn etwas schief geht.

Ein zusätzlicher Vorteil von Komponententests für kritische Teile des Systems besteht darin, dass Sie nicht wirklich hingehen und darauf hinweisen müssen, dass Dinge kaputt sind. Es gibt keinen Code-Polizisten mehr. Wenn sich die Toolkette darum kümmert, überbringt niemand schlechte Nachrichten und es gibt weniger schlechte Stimmung im Team, da es weniger Raum zum Streiten gibt.

Andererseits müssen auch die Tests aktualisiert werden. Über die Vor- und Nachteile zu diskutieren, würde hier den Rahmen sprengen.

Das Wichtigste zuerst: Es ist nicht ungewöhnlich, dass Abhängigkeitscode Downstream-Code beschädigt. Es gibt Entwicklungsmethoden, die dies abmildern können, wie z. B. gute Spezifikation, Dokumentation und Tests. Aber das ist nicht die Antwort auf deine Frage.

Hey, du hast diese X-Änderung an dieser Y-Funktion vorgenommen. Diese Änderung bricht meinen Code, weil sie Z nicht berücksichtigt, und Z ist das, was auf meiner Seite passiert. Ist es in Ordnung für dich, K zu machen, um es zu beheben?

Was Sie sagen, kann als Anschuldigung rüberkommen – Sie sagen im Grunde „Sie haben meinen Kodex gebrochen“ – und das wird die Leute in die Defensive treiben.

Ein besserer Weg ist, dies weniger "Sie haben meinen Code gebrochen" und mehr "Würde es Ihnen etwas ausmachen, sich X noch einmal anzusehen? Ich denke, es muss K tun, um mit Z zu arbeiten" zu halten.

Andererseits, wenn diese Person ein Mürrer ist, egal wie Sie auf sie zugehen, müssen Sie Ihren Chef wissen lassen, dass Ihre Arbeit verzögert wird, weil Sie die Arbeit des Mürrers reparieren müssen. Zeigen Sie auch hier nicht mit dem Finger, sondern belassen Sie es bei "Die Arbeit an Z wurde durch Änderungen in X verzögert und ich musste zuerst K erledigen".

Dies ist tatsächlich eine großartige Gelegenheit in der Verkleidung. Die meisten Ingenieure wissen nicht, wie groß dies für einen aktuellen oder potenziellen Arbeitgeber ist. Auf Augenhöhe mit technischen Fähigkeiten ist Ihre Fähigkeit, mit Menschen zusammenzuarbeiten, Verantwortung für Fehler zu übernehmen, mit anderen durch ihre eigenen zu arbeiten und Ihre Gedanken taktvoll zu vertreten. Der allgemeine Konsens ist, dass dies am besten durch das Teilen einer anekdotischen Geschichte in einem Interview demonstriert wird. normalerweise basteln Leute solche Geschichten im Nachhinein zusammen, aber Sie könnten sehr strategisch sein und erkennen, dass Sie hier die Möglichkeit haben, eine großartige Geschichte zu schreiben, die Fragen wie „Wie gehen Sie mit Konflikten um?“ beantworten und wahrscheinlich überraschende Möglichkeiten bei Ihrem derzeitigen Arbeitgeber eröffnen würde .

Etwas, das Sie dann berücksichtigen sollten, ist Ihre Taktik vs. Strategie .

Taktik

Ihre Taktiken sind die Systeme und Aktionen, die Sie wählen, um bei Ihrem Problem zu helfen. Wählen Sie zum Beispiel eine bessere Formulierung, die weniger persönlich ist, wählen Sie den richtigen Zeitpunkt, achten Sie auf das Publikum/Zuschauer, helfen Sie der Person, die Sie ansprechen, oder verwenden Sie automatisierte Tests, um den Fehler zu finden. Verbringen Sie Zeit damit, gute Taktiken zu lernen und zu üben. Dies wird Ihre Toolbox sein, die Sie für Ihre Strategie nutzen können.

Strategie

Das Problem, mit dem Sie konfrontiert sind, ist symptomatisch für ein noch größeres Problem: Diese Person mag Sie nicht wirklich. Das wollen Sie strategisch beheben.

Am Arbeitsplatz, insbesondere in einem Team, liegt es außerhalb Ihrer Kontrolle, dass Sie eine persönliche Beziehung zu jedem einzelnen Ihrer Teamkollegen haben. Vielleicht mag dich jemand nicht und du magst ihn nicht, schade, du wirst in eine Beziehung gezwungen, weil du in einem Team bist. Es ist Ihre Entscheidung, ob diese Beziehungen gut oder schlecht sind. Sie können wählen, ob Sie sich um andere Menschen bemühen möchten oder nicht. Wirkliches berufliches Wachstum entsteht, wenn Sie sich nicht nur als Code-Cruncher (was zu Code-Arroganz-Problemen führt), sondern als funktionierendes Mitglied eines Teams sehen, und Sie wollen zeigen, dass dieses Team mit Ihnen in einem Team ist größer als die Summe seiner Teile. Das bedeutet großes Beziehungsbewusstsein.

Die strategische Entscheidung besteht darin, sich zu fragen, wie diese Beziehung aussehen soll. Ist es möglich? Was fehlt oder welche Herausforderungen könnten die Beziehung behindern? Was müssen Sie tun, um das zu erreichen? Zum Beispiel sind viele Beziehungsprobleme auf Vertrauen zurückzuführen. Eine Strategie wäre also, diesem Entwickler zu zeigen, dass Sie an seine/ihre Interessen denken und nicht nur an Ihre eigenen, und Ihre Beziehung an den Punkt zu bringen, an dem diese Person Ihnen vertraut. Seien Sie kein stoischer Besserwisser, das bringt die Leute nicht auf Ihre Seite, auch wenn Sie Recht und Berechtigung haben. Die Strategie besteht darin, zu erkennen, dass Sie Menschen auf Ihrer Seite haben möchten, und darüber nachzudenken, wie dies geschieht. Was funktioniert und was nicht. Es ist auch wichtig zu erkennen, dass eine erfolgreiche Strategie oft Geduld erfordert.

Das Coole daran ist, dass, wenn Sie eine wirklich solide Beziehung zu diesem Senior-Entwickler aufbauen, die Taktiken, die Sie dorthin gebracht haben, viel weniger notwendig werden und es einfacher ist, effizienter und erfolgreicher in Ihrem Job zu sein. Eine gute Strategie kann Sie zu einer guten Beziehung führen, und mit einer guten Beziehung werden Sie es viel einfacher finden, Ihre Ziele zu erreichen. Denken Sie also daran, an Ihrer Beziehung zu dieser Person zu arbeiten, wenn es kein Problem gibt, und das wird es einfacher machen, wenn solche Probleme auftauchen.

Wie soll ich ihm mitteilen, dass ich mit guten Mitteln komme, ihm aber auch verständlich machen (und zustimmen), dass er derjenige ist, der die erforderlichen Änderungen vornehmen sollte, um den defekten Code/das defekte Modul zu reparieren?

Stellen Sie besser sicher, dass Ihr Chef/Team zustimmt, dass dies so gehandhabt werden sollte. Idealerweise gibt es in einer Codierungsumgebung eine Art automatisiertes Testsystem. Wenn also versucht wird, Code einzuchecken, wird er abgelehnt, bis er behoben ist. Normalerweise ist dies die Person, die es geändert hat. Jeder sollte stolz auf seine Arbeit sein, die mit einem Maß an Verantwortung einhergeht, um Dinge reparieren zu wollen, die er kaputt macht.

Ihr Chef hält es möglicherweise für Verschwendung, wenn die Zeit der erfahrenen Entwickler jeden kleinen Fehler beheben muss, den sie in das System einführen. Sie denken, dass diese Aufgabe jungen Entwicklern überlassen wird; Ich bin damit nicht einverstanden. Wie das funktionieren soll, musst du selbst herausfinden.

Meine Herangehensweise an diese Art von Problem besteht darin, sicherzustellen, dass ausreichende Methoden und Werkzeuge vorhanden sind, um das Problem technisch und nicht persönlich zu behandeln.

Stellen Sie beispielsweise sicher, dass Sie über automatisierte Builds und Rauchtests verfügen. Wenn diese kaputt gehen, haben Sie eine Regel, dass der Brecher beim nächsten Teammeeting für Essen sorgen muss.

Manchmal stellen Menschen den Status quo mutig in Frage, in einem selbstsüchtigen Streben nach persönlichem Fortschritt. In gewisser Weise ist das normal. Es ist bestenfalls unternehmerisch. Das Individuum bewegt sich in einem Rahmen vorwärts, der es zulässt. Ändern Sie also den Rahmen. Diese Arten von Menschen werden nicht ausgebremst, sie werden auf unterschiedliche Weise Fortschritte machen. Als Führungskraft ist es Ihr Ziel, diesen Geist zu nutzen und ihn positiv für das Team und die Ziele zu lenken.

Ein Teil dieser Strategie, den Willen zu nutzen, besteht darin, sicherzustellen, dass die Menschen immer noch ein Gefühl der Eigenverantwortung haben. Die populärste Antwort hier bisher plädiert für eine Philosophie des Eigentumsverzichts. Ich denke, das kann kontraproduktiv sein. Lassen Sie Menschen ihren Bereich leidenschaftlich besitzen. Aber stellen Sie sicher, dass sie andere nicht betreten.

Diese Frage hängt wahrscheinlich stark von der Kultur des Unternehmens ab.

Es gibt Unternehmen, in denen "Fehler nicht passieren". Oder besser gesagt, Sie dürfen nicht darüber sprechen, und ein Manager, der jemanden kennenlernt, der einen Fehler gemacht hat, wird "diese Person genau beobachten".

In dieser Situation legen Sie das Problem dieser Person persönlich so offen, dass der Vorgesetzte nur dann davon erfährt, wenn es absolut notwendig ist, und sagen ihm genau, was er tun oder beheben soll, nachdem Sie versucht haben, es selbst zu beheben. (Natürlich solltest du auch rennen, rote Fahnen yada yada.) Du solltest ihnen auch sagen, dass es zwischen dir und ihnen ist und dass du cool bist.

In jedem funktionierenden Unternehmen müssen Sie sicherstellen, dass Ihre Offenlegung nicht wie eine Anschuldigung klingt.

Sie müssen immer noch sicherstellen, dass Sie ihnen genau sagen, was Sie von ihnen wollen und warum Sie es nicht selbst tun können (denn wenn Sie es reparieren können, warum beschweren Sie sich dann, beheben Sie es schnell und machen Sie weiter, sie haben es nicht getan nicht um Arbeit für Sie zu schaffen, sie mussten ihr eigenes Problem lösen).

Stellen Sie außerdem sicher, dass ihr Vorgesetzter oder Projektleiter davon Kenntnis hat und ihm sein Okay gegeben hat, das Problem zu beheben.

Sie können nicht entscheiden, was sie mit ihrer eigenen Zeit anfangen sollen, und bekommen von ihrem Vorgesetzten/Projektleiter Arbeit zugewiesen.

Wenn Sie vorbeikommen und über einen Fehler in einem Ticket sprechen, der jetzt erledigt sein sollte, ohne diese Dinge vorher zu tun und sie direkt anzusprechen, wird dies Stress und den Eindruck erzeugen, dass Sie möchten, dass sie in einer Zeit arbeiten, in der sie etwas anderem zugewiesen sind oder in ihrer Freizeit.

Die meisten Konflikte oder Probleme mit Menschen sind auf zugrunde liegende Prozessprobleme zurückzuführen. Das ist hier sicherlich der Fall.

Sie, Ihre Kollegen, Ihr Unternehmen und am schlimmsten Ihre Endkunden sind alle Opfer von fehlerhaften Prozessen, die vorhanden sein sollten, um die Qualität und Integrität Ihres kombinierten Codes zu verwalten.

Aus dieser Perspektive zu denken und zu handeln ist der Schlüssel zur Lösung der zugrunde liegenden Qualitätsprobleme, die direkt zu den Problemen geführt haben, die Sie erleben. Es ist auch der Schlüssel, um Gemeinsamkeiten mit Ihren Kollegen zu finden (z. B. wird es Ihnen leicht fallen, sich auf die Prozessprobleme zu einigen, die Ihnen all die Schmerzen bereiten).

Obwohl Sie wahrscheinlich nur Ihre Arbeit erledigen und in Ihrer Karriere vorankommen möchten, werden Sie Ihre Arbeitsbeziehung mit denen beschädigen, die am besten in der Lage sind, Ihnen zu helfen, wenn Sie den Eindruck haben, dass Sie darauf bedacht sind, erfahreneren Kollegen einen Schritt voraus zu sein .

Mein Rat wäre, eine Lösung vorzuschlagen, entweder im Detail (z. B. als Pull Request) oder einen Überblick über den Gesamtansatz zu geben, den Sie als Lösung vorschlagen würden. Bringen Sie dies zu der Person, deren Code Sie für gebrochen halten, und fragen Sie nach ihrer Meinung. Und vor allem auf die Antwort hören .

Dies stellt den Kollegen, den Sie vielleicht gerade unterbrochen haben, vor eine Lösung statt vor ein Problem und damit zusätzliche Arbeit. Sie werden wahrscheinlich nicht nur etwas aus den Antworten lernen, die Sie erhalten, sondern Sie werden auch als hilfsbereit und teamfähig angesehen.

Wie andere vorgeschlagen haben, müssen Sie dies entpersonalisieren. Es sollte ein kollektives Eigentum an dem Code geben. Weniger "Du hast meine Änderungen kaputt gemacht!" und mehr wie "Wie können wir beide Änderungen dazu bringen, gut zusammenzuarbeiten?"

Sie sollten auch überlegen, ob es Spielraum gibt, die Kommunikation während der täglichen Standups zu verbessern (falls vorhanden - oder schlagen Sie vor, sie einzuführen, falls nicht), damit im Allgemeinen mehr Bewusstsein dafür besteht, woran die Menschen arbeiten, und daher weniger Konflikte möglich sind brechende Änderungen.

Es ist schwierig, bei Standups das richtige Maß an Details bereitzustellen, aber wenn Ihre Kollegen den breiten Bereich des Codes, in dem Sie arbeiten, nicht kennen, möchten Sie vielleicht etwas mehr Details angeben.

Noch etwas, das Sie im Hinterkopf behalten sollten - als jüngerer, aber weniger erfahrener Entwickler ist es durchaus möglich, dass Sie schneller programmieren können als Ihre erfahreneren Kollegen (ein jüngeres, schärferes Gehirn ist manchmal eine echte Bereicherung!), aber das sollten Sie auch anerkennen Ihre erfahreneren Kollegen haben einen Erfahrungsvorsprung und können aufgrund ihrer jahrelangen Erfahrung in ihrem Ansatz überlegter sein. Tatsächlich ähneln die meisten Entwicklungsprojekte eher Marathons als 100-Meter-Sprints. Die besten Teams schöpfen aus allen Erfahrungsstufen.

Wie soll ich ihm mitteilen, dass ich mit guten Absichten komme, ihm aber auch verständlich machen (und zustimmen), dass er derjenige ist, der die erforderlichen Änderungen vornehmen sollte, um den defekten Code/das defekte Modul zu reparieren?

Ich stimme vielem zu, was bereits gesagt wurde. Unterschiedliche Menschen interpretieren dieselbe Botschaft unterschiedlich, und was der eine als ganz normale, effektive Kommunikation empfindet, empfindet der andere als irritierend oder einschüchternd – aus welchen Gründen auch immer. Diese Person teilt wahrscheinlich (implizit) mit, dass sie Ihren Stil unangenehm findet. Probieren Sie beim nächsten Mal etwas anderes aus. Versuchen Sie, die Einstellung zu ändern – erwischen Sie ihn eher am Wasserbrunnen als an seinem Sitzplatz. Setzen Sie sich neben ihn, bevor Sie das Gespräch beginnen, anstatt über ihm zu stehen. Probieren Sie verschiedene Ansätze aus – verwenden Sie Ihren gesunden Menschenverstand.

Und noch eine Sache, die ich vorschlagen kann, versuchen Sie, Ihre Kommunikation mit ihm auszugleichen. Wenn er sensibel ist, wenn Sie auf seine Fehler hinweisen, finden Sie Gelegenheiten, ihm (aufrichtig) Komplimente für kluge Entwürfe oder eine effektive Ausführung zu machen – das hilft den meisten Menschen sehr.

Der einfachste Weg, damit umzugehen, ist, nicht damit umzugehen. Lassen Sie den Entwickler stattdessen mit einem fehlgeschlagenen Test argumentieren. Fragen Sie sie, wie der Code funktionieren soll, und bauen Sie dann einen Test darum herum. Geben Sie ihnen den Test und sagen Sie ihnen, dass er fehlschlägt.