Er hat Ihren Code falsch verstanden.

Sicherstellen, dass das Team Ihren Code richtig versteht, war in Ordnung.

Ihr Beispiel enthält einfache Fakten und wäre als Antwort in Ordnung gewesen.

Die beste Antwort wäre

"Eigentlich macht Z Y"

Prägnant, objektiv und präzise ohne persönlichen Kontext.

In professionellen Gesprächen Sie Halten Sie sich an objektive Fakten und etablierte Verfahren .

Sie lassen persönliche Kommentare oder Bemerkungen aus, zeigen mit den Fingern oder greifen persönlich an.

Wenn jemand einen offensichtlichen Fehler gemacht hat, dessen Sie sich sicher sind, oder der Ihren eigenen Code missverstanden hat, dürfen Sie ihn nicht nur auf respektvolle Weise korrigieren, sondern auch vermeiden, ihn mit anderen Personen in Verlegenheit zu bringen oder zu tadeln vorhanden.

Die Angabe objektiver Tatsachen ist keine passive Aggression, und jeder, der von ihnen beleidigt wird, ist unprofessiv sional.

Dies hängt von der Umgebung und der Beziehung ab, die Sie zu dem Kollegen haben, dessen Code Sie überprüfen (oder der Ihren Code überprüft). In einigen Ländern (Ländern, Teams, Arbeitsplätzen usw.) ist es nicht akzeptabel, direkt zu sein, selbst bei Codeüberprüfungen. in anderen wird es als dumm angesehen, zu indirekt zu sein. Sie müssen Ihren Stil an die Umgebung und die Personen anpassen, mit denen Sie arbeiten.

Ich habe beispielsweise in Umgebungen gearbeitet, in denen

X durch Y ersetzen, X nicht mach {was auch immer}.

war akzeptabel und Orte waren

Das sieht für mich sehr gut aus, aber ich glaube, du solltest hier Y verwenden, weil X. würde ...

klang zu direkt.

Ich arbeite derzeit mit einem Kollegen zusammen, der sehr stolz auf seine Arbeit ist, und das fühlt sich selbst durch konstruktive Maßnahmen eher vermindert an Kritik. Ich arbeite daran, indem ich seinen Code überprüfe, während er neben mir sitzt und ihn bittet, den Code zu beschreiben. Es wird zu einer Art verzögerter Paarprogrammierungssitzung, in der wir Verbesserungen diskutieren und gemeinsam erarbeiten. Während des Prozesses fügen wir der PR Notizen hinzu, damit er später darauf zurückgreifen kann. Wir durchlaufen einen ähnlichen Prozess, wenn er eine PR von mir überprüft und ich einem seiner Kommentare nicht zustimme.

Wenn Sie Zweifel haben, sollten Sie mit Ihrem Kollegen sprechen und dies persönlich klären und dann auf seinen Kommentar antworten. Wenn der Kollege remote ist, können Sie mit einem kurzen Anruf oder einigen Sofortnachrichten ein ähnliches Ergebnis erzielen. Wenn Sie sich auf den Inhalt Ihrer Antwort geeinigt haben, auch auf etwas wie

Wie bereits erwähnt, ist dies nicht korrekt. Ich löse diese Konversation (um eine GitHub-Terminologie zu verwenden)

klingt aufgrund des Kontexts nicht snarky.

Der beste Weg, um jemanden in einer Situation zu korrigieren, besteht darin, dies so zu tun, dass er sein Gesicht retten kann, insbesondere wenn er solche Bewertungen durchführt.

Der beste Weg, dies zu tun, besteht darin, dies zu tun indirekt.

Hmmmm ... Lassen Sie mich das noch einmal überprüfen ... Ah! Hier sind wir. Z tut Y. Es tut mir leid, wenn ich das nicht klar genug kommentiert habe.

Oder so ähnlich. Sie haben das Gefühl, dass "X tatsächlich kein Y macht. Z ist das, was Y tatsächlich tut". klingt snarky.

Eine andere Art, wie Sie das ausdrücken könnten indem Sie die Person sanft anstupsen, um sie erneut zu durchlaufen.

Lassen Sie uns noch einmal nachsehen ... Können Sie mir zeigen, was los ist?

und lassen Sie die Person Finden Sie den Fehler selbst.

Es ist besser, eine Person das Gesicht retten zu lassen, als Recht zu haben.

Ich möchte einen Ansatz hinzufügen, den ich als nützlich erachtet habe - die Bemerkung des Rezensenten, wie oben beantwortet, präzise zu korrigieren, aber auch anzubieten, einen Kommentar hinzuzufügen, die Dokumentation zu ändern oder die Funktion umzubenennen, um ihre Absicht klarer zu machen (falls möglich).

