Frage:
Antwort auf einen Bugfix-Vorschlag, der nur Fehler meldet (keine Lösungen vorschlägt). Ist das typisch?
MortysFriend
2018-06-21 09:20:01 UTC
view on stackexchange narkive permalink

Ich bin ein neuer Mitarbeiter eines Softwareunternehmens und habe eine E-Mail gesehen, die von einem Systembesitzer an einen Mitarbeiter gesendet wurde, aber mit dem gesamten Entwicklerteam, und ich habe mir ein bisschen Sorgen um die Umgebung gemacht. Ich habe vor kurzem das College verlassen, also ist dies mein erster Job. Ist das in Tech-Unternehmen normal?


An die Mail-Liste des Entwicklerteams von Rick und Cc gesendet:

Hallo Rick,

Ich habe valgrind auf dem SpaceShip-Projekt ausgeführt und ich glaube, ich habe einen Speicherverlust in einem Teil des Plattformcodes gefunden. Ich glaube, ich habe die Quelle gefunden und das Problem kann mit dem folgenden Unterschied behoben werden:

  --- 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);  

Ich habe valgrind mit der Änderung erneut ausgeführt, und es scheint das Problem zu beheben!

Danke,
Morty

Eine ziemlich vernünftige E-Mail, dachte ich, die beantwortet wurde mit:

Hallo Morty,

Danke, aber in Zukunft bitte nur angeben die Informationen zum Reproduzieren eines Problems, keine vorgeschlagene Lösung. Ich lese keine vorgeschlagenen Korrekturen, da sie mich für eine bestimmte Vorstellung davon prädisponieren, was das eigentliche Problem ist und wie die Korrektur aussehen sollte. Ich gehe besser frisch rein und entscheide selbst.

In Fällen, in denen ich versehentlich ein Diff gelesen habe, bevor ich merkte, was es ist, verbringe ich absichtlich mindestens einige Tage damit, es zu vergessen, damit ich es frisch angehen kann. Wenn ich mir also einen Unterschied mache, ist es wahrscheinlicher, dass ich mich das Problem für einige Zeit nicht einmal anschaue.

Vielen Dank,

--Rick

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/79214/discussion-on-question-by-mortysfriend-is-this-tone-unusual-in-a-tech-workplace).
Es ist sehr ungewöhnlich, diese Art der Kommunikation zu haben, aber leider ist es üblich, dass jedes Unternehmen / Team ein Mitglied hat, das nicht wirklich in einem Team funktioniert oder ein Besserwisser ist und so weiter.Grundsätzlich gilt: Solange dies bei den meisten Ihrer Kollegen nicht der Fall ist, versuchen Sie einfach, diese eine Person zu vermeiden, und es sollte Ihnen gut gehen.
Elf antworten:
#1
+240
mxyzplk - SE stop being evil
2018-06-21 09:25:50 UTC
view on stackexchange narkive permalink

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".

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/79213/discussion-on-answer-by-mxyzplk-is-this-tone-unusual-in-a-tech-workplace).
Die kleinste Lösung, die ich hinzufügen möchte, ist, dass OP Mortys Freund ist, nicht unbedingt Morty.
Das ist keine Lösung, der Rick hat in diesem Beispiel ein Problem mit dem Morty.Mortys Freund ist der OP, aber er ist nur ein Zuschauer.
#2
+70
hyde
2018-06-21 12:41:21 UTC
view on stackexchange narkive permalink

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.

