Antwort auf einen Bugfix-Vorschlag, der angeblich nur Bugs meldet (keine Lösungen vorschlägt). Ist das typisch? [geschlossen]

Nein, das ist nicht üblich. Sie sind jedoch auf eine ziemlich häufige Bestie gestoßen, den elitären Super-Entitled-Entwickler. Er ist seiner Meinung nach schlauer als alle anderen und hat aus dem gleichen Grund das Recht, unhöflich zu sein. Er hat eine Axt gegen Morty zu schleifen. Vermeiden Sie ihn, wenn möglich, und gehen Sie weiter.

Während er sicherlich das Recht hat, das Problem selbst untersuchen zu wollen, ist eine zivilisierte Antwort "Danke für den Vorschlag, ich werde mich darum kümmern." Es mag bereits böses Blut zwischen den beiden geben oder er kann einfach wild sein, aber in beiden Fällen ist dieses Verhalten zwar in der Technik nicht unbekannt, aber nicht akzeptabel oder „üblich“.

Als Entwickler finde ich den ersten Bericht sehr sehr nützlich. Keine lange Erklärung, keine lange Valgrind-Spur zum Lesen. Mit diesem Patch konnte ich sofort sehen, was das Problem ist, und wenn ich kürzlich an diesem Code gearbeitet hätte, würde ich wahrscheinlich wissen, ob es richtig ist oder nicht, sogar ohne den Code zu überprüfen. Also würde ich einfach antworten "Danke, dass Sie ihn gefunden haben" oder "Danke, dieser Zeiger sollte nicht geteilt werden, aber ich weiß, wie das Problem behoben werden sollte, jetzt, wo Sie mich darauf aufmerksam gemacht haben" oder so ähnlich.

Auch erkenne ich in der Botschaft kein Überlegenheitsgefühl.

Jetzt kann es schlecht sein, alle zu CC'n. Der Code könnte etwas sein, von dem auch andere wissen, also wenn die CC-Empfängerliste kurz genug ist, ist das gut. Die Mail ist kurz genug, und jeder kann anhand des Patches sofort sehen, ob er interessiert sein sollte oder nicht, was nur wenig Zeit verschwendet. Wenn es jedoch Leute gibt, die nicht mit dieser Quellcodebasis in CC zu tun haben, dann war es unangemessen.

Ein weiteres Problem ist, ob die Person ihre Zeit damit verbringen sollte, ein Problem wie dieses zu debuggen. Wenn sie jedoch ihre eigenen Ziele nicht verfehlen, ist es im Allgemeinen eine sehr, sehr wertvolle Eigenschaft, die Verantwortung für die gesamte Software zu übernehmen. Es zeigt Enthusiasmus und Fürsorge, was wirklich selten ist. Diese Dinge können zu weit gehen, aber es kommt viel häufiger vor, dass Teamkollegen sich nicht weniger um einen Fehler im Code eines anderen kümmern, es sei denn, er betrifft sie direkt.

Um die Titelfrage zu beantworten. Mortys Ton, wie er in Frage gestellt wird, ist in meinen Augen professionell und normal. Ricks Ton ist... leider auch nicht so ungewöhnlich, aber schade. Wir alle haben jedoch schlechte Tage, daher werde ich keine einzige anonymisierte Nachricht weiter analysieren. Es könnte ein schlechtes Zeichen sein (und sieht so aus, TBH), oder es könnte Teil einer recht anständigen Arbeitskultur sein, an die Sie sich nur gewöhnen müssen.

Ich weiß, dass die Frage bereits beantwortet wurde, und ich stimme der akzeptierten Antwort zu, aber ich wollte diese nur mit weiteren Informationen erweitern.

Was Sie hier gesehen haben, ist ein potenzielles XY-Problem . XY-Probleme sind meiner Meinung nach etwas, das jeder Problemlöser (nicht nur Programmierer) kennen und vermeiden sollte.

Das Prinzip eines XY-Problems ist ganz einfach:

• X ist ein Problem und muss behoben werden.
• Y ist eine Lösung, aber nicht die beste Lösung. Unabhängig davon wird es gewählt (entweder aus Faulheit oder aus Unverständnis, dass es eine bessere Lösung gibt)
• Wenn bei der Implementierung von Y ein Problem auftritt, widmen die Leute Zeit dem Versuch, Y zum Laufen zu bringen, anstatt tatsächlich zu suchen, ob es eine Z-Lösung gibt, die besser passt.

