Nein, das ist nicht üblich. Sie sind jedoch auf ein ziemlich verbreitetes Tier gestoßen, den Elitist Super Entitled Developer. Er ist schlauer als alle anderen in seinem Kopf und hat das Recht, aus demselben Grund unhöflich zu sein. Er hat eine Axt gegen Morty. Vermeiden Sie ihn, wenn möglich, und gehen Sie weiter.

Während er sicherlich das Recht hat, das Problem selbst untersuchen zu wollen, lautet eine zivilisierte Antwort: "Danke für den Vorschlag, ich werde mich darum kümmern." Möglicherweise gibt es bereits schlechtes Blut zwischen den beiden oder er ist nur wild, aber in beiden Fällen ist dieses Verhalten zwar technisch 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 erkennen, wo das Problem liegt, und wenn ich kürzlich an diesem Code gearbeitet hätte, würde ich wahrscheinlich wissen, ob er richtig ist oder nicht, auch ohne den Code zu überprüfen. Also würde ich einfach antworten: "Danke, dass Sie es verstanden haben" oder "Danke, dieser Zeiger sollte nicht geteilt werden, aber ich weiß, wie das Problem behoben werden sollte, nachdem Sie mich darauf aufmerksam gemacht haben" oder so ähnlich. P. >

Außerdem spüre ich in der Nachricht kein Gefühl der Überlegenheit.

Jetzt könnte es schlecht sein, wenn jeder CC ist. Der Code könnte etwas sein, über das auch andere Bescheid wissen. Wenn die CC-Empfängerliste kurz genug ist, ist dies gut. Die Mail ist kurz genug und jeder kann sofort anhand des Patches sehen, ob er interessiert sein sollte oder nicht, was nur wenig Zeit verschwendet. Wenn es jedoch Personen gibt, die nicht mit dieser Quellcodebasis in CC befasst sind, war dies unangemessen.

Ein weiteres Problem ist, ob die Person ihre Zeit damit verbringen sollte, ein solches Problem zu debuggen. Wenn sie jedoch nicht hinter ihren eigenen Zielen zurückbleiben, ist es im Allgemeinen eine sehr, sehr wertvolle Eigenschaft, die Verantwortung für die gesamte Software wie diese zu übernehmen. Es zeigt Begeisterung und Fürsorge, wirklich selten. Diese Dinge können zu weit gehen, aber es ist so viel häufiger, Teamkollegen zu sehen, denen ein Fehler in einem anderen Code nicht weniger wichtig ist, es sei denn, er hat sie direkt beeinflusst.

Um zu antworten die Titelfrage. Mortys Ton, wie er in Frage gestellt wird, ist für mich professionell und normal. Ricks Ton ist ... leider auch nicht so ungewöhnlich, aber es ist unglücklich. Wir haben jedoch alle 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 man sich nur gewöhnen muss.

Ich weiß, dass die Frage bereits beantwortet wurde, und ich stimme der akzeptierten Antwort zu, aber ich wollte dies nur um weitere 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 muss.