"Jeder könnte schlecht sein oder auch nicht" - falls er wusste, wie Rick sich in diesen Situationen verhält, fühlt sich jeder als der am besten geeignete Weg an, um sicherzustellen, dass das Problem tatsächlich behoben wird.
#3
+48
Flater
2018-06-21 11:09:10 UTC
view on stackexchange narkive permalink

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.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/79212/discussion-on-answer-by-flater-is-this-tone-unusual-in-a-tech-workplace).
@JaneS-Kommentare werden jedoch * korrekt * verwendet, um auf Probleme bei Antworten hinzuweisen.
Obwohl ich denke, dass die Erwähnung des XY-Problems relevant dafür ist, ob Ricks Anfrage hier vernünftig war, denke ich nicht, dass dies eine Antwort auf die Frage ist, wie Sie sie geschrieben haben.Das OP fragte, ob Ricks Ton in der Branche normal sei.Sie könnten erwägen, Ihre Antwort neu zu formatieren, um sich darauf zu konzentrieren, wie Rick damit umgegangen ist, obwohl der Kern seiner Antwort gültig ist.
@BloodGain `Sie könnten Ihre Antwort neu formatieren, um sich darauf zu konzentrieren, wie Rick damit umgegangen ist, obwohl der Kern seiner Antwort gültig ist .` Genau das spricht der letzte Satz der Antwort.
#4
+15
Daniel
2018-06-21 16:21:11 UTC
view on stackexchange narkive permalink

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.

  3. 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.
Ich mag alle Stichpunkte.Die ersten beiden sind gute allgemeine Richtlinien im Leben.
Für das Baby ist es wichtig, ob die Person Erfahrung mit Open Source hat.
Die Beschwerde über den Mangel an Reproduzierern ist IMO gültig.Aber es ist ziemlich verrückt, keine Lösung anzufordern.Wenn Sie jedoch nicht in der Lage sind, die anderer zu ignorieren, können Sie Ihre eigenen irreführenden Gedanken nicht ignorieren.Und wenn Sie nicht können, dann viel Glück beim Programmieren.Sie müssten einen Weg einschlagen und auf unbestimmte Zeit in die gleiche Richtung gehen. Oder vorhandenen Code umgestalten?Sie müssen verstehen, was die ursprüngliche Idee war, und sich dann in das neue Paradigma einfügen, das Sie anwenden möchten.
Ricks Erklärung, dass er den Prozess absichtlich verzögern wird, nominell, damit er seinen empfindlichen Verstand von Mortys korrupter Idee befreien kann, ist gereizt und völlig inakzeptabel und muss behandelt werden.Wenn Morty zu weit reicht (seine Fähigkeiten und / oder sein Umfang), wäre eine ausgewogenere Antwort "Danke, Morty, und Ihr schneller Vorschlag könnte Teil der Lösung sein, aber ich muss mehr über das Problem nachdenken, um sicherzugehenEs ist der beste Ansatz. Können Sie diesen Fehler bitte in unserem Bug-Tracker dokumentieren? Es ist wirklich wichtig, alle Fehler darin zu platzieren! "
@CCTO (und andere Kommentatoren) Sie wissen, dass OP nicht gefragt hat, wie man damit umgeht, ja?
#5
+14
Alexander - Reinstate Monica
2018-06-21 09:57:26 UTC
view on stackexchange narkive permalink

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.