Als klares Beispiel:

• X = Ich möchte diese Excel-Daten sortieren.
• Y = Ich kann eine Anwendung schreiben, um die Daten zu sortieren und die Datei zu speichern.
• Z = Ich sollte lernen, wie man die Sortierfunktion von Excel verwendet.

Dies ist im Wesentlichen das, was in Mortys E-Mail passiert ist. Rick ist nicht in der Lage, die Anfrage als Y oder Z zu kennzeichnen, weil Morty X nicht erklärt. X zu erklären ist wichtiger als die Y/Z-Lösung anzubieten, da Rick in der Lage ist, Z zu finden, wenn er X kennt, aber er kann' Ich errate X nicht aus dem Nichts.

Das ist das X-Problem:

ein Speicherleck in einigen Plattformcodes

Beachten Sie, dass es ziemlich vage ist. Was war das Problem? Wo ist es passiert? Wann ist es aufgetreten? War es ein Grenzfall?

Dann schlägt Morty eine Y-Lösung vor. Da wir die Besonderheiten von X nicht kennen, haben wir keine Möglichkeit abzuschätzen, ob Y eine geeignete Lösung für X ist.

Deshalb wehrt sich Rick dagegen. Er wird gebeten, etwas zu ändern (und tatsächlich die Verantwortung dafür zu übernehmen, etwas geändert zu haben) , ohne eine Wahl zu haben . Morty hat Ricks Verantwortung (das Schreiben von gutem Code) effektiv untergraben und ersetzt sie durch eine Bitte um blindes Vertrauen, dass der angebotene Code angemessen und gut ist.

Stellen Sie sich das so vor: Sie sind ein Polizist. Ein Mann kommt auf dich zu und sagt: "Ich brauche dich, um diesen Mann zu verhaften" (Y).

Der Polizeibeamte sollte dem nicht nachkommen, da er nicht persönlich bestätigen kann, dass die Festnahme des Mannes gerechtfertigt ist.

Hätte der Mann jedoch gesagt „dieser Mann hat gerade jemanden kaltblütig getötet“, dann kann der Polizist das Problem tatsächlich verstehen und selbst über die Lösung (Festnahme des Mannes) entscheiden.

Das ist im Grunde das, was Morty falsch gemacht hat. Ich denke, dass Rick es freundlicher hätte formulieren können (wenn dies Interpersonal.SE wäre, würde ich definitiv einige von Ricks Sätzen umformulieren), aber seine Bitte ist berechtigt.

Unabhängig davon, ob es zwischen den beiden zu Spannungen, einem allgemeinen Kommunikationsproblem oder dem Standardton bei Ihnen kommt, möchte ich mich auf Ihre Frage konzentrieren:

Ist dieser Ton an einem Tech-Arbeitsplatz ungewöhnlich?

Nein , dieser Ton ist nicht ganz ungewöhnlich.

1. Menschen in der Branche sind an syntaktische Programmiersprachen und genaue technische Spezifikationen gewöhnt und neigen dazu, manchmal den Ton in ihrer Kommunikation zu vergessen. Dies ist oft kein Problem, solange keine Außenstehenden in die Kommunikation involviert sind. Gewöhnen Sie sich an viele sachliche Botschaften.

2. Es ist ein Klischee, aber ja, es gibt auch diese Nerds da draußen, die einfach nur schlechte soziale Fähigkeiten haben, also lerne besser, mit ihnen umzugehen und nimm es nicht persönlich.

3. Für viele Programmierer ist "ihr" Code ihr Baby. Auf einige unbestreitbare Fehler hingewiesen zu werden, ist eine Sache - daran herumzuspielen kann nur einige Abwehrmechanismen auslösen.

Das heißt, es kann besser gemacht werden. Als Faustregel gilt, um solche Probleme zu vermeiden:

• Öffentliche loben, Private kritisieren.
• Wenn Sie Probleme mit jemandem haben, verwenden Sie dafür auf keinen Fall E-Mail!
• Wenn Sie einen Fehler finden, melden Sie ihn über einen Standardmechanismus, der vom Team akzeptiert wird.
• Erledige nicht die Arbeit von jemand anderem, es sei denn, du wirst darum gebeten.