Das Prinzip eines XY-Problems ist recht 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 ausgewählt (entweder aus Faulheit oder weil man nicht versteht, 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 dorthin zu schauen ist eine Z-Lösung, 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 Was ist in Mortys E-Mail passiert? Rick ist nicht in der Lage, die Anfrage als Y oder Z zu kennzeichnen, da 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 ' t rate X aus dem Nichts.

Dies ist das X-Problem:

ein Speicherverlust in einem Teil des Plattformcodes

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

Dann schlägt Morty eine Y-Lösung vor. Da wir die Besonderheiten von X nicht kennen, können wir nicht beurteilen, ob Y eine geeignete Lösung für X ist.

Deshalb drängt Rick sich dagegen zurück. Er wird gebeten, etwas zu ändern (und effektiv 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 Sie zu und sagt: "Sie müssen diesen Mann verhaften" (Y).

Der Polizist sollte sich nicht daran halten, 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", kann der Polizist das Problem tatsächlich verstehen und selbst über die Lösung (Festnahme des Mannes) entscheiden.

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

Wenn ich ignoriere, ob zwischen Ihnen eine Spannung besteht, ein allgemeines Kommunikationsproblem oder der Standardton bei Ihnen, möchte ich mich auf Ihre Frage konzentrieren:

Ist dieser Ton ungewöhnlich ein technischer Arbeitsplatz?

Nein , dieser Ton ist nicht ganz ungewöhnlich.

Menschen in der Branche sind an syntaktische Programmiersprachen gewöhnt, und genaue technische Daten vergessen manchmal den Ton in ihrer Kommunikation. Oft ist dies kein Problem, solange Außenstehende nicht an der Kommunikation beteiligt sind. Gewöhnen Sie sich an viele Nachrichten, die auf den Fall zugeschnitten sind.

1. Es ist ein Klischee, aber ja, es gibt auch solche Nerds da draußen, die nur schlechte soziale Kontakte haben Fähigkeiten, so dass Sie besser lernen, mit ihnen umzugehen und sie nicht persönlich zu nehmen.

2. Für viele Programmierer ist "ihr" Code ihr Baby. Es ist eine Sache, auf unbestreitbare Fehler hingewiesen zu werden - das Durcheinander kann nur einige Abwehrmechanismen auslösen.

ol>

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

• Lob öffentlich, Kritik privat.
• Wenn Sie Probleme mit jemandem haben, verwenden Sie dafür überhaupt keine E-Mail!
• Wenn Sie einen Fehler finden, melden Sie ihn über einen Standardmechanismus, der von der akzeptiert wird Team.
• Machen Sie keine anderen Arbeiten, es sei denn, Sie werden darum gebeten.

Sein Gefühl hat einen gewissen Wert. Ich weiß oft, wo meine Vermutung über eine Grundursache jemanden auf den falschen Weg geführt und seine Zeit verschwendet hat.

Bei den meisten Problemen hat jede Person bestimmte Vermutungen, die sie nur "herausspringen". Ich denke, es lohnt sich zu versuchen, diese Kraft zu nutzen. Wenn ich Hilfe bei einem Fehler brauche, an dem ich festhalte, versuche ich zu vermeiden, ihnen meine eigenen Vorstellungen aufzuzwingen, damit ihre vielleicht neuartig und produktiv sind.

Aber so, wie er es ausgedrückt hat. Er war ein totales Arschloch.

Klar, nicht jeder stimmt dem zu, aber IMO das ist eine normale Antwort, nimm es nicht persönlich .

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

Es ist nicht persönlich für Sie oder Beleidigung oder Untergrabung ist eine Erklärung. Für manche Leute ist es ein bisschen direkt, aber das ist oft ein Problem für Programmierer, direkt und (zu) sachlich zu sein. Sie können diese ganze E-Mail in einem normalen Tonfall lesen, in dem er seine bevorzugte Methode erklärt. Nur weil du kein Fan davon bist, heißt das nicht, dass es eine schlechte Praxis ist, du wirst vielen Menschen begegnen, die anders arbeiten als du.

Ich stimme zu, dass es ein bisschen formuliert sein könnte Höflicher, aber auch hier sagt ein Programmierer oft nur, was er ohne all diese geladenen Interpretationen meint (was keine Entschuldigung ist, aber es könnte eine Erklärung sein).

Es ist seine Aufgabe, Probleme zu beheben, nicht deine. Sie haben gerade Zeit mit etwas verbracht, das sonst hätte verwendet werden können. Versteh mich nicht falsch, Bugfixing zu üben ist wichtig! Aber studieren Sie die angewandte Lösung und vergleichen Sie sie mit Ihrer. Ihre Lösung scheint in Ordnung zu sein, aber die Erfahrung lehrt Sie möglicherweise etwas anderes.

Hier sind beide Seiten schuld.

Morty hätte nicht alle in der ersten E-Mail kontaktieren sollen. Auf diese Weise brachte er Rick in Verlegenheit, indem er alle auf seinen Fehler hinwies. Ich weiß nicht, ob Morty versucht hat, auf diese Weise 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 ist es peinlich, dass sein Fehler öffentlich darauf hingewiesen wurde, dass er schlecht reagiert hat. Er hätte Morty nicht niederlegen sollen. Er hätte Morty nicht öffentlich dafür kritisieren sollen, dass er versucht zu helfen.

Ein Beispiel für einen E-Mail-Austausch sagt nichts über eine Unternehmenskultur aus. Wenn Sie jedoch häufig öffentliche E-Mails senden, in denen auf die Fehler anderer Personen hingewiesen wird, und E-Mails senden, in denen Personen mitgeteilt werden, dass sie keine Hilfe anbieten sollen, haben Sie eine toxische Kultur.

Leider ist diese Art von toxischer Kultur in Software häufig Unternehmen in den Vereinigten Staaten. Ähnlich wie [1] [2] [3] geschrieben und darüber gesprochen wurde, wie eine bestimmte Art von Software-Ingenieuren andere behandelt, insbesondere nicht -Softwareingenieure und Menschen, die nicht zu ihrem Stereotyp eines Softwareentwicklers passen.

Diese Kultur ist nicht der richtige Weg, um Menschen zu behandeln. Gute Unternehmen, Manager und Mitarbeiter tolerieren diese Art von Kultur nicht. Gute Mitarbeiter weisen sich gegenseitig nicht öffentlich auf Fehler hin und gute Mitarbeiter entlassen keine Hilfe von anderen.

Sie müssen herausfinden, dass dieses Verhalten in der Kultur Ihrer Abteilung und Ihres Unternehmens akzeptabel ist. Wenn Sie glauben, in einem Unternehmen zu sein, in dem dies akzeptiert wird, müssen Sie entscheiden, ob Sie der Meinung sind, dass Sie die Kultur ändern können, und ob dies die Anstrengung wert ist. Es ist wichtig herauszufinden, ob diese Kultur von der Führung kommt oder nicht. Wenn Führung ein schlechtes Beispiel gibt, können Sie nichts tun. Wenn dies die Basis-Kultur ist, haben Sie eine Chance, die Menschen davon zu überzeugen, sich zu ändern. Es wird ein langer, harter Job, 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 schlechtes Blut zwischen diesen beiden Personen.

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 bewerten, ob sich dieses toxische Verhalten auch auf andere ausgeweitet hat oder ob es sich um eine handelt enthaltene Situation.

Was auch immer passiert, lassen Sie es einfach nicht in Ihre Persönlichkeit eindringen.

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

Ist dies in Technologieunternehmen normal?

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

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

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

Um dies zu verallgemeinern, geschieht hier, dass Rick von Morty eine Direktive gegeben wird , die zuerst eine Begründung für die Direktive erstellt und dann die Besonderheiten dieser Richtlinie.

Dies erschwert die Angelegenheit weiter, da die Richtlinie in einer Gruppeneinstellung (cc'd an alle Mitglieder von th e Team).

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 gleich

Soll Rick die Anweisung von Morty übernehmen?

• Nein? Dann ist Rick berechtigt, zurückzudrängen.
• Ja? Dann müssen nicht alle CC. Rick ist immer noch berechtigt, Morty zu sagen, wie er seinen Job am besten ausführt.

Diese Situation wäre nicht anders, wenn es ... h3 wäre >

• Medizin. Dr. Oz sagt Dr. No, dass er den Patienten von Dr. No diagnostiziert hat und X, Y und Z durchführen soll, ohne Dr. No.
• Automotive die Symptome mitzuteilen. Ingenieur 1 teilt Ingenieur 2 mit, dass ein Problem im Aufhängungsdesign von Ingenieur 2 gefunden wurde. Die Lösung besteht darin, die Lasche A an Steckplatz B zu schweißen, ohne die Testdaten bereitzustellen, um das Problem anzuzeigen.
• Technischer Support - Tech 1 teilt Tech 2 mit, dass ein Problem mit dem System von Tech 2 vorliegt. Die Lösung besteht darin, die Patches A, B und C zu implementieren, ohne die Fehlermeldungen anzugeben, die auf das Problem hinweisen.

TL; DR

Unter dem Strich teilt die Person, die für die eigentliche Reparatur verantwortlich ist, der Person mit, was sie für die ordnungsgemäße Ausführung der Arbeit benötigt. Die einzige Person, die möglicherweise "out of line" ist, ist Morty für das passive aggressive Verhalten, alle zu erreichen.

Dies geschieht jeden Tag in jeder Branche. Es ist nichts Neues oder Ungewöhnliches.

  --- a / raumschiff / DoBattle.cpp +++ b / raumschiff / DoBattle.cpp vector<part> parts = getSpaceShipParts (); + shared_ptr<SpaceShip> p = neues Raumschiff (Teile); -SpaceShip * p = neues SpaceShip (Teile); engagInBattle (p, Feind);  

Leider behebt diese Änderung den Fehler (so zu tun, als wäre der Valgrind-Test adaquit), aber es wurde etwas Unerwünschtes eingeführt, ein Kampf um die Code-Philosophie. Wenn Sie kein regelmäßiger Mitwirkender sind, sollten Sie sich nicht auf Code-Philosophie-Kämpfe einlassen.

Um den Philosophie-Kampf zu vermeiden, sollte dieser stattdessen gesendet werden. Ja, es ist objektiv schlimmer, aber es entspricht dem Stil des bereits vorhandenen Codes:

  --- a / spacehip / DoBattle.cpp +++ b / spacehip / DoBattle.cpp SpaceShip * p = neues Raumschiff (Teile); engagInBattle (p, Feind); + lösche p;  

Aber mit dieser Antwort des Entwicklers hätte er das wohl auch nicht gemocht. Ich höre diesen Ton viel zu viel, selbst von Leuten, die es besser wissen sollten. Es ist nicht normal, aber es reicht aus, dass Sie es oft hören. Ich bin enttäuscht.

1) Kommunikation: OP lässt es als Standard erscheinen, den Rest des Entwicklerteams zu kontrollieren. Ich sehe nie einen Grund, den Rest des Entwicklerteams nicht in ein Problem / eine Lösung einzubeziehen, die alle betrifft.

2) Problem / Lösung: Sehen Sie hier nichts Falsches. Es sollte mit einer Pull-Anfrage durchgeführt werden, aber vorausgesetzt, dass dies hier nicht möglich ist, ist es in Ordnung.

3) Antwort: So viele Dinge sind falsch, dass ich nicht einmal 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 warten Einige Tage, bevor ich Ihre Arbeit vollständig ignorieren und Ihre Lösung verwerfen kann. Ich werde nicht nur Zeit damit verschwenden, eine Lösung zu implementieren, sondern auch mehr Zeit damit verschwenden, eine Lösung für ein Problem zu finden, das (von) gelöst wurde den Code, den Sie geschrieben haben, den ich verwerfen werde) "
c) 'sehen, was das eigentliche Problem ist und was das Update sein sollte': test it . Testen Sie es, um festzustellen, ob ein Problem vorliegt. Testen Sie es dann, um festzustellen, ob das Problem behoben wurde. Sie gewinnen nichts, wenn Sie eine eigene Lösung entwickeln, die getestet werden muss , anstatt die vorgeschlagene Lösung zu testen, um festzustellen, ob sie alles behebt. Wenn das Problem 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 leitete die Antwort sofort und kommentarlos an meinen Manager weiter. Es ist einfach inakzeptabel.