Ich bekomme manchmal Web-Tickets mit vorgeschlagenen CSS-Korrekturen für visuelle Fehler.Das Problem ist, dass die Selektoren normalerweise sehr allgemein sind (oft nur auf Tag-Namen oder einer Klasse basieren) und mehrere andere Bereiche der Site beschädigen würden.Trotzdem gefällt mir der Vorschlag, weil er mir normalerweise Zeit spart, das genaue Problem zu finden, und ich ihn dann einfach in etwas Produktionsfähiges umwandeln kann ...
@dandavis Es ist nicht ihre Aufgabe, das Problem zu lösen.Es ist dein Job.Um ein Problem zu lösen, muss man wissen, was das Problem ist und welche Probleme mit der Lösung verbunden sind: P.
Könnten Sie das unhöfliche Stück erweitern?Diese Antwort ist großartig, da sie beide Seiten wiegt, aber etwas ungleichmäßig.
Ich muss respektvoll widersprechen.Bei der technischen Fehlerbehebung sind mehr Informationen * immer * wertvoller als weniger.Als zugewiesener Problemlöser ist es Aufgabe der Entwickler, zu ermitteln, welche fehlerhaften Informationen vom Kunden im Vergleich zu wertvollen Details vorliegen.Es ist eine lächerliche Idee für mich, einige Details von der Fehlerbehebung fernzuhalten, weil Sie sie möglicherweise auf den falschen Weg bringen, und ich würde jeden meiner Mitarbeiter, der auf diese Weise auf einen Kunden reagiert hat, zurechtweisen.
Technisch, aber kein Softwareentwickler hier, und ich stimme @DanK zu.Die einzige sehr geringfügige Änderung, die ich am ersten Bericht vornehmen würde, besteht darin, zuerst das Detail (möglicherweise mit einigen weiteren Benchmarks) und am Ende den Unterschied anzugeben.Das würde Rick die Möglichkeit geben, den Bericht ohne den Diff zu lesen, aber (IMO als jemand, der an wissenschaftliche Arbeiten gewöhnt ist, einschließlich mit Codelisten), das Diff aus dem Körper herauszuhalten, sorgt für eine klarere Lektüre.
Können Sie bitte näher erläutern, was hier nicht höflich ist?es scheint mir völlig frei von Beleidigungen zu sein, ich würde es gerne verstehen
@SargeBorsch - Die Forderung, keine gewöhnlichen, trivialen Informationen aufzunehmen, ist in einem Verbundprojekt völlig inakzeptabel.Und die erklärte Absicht, Morty durch absichtliche Verzögerung des Projekts zu bestrafen, verdoppelt dies nur.Es ist so geschrieben, dass es gut aussieht, aber die Bedeutung ist offensichtlich und unangemessen.Dass der Problembericht zwei Zeilen Diff enthält, ist kein Problem - es könnte helfen oder auch nicht, aber es ist kein Problem.Wenn Morty nicht Valgrind ausführen soll und gewöhnlich verwirrte Dinge meldet, * könnte * dies etwas sein, mit dem sich die Organisation befassen muss, aber dies ist nicht der Weg.
@SargeBorsch viel zu viele Menschen verwechseln Direktheit und Prägnanz mit Unhöflichkeit.Das einzige Problem, das ich mit der E-Mail habe, ist, dass der Urheber es für notwendig hielt, alle zu überprüfen.
@DanK Es hängt ganz von der Art des Problems ab.Ich befürworte diesen Ansatz nicht allgemein, sondern lediglich als eines der verfügbaren Tools in der Box.Wenn ich zu einem Kollegen gehe, um Hilfe bei einer Untersuchung zu erhalten, weiß ich oft, dass ich wahrscheinlich einem roten Hering nachjage und meine Zeit verschwende.Ich möchte den Vorteil einer neuen Perspektive.
Ich stimme DanK darin zu, es ist wichtig, so viele Informationen wie möglich aufzunehmen.Selbst wenn sie sich in Bezug auf die Grundursache irren, kann es hilfreich sein zu wissen, * warum * sie glauben, dass es sich um die Grundursache handelt. Dies kann zu weiteren Informationen führen.
@LordFarquaad Dies ist kein polarisiertes Teamspiel.Ich schlage keinen kostenlosen Informationsaustausch vor.Menschen sind leicht zu überzeugende Menschen.Es ist kein bewusster Prozess, es geht also nicht darum, "ein guter Informatiker" zu sein.
#6
+10
Martijn
2018-06-21 13:54:07 UTC
view on stackexchange narkive permalink

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.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/79196/discussion-on-answer-by-martijn-is-this-tone-unusual-in-a-tech-workplace).
@Martijin Die Frage besagt tatsächlich, dass Morty der "Systembesitzer" ist, dh jemand, der dafür verantwortlich ist, dass dies behoben wird.Die Untersuchung des Problems ist nicht wirklich aus ihrer Gesamtaufgabe heraus.Ricks E-Mail ist zum Teil eine Erklärung, aber es ist eine Erklärung für die Forderung, vor solchen Informationen geschützt zu werden, die in solchen Situationen normalerweise und sinnvoll ausgetauscht werden, und als solche, die mit einem Gruppenprojekt * grundsätzlich nicht kompatibel * sind, egal wieschön ist es formuliert.Es steht Rick frei, alternative Ursachen und Lösungen in Betracht zu ziehen, aber die normalerweise ausgetauschte Kommunikation nicht zu beenden.
#7
+4
Ben Mz
2018-06-21 09:31:07 UTC
view on stackexchange narkive permalink

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.