Sein Gefühl hat einen gewissen Wert. Ich kenne viele Fälle, in denen meine Vermutung über eine Grundursache jemanden auf den falschen Weg geführt und seine Zeit verschwendet hat.

Bei den meisten Problemen hat jeder Mensch bestimmte Ahnungen, die ihm einfach auffallen. Ich denke, es lohnt sich, zu versuchen, diese Kraft zu nutzen. Wenn ich Hilfe bei einem Fehler brauche, an dem ich feststecke, versuche ich zu vermeiden, ihnen meine eigenen Ahnungen aufzuzwingen, damit ihre vielleicht neuartig und produktiv sind.

Aber so wie er es ausdrückte... war er ein totales Arschloch.

Natürlich stimmt nicht jeder damit überein, aber meiner Meinung nach ist dies eine normale Antwort, nimm es nicht persönlich .

Es ist eine leicht verständliche E-Mail, er begründet seine Gründe, warum er es vorzieht, Ihre Lösung nicht zu hören (nicht weil es Ihre Lösung ist, sondern weil er von Anfang an eine leere Tafel haben möchte).

Es ist nicht persönlich dir gegenüber oder beleidigend oder überhaupt untergrabend, es ist eine Erklärung. Für manche Leute ist es ein bisschen direkt, aber das ist oft eine Eigenart von Programmierern, direkt und (zu) sachlich zu sein. Sie könnten diese ganze E-Mail in einem normalen Tonfall lesen, in der er seine bevorzugte Methode erklärt. Nur weil Sie kein Fan davon sind, heißt das nicht, dass es eine schlechte Praxis ist, Sie werden vielen Menschen begegnen, die anders arbeiten als Sie.

Ich stimme zu, dass es etwas höflicher formuliert werden könnte, aber noch einmal, ein Programmierer sagt oft nur, was er meint, ohne all diese aufgeladenen Interpretationen (was keine Entschuldigung ist, aber es könnte eine Erklärung sein).

Es ist sein Job, Probleme zu lösen, nicht deiner. Sie haben nur Zeit für etwas aufgewendet, das Sie anderweitig hätten nutzen können. Verstehen Sie mich nicht falsch, das Üben von Bugfixing ist wichtig! Aber studieren Sie die angewandte Lösung und vergleichen Sie sie mit Ihrer. Ihre Lösung mag gut erscheinen , aber die Erfahrung könnte Sie eines Besseren belehren.

Hier sind beide Seiten schuld.

Morty hätte in der ersten E-Mail nicht alle auf CC setzen sollen. Dadurch brachte er Rick in Verlegenheit, indem er alle auf seinen Fehler hinwies. Ich weiß nicht, ob Morty versucht hat, damit Punkte zu sammeln, oder ob er einfach dumm war. Das Ergebnis war jedoch aus Ricks Sicht dasselbe. Morty wäre besser dran gewesen, diese E-Mail nur an Rick zu senden, damit sie das Problem beheben können, ohne dass jemand schlecht aussehen muss.

Rick, der sich darüber schämte, öffentlich auf seinen Fehler hingewiesen zu werden, reagierte schlecht. Er hätte Morty nicht niedermachen sollen. Er hätte Morty nicht öffentlich dafür kritisieren sollen, dass er versucht hat zu helfen.

Ein Beispiel für einen E-Mail-Austausch sagt nichts über eine Unternehmenskultur aus. Wenn jedoch das Versenden öffentlicher E-Mails, in denen auf die Fehler anderer Personen hingewiesen wird, und das Versenden von E-Mails, in denen Personen mitgeteilt wird, dass sie keine Hilfe anbieten sollten, dort üblich sind, haben Sie eine toxische Kultur.

Leider ist diese Art von toxischer Kultur in Softwareunternehmen in den Vereinigten Staaten weit verbreitet. Es wurde viel darüber geschrieben [1] [2] [3] und gesagt, wie eine bestimmte Art von Software-Ingenieuren andere behandelt, insbesondere Nicht-Software-Ingenieure und Menschen, die nicht in ihr Klischee eines Software-Ingenieurs passen.