Vielleicht hat sich der Rezensent etwas beeilt und Ihren Code falsch verstanden. Aber der beste Code kann ohne viel Nachdenken gelesen und verstanden werden, und dieser Code war anscheinend nicht so einfach zu verstehen.

Natürlich kann nicht alles ganz einfach gemacht werden. Ein solcher Überprüfungskommentar weist jedoch darauf hin, dass die Lesbarkeit hier möglicherweise verbessert werden kann.

Denken Sie daran, dass Sie oder einer Ihrer Mitarbeiter diesen Code möglicherweise in einer Situation verstehen müssen, in der nicht viel Zeit oder Zeit zur Verfügung steht Ihr Geist ist auf andere Dinge gerichtet. Solche Kommentare können dann Missverständnisse und mögliche Fehler in der Zukunft verhindern - und es ist oft ein Segen für sich, nicht darüber nachdenken zu müssen.

Ich war oft dankbar, dass ich auf einen kleinen Kommentar gestoßen bin, der eine Funktion erklärt Anruf, auch in meinem eigenen Code. Dinge, die offensichtlich sind, wenn Sie tief in das Thema vertieft sind, werden mit der Zeit weniger offensichtlich, und ein paar erklärende Worte können Ihnen später viel Frust ersparen;)

Dies dient auch dazu, Respekt zu zeigen Ihr Mitarbeiter, in dem steht "Vielleicht habe ich es nicht klar genug gemacht", nicht "Sie haben das falsch verstanden, ich habe Recht".

Sie haben Ihren Standort nicht erwähnt, und was Sie fragen, ist sehr ortsabhängig. In Großbritannien geben Sie nur die Fakten an. Wenn Sie sicher sind, sagen Sie "X macht Y, wie es soll." Wenn Sie sich nicht ganz sicher sind, sagen Sie "Ich denke, X macht Y, wie es soll". Es gibt kein "rettendes Gesicht". Ich bin in der Lage, gute Arbeit zu leisten, aber ich bin auch in der Lage, absolut dumme Dinge zu tun, und ich weiß auch, dass Sie in der Lage sind, absolut dumme Dinge zu tun. Wenn Sie mich also dabei erwischen, etwas Dummes zu tun Ich werde es einfach reparieren.

Ich weiß, dass es Länder gibt, in denen es nicht so funktioniert, in denen es als äußerst unhöflich angesehen wird, einen Mitarbeiter zu kritisieren (bis zu dem Punkt, an dem Flugzeuge abgestürzt sind, weil der Co-Pilot zu höflich war auf den fatalen Fehler des Piloten hinweisen). Ich würde gerne eine Antwort von jemandem sehen, der zum Beispiel in Indien arbeitet.

Zunächst einmal können Sie sich nicht allzu viele Gedanken darüber machen, wie jemand anderes Ihre Kommentare interpretiert oder etwas aus Ihrem vermeintlichen 'Ton' ableitet.

Ich finde oft Leute, die jemanden beschuldigen, 'passiv-aggressive' Verhaltensweisen tun dies aus einer Verteidigungsposition heraus, nachdem einfache Tatsachenaussagen sie in einen negativen Rahmen geworfen haben, selbst wenn der Fehler sehr leicht behoben werden kann. Sie wollen den Fehler oder das Versehen einfach nicht zugeben. Zum Beispiel:

Anweisung: Die Funktionsrichtlinien besagen, dass Z Y tut.

Reaktion: OMG, warum beschuldigen Sie mich, die Spezifikation nicht gelesen zu haben? Die Dokumente sind nicht sehr gut organisiert und der Teil über Z ist nicht sehr klar. Sie müssen sich ausruhen!

In einer technischen Umgebung ist es wahrscheinlich, dass nur Fakten angegeben werden bei weitem die breiteste Anziehungskraft und Akzeptanz . Wenn jemand übermäßig defensiv wird, hat er zwischenmenschliche Probleme, und Sie müssen sich dies beim nächsten Mal nur merken.

Ich finde fast allgemein, dass Menschen vernünftig und vollkommen in Ordnung sind, entweder die Situation zu akzeptieren oder Korrekturen vorzunehmen, selbst wenn sie dies tun Ich bin schuld, wenn der Fehler / das Versehen / der Fehler das Problem ist, nicht die Person.

Warum macht Z nicht X? Das ist eine wirklich große Sache!

Seite 4 von Spezifikation 2 sagt, Z macht Y, also macht es das.

Oh, ich verstehe. Ich denke, es muss sich geändert haben.

Kein Problem. Wenn Z X ausführen muss, aktualisieren Sie einfach die Spezifikation und wir machen es möglich.