Könnte sein.Ohne mehr Kontext können wir nicht wirklich wissen, ob die ursprüngliche E-Mail "auf den Fehler einer Person hinweist" oder "den Fortschritt mit den anderen, die an einer Gruppenarbeit beteiligt sind, teilt" - soweit wir wissen, ist dies eine Schlüsselentwicklung in einem Bereich, in dem es eine gabgemeinsames, aber unspezifisches Gefühl, dass etwas nicht stimmte.Beachten Sie, dass dort nicht "in Ihrem Code" steht - das könnte eine implizite Annahme sein, aber der Text der E-Mail ist nicht anklagender als ein typisches Bug-Ticket und besser recherchiert als die meisten anderen.Oder es könnte ein ganz normal aussehender Text sein, der in seinem tatsächlichen Kontext stark bewaffnet ist.
Es ist ziemlich üblich, das Team zu kontaktieren, wenn ein wichtiger Fehler auftritt.
"Er hat Rick in Verlegenheit gebracht, indem er alle auf seinen Fehler hingewiesen hat." Software enthält Fehler.Jeder, der daran beteiligt ist, weiß dies und akzeptiert es.Ich kann garantieren, dass ** niemand ** unter der Täuschung operierte, dass Rick ein unfehlbarer Programmiergott war.Sollten sie auch ihren Bug-Tracker löschen, weil er subversiv eine permanente Aufzeichnung von Ricks persönlichen Fehlern ist?Ich werde nicht dafür bezahlt, fragilen Egos nachzugeben.Ich werde dafür bezahlt, gute Software zu machen.
@Michael „Ich werde nicht dafür bezahlt, fragilen Egos nachzugeben.“So etwas sagen viele Leute, um zu rechtfertigen, ein Arsch zu sein.
@BenMz Richtig - ich bin sicher, Rick könnte versuchen, diese Behauptung aufzustellen, nachdem er einige Antworten hier gelesen hat - aber ich denke, eine solche Person würde falsch identifizieren, höflich mit Pandering zu sein.Es ist nicht das gleiche.Ich bin bei der Arbeit immer höflich, aber ich sollte nicht auf Eierschalen um eine Person herum laufen müssen, weil sie nicht damit umgehen kann, dass das Entwicklerteam per E-Mail über einen leicht zu behebenden Fehler informiert wird.
Diese Antwort setzt die emotionalen Reaktionen der betreffenden Personen voraus, wenn nichts davon explizit oder implizit impliziert wurde.
@Allan Sie können den Ton der Kommunikation am Arbeitsplatz nicht beurteilen, ohne die emotionale Reaktion zu berücksichtigen, die sie wahrscheinlich hervorrufen.
Weißt du, dass Rick verlegen war?[Verlegenheit] (https://www.bing.com/search?q=embarrassment&FORM=AWRE) ist eine selbstbewertende Emotion (auch bekannt als persönlich).Es wurden keine persönlichen Angriffe durchgeführt.Sie können sagen, dass der Ton der E-Mail "hart" oder "stumpf" oder was auch immer ist, aber Sie können die emotionale Reaktion nicht annehmen, da jeder anders reagiert.
@Allan Ich gehe davon aus, dass Rick verlegen ist.Wenn wir nach bestem Wissen davon ausgehen, wie die Menschen reagieren, entscheidet der Richter, wie er mit ihnen kommuniziert.
Eine Folgefrage wäre: "Was bringt Sie bei diesem E-Mail-Austausch dazu, anzunehmen, dass Rick verlegen war?" Um das zu erweitern, was ich zuvor gesagt habe, gibt es keinen Hauch eines persönlichen Angriffs, der "Verlegenheit" rechtfertigt.Außerdem schlägt Ricks Antwort nicht auf Morty ein;es sagt ihm, was er * braucht *.
#8
+1
MonkeyZeus
2018-06-21 20:08:18 UTC
view on stackexchange narkive permalink

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.

#9
  0
Allan
2018-06-21 20:00:32 UTC
view on stackexchange narkive permalink

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.

Kommunikation ist extrem wichtig ... In meinem Team gehen 90% der Kommunikation über Slack / Jira / Github, das jeder sehen kann.Für eine Lösung, die sich auf das Produkt eines Teams auswirkt, sollten Sie immer das gesamte Team cc (oder es wahrscheinlich einfach an das gesamte Team senden). Zum eigentlichen Problem in der E-Mail: Es wurde ein Problem gefunden, eine Lösung gefunden.Jetzt denken Sie, dass der Lead seine Zeit gut nutzt, indem er Probleme und Lösungen verwirft und versucht, zu überprüfen, ob ein Problem vorliegt, und dann eine Lösung findet, die möglicherweise besser ist oder nicht?Dabei sagst du dem Kerl, dass seine Arbeit keine Rolle spielt ...
@xyious - Ich gehe davon aus, dass Sie aus den Gründen in Ihrer Argumentation abgelehnt haben.Interessant.Bei der ** Frage ** geht es nicht darum, wer im Recht ist, die Frage ist ** ist der Ton * ungewöhnlich ***.Unabhängig davon, welche Präferenzen die für die Änderung verantwortliche Person hat, ist dies ihre Präferenz.Zeitraum.
@Allan - ein zweizeiliger Unterschied ist keine "Wäscheliste mit zu implementierenden Korrekturen" - wo immer Sie das bekommen, ist es nicht Teil der Situation der Frage.In Bezug auf die Rollen von Morty und Rick wurde ausdrücklich darauf hingewiesen, dass Morty der "Systembesitzer" ist, und aus dem Kontext geht hervor, dass Rick der aktuelle Gebietsguru für den betreffenden Code ist.
Also, @ChrisStratton, Sie haben das "Diff" wörtlich genommen?SMDH.Lassen Sie mich das fragen ... Glaubst du, ein behandelnder Arzt sagt dem Spezialisten, was zu tun ist, oder sagt er ihm die Symptome und wartet auf eine Bestätigung?
Ich habe die * Skala * des Diff wörtlich genommen und bin ziemlich zuversichtlich, dass dies korrekt ist.Der springende Punkt der Frage ist, dass Rick einen Anfall über eine extrem normale, gewöhnliche und richtige Handlung geworfen hat.Sie scheinen stattdessen auf eine ganz andere Situation reagieren zu wollen als die, nach der tatsächlich gefragt wurde, was sich auch in Ihren Spekulationen über Beziehungen äußert, die nicht zu Mortys explizit angegebener Position passen.
* Ich habe die Skala des Unterschieds wörtlich genommen ... * Ein Beitrag, der "Rick und Morty" als Verschleierung der Namen von Personen in einer E-Mail verwendet, die wohl weniger Zeilen enthält als die Anzahl der Personen auf der CC-Liste, die Sie nehmen ** das ** "ernst".Sie sind kein Management und es zeigt.
Es ist ziemlich klar geworden, dass ein Großteil des Problems in Ihrem Beitrag von der Tatsache herrührt, dass Sie darauf bestehen, auf eine andere Situation als die tatsächlich beschriebene zu reagieren.Wie jeder * erfahrene * Entwickler hervorheben würde, handelt es sich bei dem gezeigten Unterschied um die Größe eines Fixes für diese Art von Problem, * das * oft * tatsächlich ist.
#10
  0
Joshua
2018-06-21 23:37:16 UTC
view on stackexchange narkive permalink
  --- 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.

Dies kann sein, dass der Unterschied etwas zu wörtlich gelesen wird.Es ist keine * Pull-Anfrage *, sondern ein bisschen * Code als Sprache * in einer E-Mail.Tatsächlich heißt es: "Vielleicht könnten wir es auf diese Weise beheben, oder vielleicht haben Sie eine bessere Idee, aber dieses Problem ist wichtig für mein Projekt, das Ihren Code enthält, und das Problem scheint von dieser Form zu sein." Auch wenn es nicht zusammengeführt wird, unterscheidet es sichso sind ziemlich normale Kommunikation zwischen Programmierern.
#11
  0
xyious
2018-06-22 00:14:29 UTC
view on stackexchange narkive permalink

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.

Aus der Sicht eines * Managers * möchte ich Sie darüber informieren, dass jeder Entwickler eine Einzelperson ist und jede Einzelperson ihre bevorzugte Arbeitsweise hat.Wir müssen alle versuchen, die Eigenheiten des anderen zu berücksichtigen.In diesem Fall würde ich Ihnen raten (als Ihr Manager zu sprechen, wenn Sie Morty gewesen wären), Ricks bevorzugten Workflow zu respektieren, indem Sie ihm * zuerst * das senden, wonach er gefragt hat, und dann nachverfolgen, was Sie * geglaubt * haben (wie inDie E-Mail) war das Problem, gefolgt von dem, was Sie (wieder in der E-Mail) als Lösung dachten.
Und fürs Protokoll ... je weiter ich in meiner Karriere ging und Erfahrung sammelte, desto weniger verließ ich mich auf die "Diagnose und die Lösung", ohne das Problem klar zu formulieren ** zuerst **. Die Ausnahme von dieser Regelwar, wenn das Problem / die Lösung von einer vertrauenswürdigen Quelle stammte.Ich kann Ihnen sagen, dass auch ich mögliche Lösungen ignoriert habe, wenn sie nicht meinen Anforderungen entsprachen, aber nicht aus Arroganz, sondern aus einer begrenzten Menge an Ressourcen (d. H. Zeit), die für die Entschlüsselung der Arbeit anderer aufgewendet werden mussten.
Sie würden also Ihr Entwicklerteam darüber informieren, dass es akzeptabel ist (als Eigenart), die Zeit eines Entwicklers zu verschwenden (indem Sie eine Lösung bereitstellen, die verworfen wird) und die Zeit eines Leads zu verschwenden (indem er eine Lösung verwirft und eine eigene entwickelt)?
Ich würde das Entwicklerteam darüber informieren, dass es inakzeptabel ist, Zeit zu verschwenden, indem die Wünsche / Anforderungen der Verantwortlichen für ihre jeweiligen Funktionen nicht berücksichtigt werden.Nur weil Sie davon ausgehen, dass die Lösung die richtige ist, heißt das nicht, dass dies der Fall ist.Es läuft auch darauf hinaus, dass der Verantwortliche das Problem nicht anhand der Diagnose und letztendlich der Lösung validieren kann.Sie befürworten nicht, dass jemand einfach eine Diagnose und einen Lösungsvorschlag sofort akzeptieren sollte, oder?Wie viel Zeit würde dann verloren gehen?Wie viel Zeit würde gespart, wenn die Symptome ** zuerst ** validiert würden?
Probier es aus !Testen Sie, ob das Problem besteht!Testen Sie, ob die Lösung das Problem behebt!Testen Sie dann, ob die Lösung nichts anderes kaputt macht.Sie müssten sowieso die letzten beiden machen.Warum sollten Sie eine Lösung verschwenden, die Sie nicht getestet haben, und sich etwas anderes einfallen lassen, das möglicherweise nicht einmal funktioniert?
Übrigens, das ist alles in meiner Antwort oben.Sie müssen ohnehin Unit-Tests durchführen.Sie müssen sowieso ständig testen.Warum haben Sie eine Lösung, die Ihnen jemand gegeben hat, nicht getestet?Wie ist das in jeder Situation akzeptabel?
Wie genau validieren Sie einen Test (muss weniger eine Lösung sein) gegen Symptome, die überhaupt nicht artikuliert wurden?Gehen Sie nicht davon aus, dass die Diagnose von Anfang an richtig war.Der interessante Teil davon ist Ihre Antwort * nie * spricht die eigentliche Frage an - * ist der Ton ungewöhnlich *.Sie verbringen jedoch übermäßig viel Zeit damit, Ihre Position zu verteidigen.Sie machen buchstäblich meinen Standpunkt für mich.
Ich verstehe, dass das die Überschrift ist, aber das ist nicht die Frage.Der Ton in der E-Mail war nicht vorhanden.Es gibt keinen'.Es sind die Worte, die ungewöhnlich sind.Sie streiten sich auch nicht über den Ton in Ihren ersten 3 Kommentaren zu meiner Antwort.Sie haben angefangen, über den Prozess zu streiten ...
Meine Kommentare adressieren ** Ihre Antwort **.Ihre Antwort kann die Gesamtfrage nicht beantworten.In diesem Fall bieten Sie wie "Morty" eine Lösung an, ignorieren jedoch die größere Frage.Wie viel Zeit haben Sie damit verbracht, etwas zu beantworten, das überhaupt nicht gefragt wurde?Einige freundliche Ratschläge von jemandem mit mehr als 25 Jahren, der dies tut ... konzentrieren Sie sich darauf, was * tatsächlich * gefragt wird und nicht darauf, was Sie * annehmen *, gefragt wird.
@Allan - Wenn Ihr Team die vorgeschlagene Änderung * nicht * effizient * durch Inspektion * bewerten kann, müssen Sie sie alle feuern und durch kompetente Entwickler ersetzen.Das Gesamtproblem erfordert möglicherweise größere Aufmerksamkeit - es könnte nur ein Beispiel für ein weiter verbreitetes sein, aber die * vorgeschlagene Änderung * ist entweder ein legitimes Kennzeichen für einen Fehler im vorhandenen Code, ein Zeichen für Mortys Verwirrung oder keine wirkliche Wirkung.
@ChrisStratton - Es überrascht mich ohne Ende, dass Menschen bis zu ihrem letzten Atemzug verteidigen, dass ihre Position absolut korrekt ist, wenn sie die Symptome, die für die vorgeschlagene Korrektur erforderlich sind, noch nicht identifiziert haben.** Jedes Mal, wenn ich Ihren Ansatz gewählt habe, kostet es mehr Ressourcen als die wahrgenommenen Einsparungen, wenn Sie nur die Änderung implementieren. **
@Allan - Der Punkt, den Sie so ** gefährlich ** ignorieren, ist, dass der vorhandene Code nicht einmal einen Fehler auslösen muss, um falsch zu sein.Hier besteht die absolute Verpflichtung herauszufinden, ob Morty auf ein tatsächliches Problem im vorhandenen Code hinweist, * zusätzlich * zum Einchecken des von ihm gemeldeten Testfehlers, * der möglicherweise in irgendeiner Weise damit zusammenhängt oder nicht *.Selbst wenn die eigentliche Ursache an anderer Stelle gefunden wird, könnte der von Morty vorgeschlagene spezifische Code ** immer noch unsicher ** sein.Hat Morty einen Punkt?Oder ist er nur verwirrt?Sie müssen es herausfinden, und * kompetente * Entwickler können dies schnell tun.
@ChrisStratton - Ernsthaft ... wie viele Annahmen können Sie möglicherweise in zwei verschleierten E-Mails treffen?* Wenn dies oder wenn das * - nichts davon ist wichtig.Was ich weiß, ist, dass niemand mit einer der Annahmen sprechen kann, die Sie treffen (soweit wir wissen, dass Morty ein verdammter Idiot ist), so dass sie letztendlich strittig sind.Trotzdem war ich sehr erfolgreich bei der Arbeit mit Entwicklern, indem ich ihren Bedürfnissen entsprach und sie nicht mit Hypothesen schlug, die auf Pseudocode basierten.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...