Diese Kultur ist nicht der richtige Umgang mit Menschen. Gute Unternehmen, Manager und Mitarbeiter tolerieren diese Art von Kultur nicht. Gute Mitarbeiter weisen sich gegenseitig nicht öffentlich auf Fehler hin und gute Mitarbeiter lehnen Hilfe von anderen nicht ab.

Sie müssen herausfinden, ob dieses Verhalten in der Kultur Ihrer Abteilung und Ihres Unternehmens akzeptabel ist. Wenn Sie denken, dass Sie in einem Unternehmen arbeiten, in dem dies akzeptiert wird, müssen Sie entscheiden, ob Sie glauben, dass Sie die Kultur ändern können und ob es den Aufwand wert ist. Es ist wichtig herauszufinden, ob diese Kultur von der Führung kommt oder nicht. Wenn Führung mit schlechtem Beispiel vorangeht, können Sie nichts tun. Wenn dies die Basiskultur ist, haben Sie eine gewisse Chance, die Menschen davon zu überzeugen, sich zu ändern. Es wird eine lange, harte Arbeit sein, also entscheiden Sie besser, dass es sich lohnt, das Unternehmen zu reparieren.

Normal ist ziemlich subjektiv, zumal Sie keine Ahnung von der Geschichte dieses Arbeitsplatzes haben.

Entweder hat Rick schreckliche zwischenmenschliche Fähigkeiten oder es gibt böses Blut zwischen diesen beiden Menschen.

Es ist möglich, dass Morty absichtlich eine "vernünftige" E-Mail erstellt hat, in der Hoffnung, Rick auszulösen.

Da Sie neu sind, müssen Sie beurteilen, ob sich dieses toxische Verhalten auch auf andere ausgebreitet hat oder ob es sich um eine eingedämmte Situation handelt.

Was auch immer passiert, lass es nur nicht in deine Persönlichkeit übergreifen.

Ich schreibe dies aus der Perspektive eines Managers mit Erfahrung, die mehrere Aspekte dieser Art von Szenario abdeckt.

ist das normal in technologieunternehmen?

Dies ist für jedes Unternehmen in praktisch jeder Branche völlig normal, nicht nur im Technologiebereich.

Im Großen und Ganzen die E-Mail, die an alle Mitglieder eines Entwicklerteams gesendet wurde, die Folgendes beinhaltet:

• wies auf einen vermuteten Fehler hin ("Ich glaube, ich habe ein Speicherleck gefunden...")
• gab an, dass eine angebliche Lösung gefunden wurde ("Ich glaube, ich habe die Quelle und das Problem gefunden ...")
• präsentierte eine Wäscheliste mit Korrekturen, die implementiert werden sollten

Um dies zu verallgemeinern, was hier passiert, ist, dass Rick von Morty eine Anweisung gegeben wird, die zuerst eine Rechtfertigung der Anweisung enthält und dann die Einzelheiten dieser Anweisung aufführt.

Es verkompliziert die Angelegenheit weiter, da die Anweisung in einer Gruppenumgebung gegeben wurde (cc an alle Mitglieder des Teams).

Ricks und Mortys organisatorische Beziehung

Wir kennen die Beziehung in Bezug auf die beiden Personen nicht. Es kann jedoch allgemein als eine von drei Möglichkeiten zusammengefasst werden:

• Rick ist älter als Morty
• Morty ist älter als Rick
• Rick und Morty sind gleichberechtigt

Soll Rick Anweisungen von Morty entgegennehmen?

• Nein? Dann ist Rick berechtigt, zurückzudrängen
• Ja? Dann ist es nicht nötig, alle zu CC. Rick hat immer noch das Recht, Morty zu sagen, wie er seinen Job am besten ausführt.

Diese Situation wäre nicht anders, wenn es so wäre....

• Medizinisch. Dr. Oz teilt Dr. No mit, dass er Dr. Nos Patient diagnostiziert hat und X, Y und Z durchführen soll, ohne Dr. No die Symptome mitzuteilen.
• Automobil. Ingenieur 1 teilt Ingenieur 2 mit, dass ein Problem im Aufhängungsdesign von Ingenieur 2 gefunden wurde und die Lösung darin besteht, Lasche A an Schlitz B zu schweißen, ohne die Testdaten bereitzustellen, um das Problem aufzuzeigen
• Technischer Support - Tech 1 teilt Tech 2 mit, dass es ein Problem mit dem System von Tech 2 gibt und die Lösung darin besteht, die Patches A, B und C zu implementieren, ohne die Fehlermeldungen zu liefern, die auf das Problem hinweisen.

TL;DR

Unterm Strich sagt die Person, die für die eigentliche Reparatur verantwortlich ist, der Person, was sie braucht, um die Arbeit richtig zu erledigen. Die einzige Person, die möglicherweise "aus der Reihe tanzt", ist Morty für das passiv-aggressive Verhalten, alle auf CC zu setzen.

Das passiert jeden Tag in jeder Branche. Es ist nichts Neues oder Ungewöhnliches.

--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp  
 vector<part> parts = getSpaceShipParts();  
+shared_ptr<SpaceShip> p = new SpaceShip(parts);  
-SpaceShip * p = new SpaceShip(parts);  
 engageInBattle(p, enemy); 

Leider behebt diese Änderung den Fehler (vorzutäuschen, dass der Valgrind-Test angemessen ist), aber sie hat etwas Unerwünschtes eingeführt, einen Kampf um die Code-Philosophie. Wenn Sie kein regelmäßiger Mitwirkender sind, lassen Sie sich nicht auf Code-Philosophiekämpfe ein.

Um den Philosophiekampf zu vermeiden, hätte dieser stattdessen gesendet werden sollen. Ja, es ist objektiv schlechter, aber es entspricht dem Stil des bereits vorhandenen Codes:

--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp  
 SpaceShip * p = new SpaceShip(parts);  
 engageInBattle(p, enemy); 
+delete p;

Aber bei dieser Antwort des Entwicklers nehme ich an, dass ihm das auch nicht gefallen hätte. Ich höre diesen Ton viel zu oft, selbst von Leuten, die es besser wissen müssten. Es ist nicht normal, aber es reicht aus, dass man es oft hört. Ich bin enttäuscht.

1) Kommunikation: OP lässt es so aussehen, als wäre es üblich, den Rest des Entwicklerteams auf CC zu setzen. Ich sehe nie einen Grund, den Rest des Entwicklerteams nicht in ein Problem/eine Lösung einzubeziehen, die alle betrifft.

2) Problem/Lösung: Sehe hier nichts Falsches. Es sollte mit einer Pull-Anforderung erfolgen, aber vorausgesetzt, das ist hier nicht möglich, ist es in Ordnung.

3) Antwort: So viele Dinge sind falsch daran, dass ich gar nicht weiß, wo ich anfangen soll.
a) „Ich lese keine vorgeschlagenen Korrekturen“: Das ist absolut schrecklich. Lesen Sie immer den vorgeschlagenen Code. Es besteht eine gute Chance, dass es besser ist als alles, was Sie sich einfallen lassen können....
b) „Ich muss ein paar Tage warten, bevor ich eine Lösung finden kann“: Lassen Sie mich das übersetzen: „Ich muss ein paar Tage warten bevor ich Ihre Arbeit vollständig ignorieren und Ihre Lösung verwerfen kann. Ich werde nicht nur Zeit verschwenden, um eine Lösung implementieren zu lassen, ich werde auch mehr Zeit verschwenden, um eine Lösung für ein Problem zu finden, das gelöst wurde (durch den Code, den Sie schrieb, dass ich es verwerfen werde)"
c) 'sehen Sie, was das eigentliche Problem ist, und sehen Sie, was die Lösung sein sollte': Testen Sie es. Testen Sie es, um zu sehen, ob es ein Problem gibt. Testen Sie es dann, um zu sehen, ob das Problem gelöst wurde. Sie gewinnen nichts, wenn Sie Ihre eigene Lösung entwickeln , die getestet werden muss, anstatt die vorgeschlagene Lösung zu testen, um zu sehen, ob sie alles behebt. Wenn das Problem dadurch nicht behoben wird , können Sie versuchen, eine Lösung für die vorgeschlagene Lösung oder eine Lösung für das Problem insgesamt zu finden.

In meiner Firma hätte ich die Antwort sofort und kommentarlos an meinen Vorgesetzten weitergeleitet. Es ist einfach nicht akzeptabel.