Frage:
Ist es ein Problem, dass Pull-Anfragen ohne Kommentare genehmigt werden?
mkki
2019-05-30 18:33:38 UTC
view on stackexchange narkive permalink

Ich bin kürzlich einer neuen Firma in diesem hübschen kleinen Team beigetreten. Ich stoße auf dieses Problem, bei dem meine Mitarbeiter meine Pull-Anfrage einige Sekunden nachdem ich sie gebeten habe, sie zu überprüfen, genehmigen. Es gibt nie Kommentare dazu, egal wie komplex die Pull-Anfrage ist.

Ich bin ein wenig frustriert, weil ich weiß, dass mein Code nicht perfekt ist, duh, aber ich bin es nicht in der Lage zu sein, meine Codierungsfähigkeiten zu erweitern, wenn ich kein Feedback bekomme. Ich habe das Gefühl, ich kann einfach jeden Code schreiben und bekomme die Genehmigungen, um ihn zusammenzuführen.

Wir haben derzeit keinen direkten Manager, daher kann ich nicht mit ihnen darüber sprechen. Ich finde es auch komisch, zu den Entwicklern zu gehen und sie zu bitten, meine Pull-Anfragen besser zu überprüfen. Vielleicht sollte ich das nicht tun?

Beachten Sie, dass Pull-Anfragen von anderen Teams unzählige Kommentare, gute Kommentare und keine Tipps enthalten.

Ich bin mir nicht ganz sicher, was ich hier tun soll. P. >

Sind Sie sicher, dass sie es vor der Genehmigung nicht mindestens flüchtig überprüfen?Haben Sie Code eingegeben, der offensichtlich nicht hätte eingegeben werden sollen, und sie haben ihn trotzdem genehmigt?
Sie können versuchen, einen offensichtlichen (aber harmlosen) Fehler in Ihren Code einzufügen, um festzustellen, ob der Code tatsächlich überprüft wird.
Ich bin mir sicher, dass sie es nicht überprüfen.Ich habe einmal eine Änderung von 10 Dateien mit mehr als 509 Zeilen Codeänderung vorgenommen und es dauerte dann 20 Sekunden, um sie zu genehmigen.Ich mache keine Witze, 20 Sekunden.
Ich möchte wirklich keine Fehler einführen.Ich würde lieber einen anderen Weg gehen.
@mkki Wenn der Code einen Fehler enthält und dieser auf diese Zusammenführung zurückgeführt wird, kann jeder, der für das System verantwortlich ist, zu diesem Zeitpunkt zurückkehren und fragen, ob der Zusammenführungsprozess tatsächlich befolgt wurde, und eine Erklärung anfordern.
@Underverse Leider haben wir noch keine Funktionen für die Öffentlichkeit freigegeben.Ich müsste also noch ein paar Wochen warten, um überhaupt einen Fehler zu finden, der auf eine schlechte Bewertung zurückzuführen ist.
@mkki Bis dahin ist es möglich, dass jemand anderes Ihren Code auscheckt, Änderungen vornimmt, ihn testet und wieder zusammenführt. In diesem Fall kann der Test alles aufgreifen, was Ihre Unit- / Integrationstests verpasst haben.SDLC, Agile oder was auch immer Sie verwenden, es funktioniert immer auf die gleiche Weise.Decken Sie sich ab, stellen Sie sicher, dass Sie getan haben, was Sie können, kennzeichnen Sie es mit dem Management und fahren Sie fort.
Ein häufiges Problem für Unternehmen, die Codeüberprüfungen durchführen, besteht darin, ihren Zweck falsch zu verstehen und zu glauben, dass Senioren sie nicht benötigen.Ich würde das mit deinen Teamkollegen besprechen.
Diese Frage sollte auf Software Engineering SE gestellt worden sein.
@Chris Ich denke, es gibt viele Überschneidungen.Wenn einfach gefragt würde, ob "mein Kollege meine Arbeit überprüfen soll, bevor er sich abmeldet, sich aber ohne Prüfung abmeldet" und die Softwareentwicklung nicht erwähnt, wäre dies hier in Ordnung.
Machst du Retros, um zu besprechen, was du besser machen könntest?Nicht, dass ich jederzeit ein Problem damit hätte, über Codeüberprüfungen zu sprechen, aber eine Retrospektive könnte eine gute Gelegenheit sein, solche Dinge zur Sprache zu bringen.
@JollyJoker in der Tat, es ist buchstäblich das, wofür sie sind!
@mkki versteht vollständig, dass Sie nicht absichtlich einen Fehler einführen möchten.Wie wäre es mit einem Kommentar, der besagt: "Wenn Sie diesen Kommentar während der Codeüberprüfung entdecken, zeigen Sie ihn mkki und er gibt Ihnen 5 $"?Finden Sie bald heraus, ob sie es genau betrachten oder nicht ...
@mkki Obwohl es absolut nicht entschuldigt, die Überprüfung zu überspringen, ist 509 LOC über 10 Dateien etwas zweifelhaft.
Mir scheint, das Problem ist, dass sie so schnell zustimmen, dass sie offensichtlich nichts überprüft haben.Das Fehlen von Kommentaren ist nicht wirklich das Problem.Ich schlage vor, den Titel zu ändern, um den Hauptteil der Frage besser widerzuspiegeln.(Dies ist kein „Verschieben von Torpfosten“ der Frage, da Ihre Frage dieselbe ist. Sie geben einfach eine bessere Zusammenfassung.)
Was ist Ihr Arbeitsorganisationsprozess?Bist du in Agile?Haben Sie Sprints und Rückblicke am Ende der Sprints?Gibt es andere geplante Zeremonien, bei denen Sie Dinge zum Starten / Stoppen / Fortfahren ansprechen können, bei denen dieses Thema sehr relevant wäre?
Empfehlen Sie, dass der Kommentar "Ich bin auch der älteste Entwickler im Team" zu diesem Fragetext hinzugefügt wird.
Frage zum Kommentar "Ich bin auch der älteste Entwickler im Team" - Sie sind vermutlich in Jahren älter, aber sind Sie auch in der Position oder in einer offiziellen Form älter?Wenn eines dieser Punkte ein "Ja" ist, ändert sich * drastisch *, was Sie tun können, um die Unternehmenskultur zu ändern, über die derzeit akzeptierte Antwort "Nur um Kommentare bitten" hinaus.
Typisch typisch typisch in meiner Firma.Die Leute sagen nicht "Können Sie meine PR überprüfen?", Sondern "Können Sie meine PR genehmigen?".Ich bin froh, dass ich in einem kleinen Team arbeite, das sich um die Qualitätsstandards des Codes kümmert. Wir führen die Überprüfung tatsächlich durch und unsere PRs müssen in der Regel 1-3 Mal aktualisiert werden, bevor sie zusammengeführt werden.
Tun sie das auch mit anderen PRs?Machst du selbst PR-Kommentare?Wie die Autoren dann reagieren?
Was ist die offizielle Politik des Unternehmens?Wird von ihnen erwartet, dass sie Ihren Code überprüfen?Oder ist es nur so, dass "Sie Ihre eigene Pull-Anfrage nicht genehmigen können"?
Vierzehn antworten:
#1
+116
SamGibson
2019-05-31 03:35:17 UTC
view on stackexchange narkive permalink

Während die anderen Antworten gut sind, haben Sie in einem Kommentar etwas Neues und Relevantes erwähnt, das möglicherweise das spezifische Verhalten Ihrer Teamkollegen in Ihrem Fall verursacht. Sie sagten:

Ich bin auch der älteste Entwickler im Team

Das könnte hier wichtig sein. In diesem Fall kann ich mir leicht vorstellen, dass Sie mit besonderer Achtung / Respekt behandelt werden und eine Mischung der folgenden Punkte zutreffen könnte (ich habe diese persönlich gesehen):

  • die andere Die Teammitglieder möchten nicht, dass Sie sie als Herausforderung für Ihre Codequalität ansehen. und / oder

  • die anderen Teammitglieder gehen davon aus, dass das, was Sie schreiben, besser ist als das, was sie schreiben, und sie gehen (fälschlicherweise) davon aus, dass dies bedeutet, dass Sie keine Fehler machen, die sie machen könnte finden, selbst wenn sie Ihren Code überprüft haben;

    und daher:

  • sie "stempeln" nur Ihre Pull-Anfragen - was Sie sehen

Dies gilt insbesondere, da Sie:

kürzlich einer neuen Firma beigetreten sind

Da Sie neu im Team sind, wissen sie möglicherweise nicht, dass der Senior -Entwickler immer noch eingehende Überprüfungen von weniger Senior-Teammitgliedern wünscht (nicht alle Senior-Entwickler). Vielleicht hatte Ihr Team zuvor einen leitenden Entwickler, der bei der Überprüfung seines Codes "in die Luft gesprengt" wurde, und so wurden sie darauf konditioniert, dies nicht zu tun?

Ich finde es auch komisch, zu den Entwicklern zu gehen und sie bitten, meine Pull-Anfragen besser zu überprüfen.

Ich schlage vor, ein Teammitglied in einem ruhigen privaten Moment beiseite zu nehmen und ohne Hinweis darauf, dass es etwas falsch gemacht hat, fragen Sie es einfach, warum es Ihren Code nicht eingehender überprüft hat. Und hoffe, dass sie eine ehrliche Antwort geben. Ihre Antwort könnte mit einem meiner obigen Vorschläge übereinstimmen oder etwas Neues hervorbringen, z. Vielleicht haben Sie in der Vergangenheit (unwissentlich) etwas getan, das sie glauben ließ, Sie wollten keine eingehenden Überprüfungen, und deshalb verfolgen sie dieses Missverständnis seitdem?

Ich glaube nicht, dass Sie kenne die Antwort, bis dir jemand in deinem Team sagt, warum er sich so verhalten hat.

Es könnte sich lohnen, alle zusammenzubringen und zu fragen: "Führen wir Codeüberprüfungen durch, und wenn ja, wie läuft das ab?" Oder "Wir scheinen keine Codeüberprüfungen durchzuführen, sollten wir beginnen?".Aber vielleicht sehen sie überhaupt keine Notwendigkeit für sie (hey, Agile macht das, was für das Team funktioniert!) Und haben nach dem Ereignis andere Prozesse für die Codequalität (ich kann nicht beurteilen, ob dies gut oder schlecht ist, das istnicht die gestellte Frage).
@gbjbaanb - "* Es könnte sich lohnen, alle zusammen zu bringen *" Persönlich würde ich * absichtlich * nicht * mit allen zusammen * anfangen.Gruppenzwang kann zu merkwürdigen Ergebnissen führen, z.Personen, die mit den lautesten Sprechern nicht einverstanden sind, dürfen nicht vor ihnen sprechen.Dies kann auch jede Erklärung dafür verhindern, warum derzeit in diesem Team keine Codeüberprüfungen (zumindest die des OP-Codes) durchgeführt werden, insbesondere wenn die Gründe peinlich / persönlich / usw. sind. Deshalb habe ich vorgeschlagen, mit einer ruhigen,privat eins zu eins, um Gruppenzwang zu vermeiden und ihnen die Offenheit zu erleichtern.Wie immer YMMV.
Wenn OP der anerkannte "älteste Entwickler" ist, besteht ihre Aufgabe möglicherweise darin, das Team zu schulen und die Qualität der Arbeit dort zu verbessern.Das Wissen über gute Praktiken zur Codeüberprüfung kann geteilt werden.Ich denke, es könnte erwähnenswert sein, dies als Teil Ihrer Antwort zu betonen, die ansonsten alles abdeckt, was ich sagen könnte.
Ein guter, einfacher Weg, dies zu testen - geben Sie eine Ladung Müll in eine Pull-Anfrage und sehen Sie, wie die Reaktion ist.Wenn es genehmigt wird, können Sie etwas präsentieren, von dem Sie wissen, dass es nicht hätte sein sollen.
Wenn Sie jemanden beiseite ziehen, um darüber zu sprechen, wird sich diese Person wahrscheinlich komisch fühlen, egal wie Sie vorgehen.Es wäre wahrscheinlich besser, auf ein natürlicheres Einzelgespräch zu warten, beispielsweise auf ein Mittagessen / einen Kaffee, und es dann als ungezwungenes Gespräch anzusprechen.
@UKMonkey hat er das schon effektiv gemacht.Wenn eine PR unmittelbar nach ihrer Ausstellung genehmigt wird, bedeutet dies, dass es keine Rolle spielt, was in der PR enthalten war, ob es sich um Müll handelt oder nicht.
Ich würde vorschlagen, ihnen zu sagen, dass Sie konstruktives Feedback zu Ihren PRs benötigen, um sich zu verbessern, anstatt sie zu fragen, warum sie Stempel verwenden.Letzteres kann als anklagend empfunden werden, während Ersteres betont, dass es um Selbstverbesserung geht.
#2
+47
Underverse
2019-05-30 18:46:42 UTC
view on stackexchange narkive permalink

Die kurze Antwort lautet: Nein

Es ist die Aufgabe der Person, die die Zusammenführung ausführt, sicherzustellen, dass der Prozess befolgt wurde. Du hast deinen Job gemacht, jetzt müssen sie ihren machen.

Sie können sich an sie wenden und fragen, warum es keine Kommentare oder Rückmeldungen zu Ihren Pull-Anfragen gibt, wenn Sie der Meinung sind, dass dies der Fall sein sollte. Dies ist eine kulturelle Frage - wie funktioniert Ihr Büro normal? Führen die Leute eine tatsächliche Codeüberprüfung durch? Wie sehen die PRs anderer Leute aus?

PRs von anderen Teams haben jede Menge Kommentare, gute Kommentare, keine Tipps.
Okay, es gibt ein Problem, aber es ist nicht dein Problem.Sie haben keine Kontrolle darüber, was andere tun, und jede Person muss ihren Job machen.Ich schlage vor, diese Informationen zur ursprünglichen Frage hinzuzufügen - Ihre Anfragen unterscheiden sich von denen anderer.
@mkki Mit "anderen Teams" meinen Sie Leute außerhalb Ihres Teams, die PRs machen?In diesem Fall ist es sinnvoll, dass Mitglieder außerhalb Ihres Kerns einer genaueren Prüfung unterzogen werden.
Es kann auch * nicht * das Problem der Person sein, die die Genehmigung vornimmt.Wenn Sie über Ressourcen verfügen, müssen Sie manchmal bewährte Verfahren anhand ihrer Risiken auswählen, um sicherzustellen, dass das Team liefert.Auf die gleiche Weise kann Ihnen die Teilnahme an einem langen, relevanten Schulungsworkshop verweigert werden, um Ihren Code kurz vor Ablauf einer Frist zu verbessern.Das ist wirklich nicht anders.
Hier sehen wir ein Standard-Q & A-Muster für den Arbeitsplatz: Jemand sagt: "In meinem Unternehmen läuft etwas schief. Was soll ich tun?"und die Antwort, die erscheint, lautet: "Tun Sie einfach nichts, es sei denn, Ihre offiziellen Verantwortlichkeiten verlangen dies von Ihnen."Interessiert sich hier niemand wirklich für den Erfolg der Organisationen, für die sie arbeiten?Tut hier niemand etwas, das tatsächlich Auswirkungen auf die Welt hat, so dass Dinge, die schief gehen, zumindest ein wenig * wichtig * sind, auch wenn dies nicht im wörtlichen Sinne "Menschen werden sterben"?Ich werde mich niemals auf diese Idee einlassen, dass man Funktionsstörungen ignorieren sollte, weil es nicht ihre Aufgabe ist, sie zu beheben.
@MarkAmery gut gesagt!Es ist vielleicht nicht immer möglich, die Welt zu einem besseren Ort zu machen, aber wir sollten danach streben.
@MarkAmery Das ist eine noble Einstellung, aber nach ein paar Jahrzehnten, in denen Dutzende wohlmeinender Menschen die Ergebnisse sehen, die * denken *, dass sie wissen, wie man die Arbeit aller anderen besser macht, ist es oft keine * nützliche * Einstellung.Wenn Sie das Unternehmen wirklich in Ordnung bringen möchten, lassen Sie sich zuerst auf eine Ebene befördern, auf der Sie die Befugnis haben, das zu tun, was Sie wollen, und es anderen Menschen aufzuzwingen.
@alephzero Sicher - es ist noch schlimmer, einen Wutanfall über jede Entscheidung und jeden Prozess zu werfen, mit dem Sie nicht einverstanden sind, und sich zu weigern, ihn fallen zu lassen, bis Sie sich durchsetzen.Ein gewisses Maß an Bereitschaft, sich anderen zu widersetzen, ist erforderlich, damit eine Organisation reibungslos funktioniert.Daraus folgt jedoch nicht, dass die richtige Antwort das ist, was diese Antwort befürwortet - überhaupt keinen Versuch zu unternehmen, Dinge zu beeinflussen, die schief gehen, selbst wenn sie in Ihrem eigenen kleinen Team enthalten sind, genau in Ihrem eigenen Fachgebiet liegen und Auswirkungen habendas Ergebnis Ihrer eigenen Arbeit.Der richtige Ansatz liegt irgendwo zwischen diesen beiden Extremen.
@MarkAmery Was Sie nicht sehen, ist, dass Sie, wenn Sie so gut darin sind, Funktionsstörungen in Ihrem Unternehmen zu beheben (Sie sagten, Sie werden Funktionsstörungen nicht ignorieren, auch wenn dies nicht Ihre berufliche Verantwortung war), Ihre Erfahrungen darüber teilen, wie Sie aufgehört habensagte Dysfunktion, anstatt eine andere Stimme hinzuzufügen?Es wird interessant sein zu sehen, wie ein Kollege, der keine Autorität außerhalb der Mitgliedschaft in einem Team hat, das für einen bestimmten Zweck eingestellt wurde, die Organisation zum Besseren verändern kann.
@Dan * "Es wird interessant sein zu sehen, wie ein Kollege, der keine Autorität außerhalb der Mitgliedschaft in einem Team hat, das für einen bestimmten Zweck eingestellt wurde, die Organisation zum Besseren verändern kann?" * - als Schritt 1, indem er vorschlägtdass die Leute die Dinge so machen, wie Sie denken, dass sie gemacht werden sollten, und ihnen sagen, warum.Das ist häufig genug.
@MarkAmery Es ist unklar, ob Sie aus Erfahrung sprechen oder versuchen, einen edlen Gedanken darüber zu formulieren, wie die Dinge sein sollten.Ich glaube nicht, dass Sie aus Erfahrung sprechen, da Sie keine angegeben haben.Menschen zu überzeugen ist schwer und es ist noch schwieriger, wenn Sie keine Autorität dazu haben.
@Dan Ich spreche aus viel Erfahrung.Ehrlich gesagt finde ich das verwirrend.Soll ich daraus schließen, dass Sie noch nie jemandem auf ein Problem hingewiesen haben, das sie dann behoben haben, oder einen Vorschlag gemacht haben, den sie dann umgesetzt haben, ohne zuvor die formelle Autorität über sie erhalten zu haben?Dass jede Idee, die Sie jemals in Ihrer Karriere angesprochen haben, zurückgewiesen wurde, es sei denn, die Person, der Sie sie gegenüber zum Ausdruck gebracht haben, war offiziell Ihr Untergebener?Kollegen und Managern Vorschläge zu machen, wie sie es besser machen können, war etwas, was die Leute in jedem Unternehmen getan haben, in dem ich gearbeitet habe, und es ist unauffällig.
@MarkAmery * "Es war etwas, was die Leute in jedem Unternehmen, in dem ich gearbeitet habe, getan haben, um Kollegen und Managern bessere Möglichkeiten zu bieten, und es ist unauffällig."als Antwort auf diese Frage zu teilen.Da dies ein triviales Problem zu sein scheint (unauffällig, wie Sie es nennen, da es täglich auftritt), können Sie Ihre eigene Antwort erstellen und diese Erfahrung teilen, bei der Sie es geschafft haben, zahlreiche Menschen davon zu überzeugen, Kommentare zu Ihrer PR abzugeben.Es hört sich so an, als würden Sie dem OP eine große Hilfe sein.
Diese Antwort ist ein klares Beispiel dafür, warum Sie Fragen zur Softwareentwicklung auf der Website der Software Engineering SE veröffentlichen sollten.Niemand, der agile Softwareentwicklung versteht, würde Ihnen sagen, dass dies nicht Ihre Aufgabe oder nicht Ihre Verantwortung ist.Sie und Ihr Team sind für Ihren Prozess und dessen Verbesserung verantwortlich.
Als "The Guy", der Pull-Anfragen überprüft und genehmigt, habe ich meinem Team weitgehend gesagt: "Ich werde sicherstellen, dass es keine Konflikte gibt, und wenn ich den Code in den Zielzweig ziehe, ist dies nicht der Fall."Ich werde den Code überfliegen, wenn er nicht zu kompliziert ist, und sicherstellen, dass es so aussieht, als würden Sie die Dinge gut machen, aber zum größten Teil weiß ich möglicherweise nicht unbedingt, was es istSie versuchen es zu erreichen. Ich bin nur hier, um den Meister stabil zu halten. "Es gibt andere Rezensenten (aber ich bin der einzige, der fusioniert) und einen sekundären Überprüfungsprozess, daher sind keine Kommentare (zur PR) eine gute Sache.
@Draco18s Wo es einen automatisierten Prozess für Codequalitäts-, Einheiten- und Integrationstests und eine klare Anzeige von Änderungen mit Unterschieden gibt, sicher.Meine Antwort hier stammt aus der direkten Erfahrung jahrelanger Arbeit mit Menschen, die einen Job haben, der dies nicht tut.Vieles in diesen Kommentaren ist wahr, und dies sollte auf [SE.SO] (https://softwareengineering.stackexchange.com) für die technische Seite sein.Auf der Arbeitsplatzseite ist es genauso wichtig zu wissen, wie man in einem Team arbeitet und ein Teil dieses Teams ist.
@MarkAmery: stimmte zu 100% zu, für dieses Problem ist es mehr als für die meisten anderen schädlich, dies dem Rest Ihres Teams zu * fragen * oder * zu erwähnen *.Sie können es als Diskussionsthema ansprechen, wie "Hey, was machen Sie normalerweise für die Codeüberprüfung, bevor Sie eine Pull-Anfrage zusammenführen? Ich frage mich, ob ich ein zweites Paar Augäpfel auf meinen Code bekommen könnte."Im Gegensatz zu einigen Workplace.SE-Fragen, bei denen es gerechtfertigt ist, nichts zu tun, ist es kein Problem, die Nase in das Geschäft anderer zu stecken.Hier geht es darum, wie sie * mit dir * umgehen.Zumindest deutet diese Antwort darauf hin, mit Menschen zu sprechen.
@Underverse Und jedes Team ist anders.Ich weiß, dass ich * gerne * Unit-Tests verwenden würde (aber in Unity 3D sind sie frustrierend schwierig: Oh, das kann man, aber 80% Ihres Unit-Tests beinhalten die Interaktion mit UnityEngine, die nur möglich istals "Laufzeit-Unit-Test" durchgeführt werden, mit dem man nicht schnell und schrecklich arbeiten kann) und so etwas wie Jenkins, aber ich weiß nicht, wie man Jenkins einrichtet und ausführt.Es gibt nur einen anderen älteren Entwickler außer mir, also fungiere ich im Grunde genommen als Jenkins.Auf jeden Fall habe ich die Kommentare nicht wirklich kommentiert, sondern eher meine eigene Perspektive.
@MarkAmery: Nehmen Sie für einen Moment an, dass Sie nicht wissen, ob Sie das Richtige oder das Falsche tun.Aber Sie haben die Wahl, proaktiv zu sein oder nicht.Wenn Sie proaktiv und richtig sind, großartig!Aber wenn Sie sich irren, macht es nur noch schlimmer, wenn Sie proaktiv sind."Zelot" ist ein Wort mit einer negativen Konnotation, obwohl es sich streng genommen nicht auf richtig oder falsch bezieht, sondern auf den leidenschaftlichen oder proaktiven Ansatz.Kurz gesagt, wenn Sie nicht übermäßig proaktiv sind, werden Sie vor der Möglichkeit geschützt, dass Sie sich irren. Dies wird als übereifrig angesehen und führt zu Problemen (auch wenn dies gut gemeint ist).
@MarkAmery: Ich stimme zu, dass proaktives Handeln der beste Weg ist, um das beste Ergebnis zu erzielen.Aber nicht proaktiv zu sein, schützt Sie vor dem schlimmsten Ergebnis.Besonders in einer Situation, in der Sie aufgrund Ihrer Ergebnisse (und nicht aufgrund Ihrer Absichten) zerkaut werden können, ist es sicherer, sich auf die Seite zu stellen, nicht proaktiv zu sein.Ich mag es nicht, aber es gibt viele Arbeitsplätze, an denen der Gemeinschaftsgeist nicht existiert und die Menschen kaum in der Lage sind, ihre eigenen Ärsche zu bedecken.Ihre Absicht ist nobel, aber ohne Gruppenunterstützung sind Sie nur ein Ziel für jeden, der bereit ist, Ihren guten Willen auszunutzen.
#3
+9
Kevin
2019-05-30 18:45:40 UTC
view on stackexchange narkive permalink

Sie müssen es wahrscheinlich loslassen, bis Sie einen direkten Manager erhalten.

Denken Sie daran, dass die Person, die Ihre Pull-Anfrage genehmigt, versucht, dies zu tun ihre Arbeit "- und anscheinend beinhaltet" ihre Arbeit "in ihren Augen keine langwierige Überprüfung Ihres Codes. Aber das ist das Problem: Sie können sie nicht zwingen , ihre Meinung über den Job zu ändern.

Realistisch gesehen müssen Sie warten, bis jemand die Autorität hat hat die Fähigkeit, die Prioritäten zu bestimmen - und kann dem anderen Programmierer anzeigen, dass Codeüberprüfungen ein Teil dessen sind, was sie tun sollen.

Normalerweise tritt diese Art von Problem so lange auf, bis ein schwerwiegendes Systemproblem das Management dazu veranlasst, sich einzumischen.Nur dann kümmern sie sich darum, weil es sie betrifft.
#4
+9
user168715
2019-05-31 09:04:40 UTC
view on stackexchange narkive permalink

Als führender Entwickler im Team würde ich sagen, dass es Teil Ihrer Verantwortung ist, Erwartungen für den Entwicklungsworkflow Ihres Projekts festzulegen.

Ich habe daran gearbeitet Projekte, bei denen es sich um Kooperationen zwischen erfahrenen und kompetenten Entwicklern handelt, bei denen Pull-Anfragen pro forma sind, es sei denn, ein PR fordert ausdrücklich andere auf, sich den Code genau anzusehen und etwas zu überprüfen. Detaillierte Kommentare und Bewertungen (insbesondere zum Codestil usw.) wurden nicht bei jeder kleinen Änderung erwartet oder begrüßt. Ich habe auch an Projekten gearbeitet, bei denen jede PR, auch einzeilige Fehlerbehebungen, überprüft werden.

In Ihren Schuhen würde ich mit einem höflichen und bescheidenen Schubs Erwartungen setzen, z. B.: "Ich werde Ihnen eine Pull-Anfrage für [Feature X] senden. Ich bin ein wenig unsicher, wie ich das Problem behoben habe [Problem Y]; Könnten Sie bitte einen Blick darauf werfen und mich wissen lassen, wenn Sie ein Problem entdecken? Haben Sie auch Ratschläge, wie ich [Abschnitt Z] umgestalten könnte? Ich denke, es ist möglicherweise schwer zu verstehen und zu pflegen Zukunft, aber ich sehe keine elegante Lösung. "

#5
+7
wberry
2019-05-31 10:20:04 UTC
view on stackexchange narkive permalink

Ich stimme Ihnen zu, dass dies ein Problem ist, aber ich glaube nicht, dass es keine Kommentare gibt. Ich denke, das Problem ist, dass die Pull-Anfragen sofort genehmigt werden. Das bedeutet, dass niemand Ihren Code kritisch überprüft . Und wenn sie Ihren Code nicht überprüfen, überprüfen sie wahrscheinlich auch nicht den Code der anderen. Sie lernen / verbessern sich nicht und schlechter Code landet im Hauptzweig.

Was Sie hier brauchen, sind Verbündete. Finden Sie heraus, wer in diesem Team die Codeüberprüfung ernst nimmt. Setzen Sie die Codeüberprüfung auf die Tagesordnung Ihres nächsten Teammeetings und sprechen Sie darüber. Wenn die Mehrheit auf Ihrer Seite steht, gewinnen Sie eher. Wenn nicht, dann gibt es selbst bei den meisten Start-ups ein gewisses Management. Lassen Sie sie verstehen, dass dieses Problem der "Buddy-Genehmigung" sehr real und eine Bedrohung ist. Zeigen Sie ihnen Beispiele für die sofortige Genehmigung oder sogar für offensichtlich fehlerhaften Code, der nicht abgefangen wurde.

Gehen Sie mit Mehrheits- oder Managementunterstützung zu demjenigen, der das Repository verwaltet, und stellen Sie sicher, dass Regeln für die erforderlichen Code-Repositorys vorhanden sind Mindestens ein vertrauenswürdiger Prüfer (der die Codeüberprüfung ernst nimmt), um eine Pull-Anforderung zu genehmigen, bevor sie zusammengeführt wird. Alle anderen "Buddy-Zulassungen" sind daher weniger wichtig. Ich denke jedoch, dass es immer noch wichtig ist, dass diejenigen, die die Codeüberprüfung nicht ernst nehmen, dies weiterhin tun müssen, in der Hoffnung, dass sie sich verbessern.

Ich habe genau dieses Problem in meinem Team bekämpft, und vertrauenswürdige Prüfer waren meine Lösung. Sie müssen das Repository vor gewöhnlichen "Buddy-Genehmigern" schützen. Nach meiner Erfahrung gibt es wahrscheinlich keine Möglichkeit, den Kampf um die Codequalität zu gewinnen, wenn Sie dies nicht erreichen können. Das Beste, was Sie in diesem Fall tun können, ist, Ihren eigenen Hintern abzudecken und auf die unvermeidliche Katastrophe zu warten, die das Problem erzwingt. Sei nicht derjenige, der die Tasche hält, wenn es passiert. Gehen Sie keine Kompromisse bei Ihrer eigenen Codeüberprüfungsdisziplin ein. Vielleicht reibt sich etwas davon sogar auf ihnen ab. Führen Sie Ihre eigenen Pull-Anforderungen erst zusammen, wenn Sie mehr als die erforderliche Anzahl von Genehmigungen haben. Und stellen Sie sicher, dass Sie bessere und umfassendere Komponententests schreiben als der nächste.

Wenn Sie dies ohne den Anschein von Schuldzuweisungen tun können, dann beim nächsten Mal ein eklatanter Fehler, der im Code hätte gefangen werden müssen Die Überprüfung schafft es in den Hauptzweig (dh Code mit schlechten Anti-Mustern). Bringen Sie es mit dem gesamten Team als Gelegenheit zur Qualitätsverbesserung mit einem erneuten Fokus auf den Codeüberprüfungsprozess zur Sprache. Stellen Sie nur sicher, dass es keine Schuld gibt, oder Sie verletzen nur Ihren eigenen Ruf.

Insbesondere in Bezug auf die Notwendigkeit von Kommentaren denke ich, dass Kommentare im Allgemeinen nur gemacht werden sollten, wenn Sie ein Problem sehen oder eine Frage haben. Wenn die PR gut ist, gibt es keinen Grund, einen Kommentar abzugeben. genehmige es einfach. Wenn eine PR jedoch ohne Kommentare abgelehnt wird, wäre dies meines Erachtens ein Problem, da der Mitwirkende nicht weiß, was geändert werden sollte, um die PR akzeptabel zu machen.

(Und , diese Frage gehört wahrscheinlich in Software Engineering SE.)

Wenn Sie Ihren (bezahlten) Entwicklern nicht vertrauen können, dass sie gute Bewertungen abgeben (mit Schulungen, erklärten Erwartungen, dass sie Bewertungen abgeben usw.), entlassen Sie sie einfach und stellen Sie bessere ein.Ansonsten haben Sie Sally und Bob und Tom und Jane, die den ganzen Tag damit verbringen, das lustige Code-Zeug zu erledigen, und den armen, fleißigen Jim und Joan, die den ganzen Tag damit verbringen, nur Code-Überprüfungen durchzuführen, die den ganzen Tag dauern, weil sie fleißig sind, und dann zu erklärenSteh jeden Morgen auf, dass sie den ganzen Tag Codeüberprüfungen durchgeführt haben und keine Fortschritte bei ihren tatsächlich zugewiesenen Aufgaben gemacht haben. Nein, ich bin nicht bitter (viel).
Ja das.Das Ziel ist es, KEINE Kommentare zu haben.Es ist jedoch wichtig, keine Kommentare zu haben, da der Code gut ist und nicht, weil sich die Prüfer nicht die Mühe gemacht haben, ihn zu überprüfen.
@user3067860 Das von Ihnen erwähnte Problem kann durch Aufgabenabrechnung bekämpft werden.Wenn Ihr Scrum-Tool die Aufschlüsselung von Aufgaben in Storys mit Stunden unterstützt, stellen Sie einfach sicher, dass die Codeüberprüfung in jeder Story eine separate Aufgabe ist und dass die Codeüberprüfung Teil der Definition von "Fertig" ist, und nehmen Sie die genaue Protokollierung der Aufgabenzeit ernst.Jim und Joan werden dann ihre gesamte Kapazität in Codeüberprüfungsaufgaben für die Geschichten einbringen, und die anderen werden als unseriöse Überprüfer entlarvt.Wenn das Management fragt, warum Jim und Joan bei der Codeüberprüfung "zu lange brauchen", ist dies die perfekte Eröffnung für eine Diskussion.
@wberry Aber ich würde lieber aufhören und einen besseren Job bei besseren Mitarbeitern finden, als weiterhin der einzige zu sein, der alle Peer Reviews durchführt, während meine Kollegen die wirklich lustigen Sachen machen können.Außerdem würde ich lieber kündigen und einen besseren Job finden, als die "Stunden nach Stunden" aufzuzeichnen, und wenn der Grund, warum ich die nach Stunden verbrachte Zeit aufzeichnen muss, darin besteht, dass meine Mitarbeiter Jugendliche sind, die ihren Teil des Nicht- nicht leisten können.lustige Arbeit ......
#6
+6
user1666620
2019-05-30 18:46:40 UTC
view on stackexchange narkive permalink

Tun Sie, was ich tue - fragen Sie direkt einen leitenden Entwickler, ob er sich Ihren vorgeschlagenen Änderungssatz ansehen und prüfen kann, ob er damit zufrieden ist. Bitten Sie um Feedback. Ich habe noch keine negativen Erfahrungen mit diesem Ansatz gemacht.

Wenn sie keine Zeit haben, sich Ihren Code anzusehen, werden sie Sie darüber informieren.

Möglicherweise muss ich mich außerhalb meines Teams melden, um dies zu erreichen.
@mkki Ihre Teamkollegen sind mit den Modulen und Codierungsstandards des Projekts, an dem Sie arbeiten, am besten vertraut.
das ist aber das problem.Meine Teamkollegen äußern sich nicht zu meinen PRs.Ich bin auch der älteste Entwickler im Team, also muss ich mich außerhalb unseres Teams melden.
@mkki ah, ich verstehe.Nun, als der älteste Entwickler sollten Sie den Ton angeben.Sprechen Sie mit Ihren Kollegen, erklären Sie ihnen Ihre Bedenken und erinnern Sie sie an den Zweck von Pull-Anfragen und Codeüberprüfungen.Das Problem könnte sehr wohl sein, dass die anderen davon ausgehen, dass Ihr Code in Ordnung ist, weil Sie der älteste Entwickler sind, oder dass sie vorsichtig sein könnten, auf Fehler hinzuweisen.Sie sagen, dass Sie keinen direkten Manager haben - aber jemand muss Ihnen sagen, was Sie tun sollen, oder?Sie arbeiten nicht im luftleeren Raum.
#7
+4
dbeer
2019-05-30 20:48:10 UTC
view on stackexchange narkive permalink

Ich glaube, ich bin hier ein bisschen gegen den Strich, aber ja, das ist ein Problem, und ja, Sie sollten versuchen, Teil der Lösung zu sein. Bevor ich fortfahre, werde ich sagen, dass dies ein schwer zu lösendes Problem ist. Bei Codeüberprüfungen gilt das folgende Prinzip:

Wenn wir die meisten Codeüberprüfungen ohne Eingabe genehmigen, glauben wir, dass wir die Dinge im Allgemeinen beim ersten Mal korrekt ausführen.

Im Allgemeinen ist das eine schlechte Lebensphilosophie. Wir wissen, dass Code, der getestet wurde und als produktionswürdig eingestuft wurde, immer Fehler aufweist. Ich hatte einen Professor am College, der behauptete, es sei ungefähr 1 Fehler pro 100 Codezeilen in der meisten Software, aber ich kann derzeit keine Quelle dafür finden. Außerdem sind Fehler teuer: Einige behaupten, dass ein Fehler 10.000 US-Dollar kostet, wenn er in der -Produktion

gefunden wird. Es lohnt sich, einige Zeit damit zu verbringen, Code zu überprüfen und zumindest Fragen zu stellen.

Was die Lösung des Problems angeht, können Sie offensichtlich keine Menschen zur Veränderung zwingen, da Sie kein Management sind (und natürlich kann das Management die Menschen nicht wirklich zur Veränderung zwingen). Ich empfehle ein paar Dinge:

  1. Überprüfen Sie den Code so, wie Sie der Meinung sind, dass der Code überprüft werden sollte. Erklären Sie den Leuten in den folgenden Gesprächen, warum Sie es so machen, wie Sie es tun, und machen Sie ihnen klar, dass Sie es lieben würden, wenn sie Ihren Code auf die gleiche Weise überprüfen.
  2. Besprechen Sie dieses Problem mit andere, die unter den Ingenieuren Einfluss haben. In einigen Unternehmen sind diese Personen Architekten oder andere leitende Entwickler, aber unabhängig von der Position suchen Sie nach technischen Führungskräften, die andere Ingenieure in Ihrem Team respektieren. Besprechen Sie, was mit dieser Person (diesen Personen) passiert, und versuchen Sie, sie zur Hilfe zu bewegen.
  3. Wenn Sie einen direkten Manager erhalten, sprechen Sie mit dem Manager darüber und überzeugen Sie Ihren Manager, dass dies etwas ist muss sich ändern.
  4. ol>

    Das Erkennen dieser Art von Problemen und der Versuch, sie zu lösen, ist ein wesentliches Unterscheidungsmerkmal zwischen Ingenieuren.

Ich glaube Ihrer Antwort nicht, weil "innerhalb von Sekunden"
@Joshua Ich bin nicht sicher, worauf Sie sich beziehen?
Sie hätten die Pull-Anfrage nicht in kürzerer Zeit als zum Lesen prüfen können.
Ich verstehe nicht, auf welchen Teil meiner Antwort Sie sich beziehen.
#8
+4
user3067860
2019-05-31 19:40:20 UTC
view on stackexchange narkive permalink

Sie müssen herausfinden, warum Pull-Anfragen nicht überprüft werden, bevor Sie entscheiden können, was Sie dagegen tun möchten. Auf den ersten Blick kann es sich um eine beliebige Kombination von Folgendem handeln:

  • Sie werden auf Sie als die Ältesten zurückgestellt.
  • Sie haben einen anderen Prozess, um Code zu überprüfen.
  • Sie haben wirklich schreckliche, unsichere Praktiken und überprüfen niemals den Code.
  • Ihre Pull-Anforderungen sind zu kompliziert, um sie im Tool zu überprüfen.
  • Sie stehen unter dem Druck, sie freizugeben So schnell wie möglich, überspringen Sie ansonsten wichtige Schritte.
  • Sie wissen nicht, wie eine echte Codeüberprüfung durchgeführt werden soll.
  • Sie sind zu faul, um eine echte Codeüberprüfung durchzuführen.

Ich denke, der beste Fall, auf den Sie hoffen könnten, wäre, wenn sie einen anderen Prozess zum Überprüfen komplizierter Commits haben, aber sie haben es Ihnen nicht erklärt und fragen sich leise, warum Sie ihm nicht folgen da bist du älter. In diesem Fall können sie Ihnen bei einem kurzen Gespräch erklären, wie sie Ihnen die Codeüberprüfung durchführen ... und ich würde empfehlen, zumindest einen ehrlichen Versuch zu unternehmen, bevor Sie sofort erklären, dass Ihr Weg besser ist.

Ich denke, der wahrscheinlichere, unglücklichere Fall sind keine guten Praktiken, keine besseren Kenntnisse und der Versuch, Schritte zu überspringen, um Zeit oder Mühe zu sparen. Dann ist es Ihre Aufgabe als Ältester, sie zu unterrichten und bewährte Verfahren zu fördern (möglicherweise sogar bewährte Verfahren durchzusetzen, wenn Sie als Führungskraft eingestellt wurden). Sie müssen wahrscheinlich eine Weile als Gruppe Codeüberprüfungen durchführen, um Ihre Erwartungen hinsichtlich der Gründlichkeit festzulegen. Und Sie müssen Ihre Geschwindigkeit anpassen, da Sie für eine Weile viel Zeit mit Codeüberprüfungen verbringen werden. (Sie machen es später wieder gut, indem Sie keine Zeit mit Fehlerkorrekturen verbringen müssen, aber ohne veröffentlichtes Produkt ... yikes.)

#9
+3
Blueriver
2019-05-31 21:48:35 UTC
view on stackexchange narkive permalink

Wenn Sie in einer agilen Umgebung arbeiten, liegt dies in Ihrer Verantwortung sowie im Rest des Teams. Ihr seid für euren eigenen Prozess verantwortlich, ihr besitzt eure Arbeit, ihr seid ein selbstorganisierendes Team fähiger Softwareentwickler und solltet euch auf jede erdenkliche Weise verbessern, sowohl einzeln als auch als Team.

Das Hauptproblem hierbei ist, dass sie entweder nicht den Prozess der Überprüfung jeder Codezeile verfolgen oder der Prozess nicht genau definiert ist (zum Beispiel heißt es nur, dass PRs genehmigt werden müssen, nicht dass die Änderungen muss tatsächlich überprüft werden). In jedem Fall müssen Sie entscheiden, wie Sie von nun an arbeiten möchten, einen Prozess definieren, auf den Sie sich alle einigen, ihn möglicherweise aufschreiben (hauptsächlich für zukünftige Einstellungen), sich dazu verpflichten, dem Prozess zu folgen, für den Sie sich gerade entschieden haben, und Tu es. Es liegt in der Verantwortung jedes einzelnen Teammitglieds, einschließlich Ihnen, dies zur Sprache zu bringen. Einige (zum Beispiel Junioren) bemerken diese Gelegenheit möglicherweise nicht, um Ihre Arbeitsweise zu verbessern. Bringen Sie sie daher selbst zur Sprache und bringen Sie ihnen bei, warum dies für das gesamte Team (besserer Code, weniger Fehler) und für Sie als Einzelperson (Lernen) gut ist Schreiben Sie besseren Code) und sie als Einzelpersonen (gewöhnen Sie sich daran, den Code anderer zu lesen, lernen Sie, wie gut geschriebener Code aussieht).

Wie andere bereits erwähnt haben, könnte dies damit zusammenhängen, dass Sie der älteste Entwickler sind . Einige denken vielleicht, dass es schlecht ist, Sie zu befragen, und erkennen nicht, dass dies eine großartige Gelegenheit für sie ist, zu verstehen, warum Sie (die meisten) Dinge besser machen als sie und wie Sie über Probleme denken, um (meistens) bessere Lösungen zu finden. Lehre sie das. Bemühen Sie sich außerdem um eine sichere Umgebung, in der sie, selbst wenn sie Gelegenheiten wie diese manchmal nicht klar erkennen, alles und jeden in Frage stellen können, ohne befürchten zu müssen, dass sich die andere Person angegriffen fühlt. Vielleicht möchten Sie sich fragen, wie andere Teams in Ihrem Unternehmen das tun und wie Sie das erreichen können.

#10
+1
gnasher729
2019-05-30 22:48:20 UTC
view on stackexchange narkive permalink

Ihre Arbeit sollte ordnungsgemäß überprüft werden, bevor sie angenommen wird. Da Ihr Kollege dies anscheinend nicht tun möchte, müssen Sie Ihren Code selbst überprüfen. Es ist trotzdem eine gute Idee, dies zu tun. Je besser der Code ist, den Sie von anderen überprüfen lassen, desto besser für Ihren Ruf und desto weniger Arbeit für alle.

Das bedeutet nicht, dass Sie ihn nicht dazu bringen sollten, Ihren Code ordnungsgemäß zu überprüfen.

Offensichtlich muss ein Entwickler seinen eigenen Code überprüfen, der Prozess ist Teil der normalen Entwicklung.Und ich denke, "ihn dazu bringen, Ihren Code richtig zu überprüfen" ist nicht hilfreich.
#11
+1
Egor
2019-05-31 06:20:23 UTC
view on stackexchange narkive permalink

Einige Dinge aus persönlicher Erfahrung, die bei Ihrem Problem helfen können:

  • Halten Sie PRs klein und einfach. Das Überprüfen einer kleinen PR, die ein einzelnes, genau definiertes Problem löst, ist viel einfacher als das Durchlaufen vieler verschiedener Änderungen in mehreren Dateien. Je größer die PR, desto wahrscheinlicher ist es, dass Ihre Kollegen sie durchblättern und wichtige Änderungen übersehen.
  • Wenn es bestimmte Änderungen gibt, zu denen Sie Feedback wünschen, kommentieren Sie diese und erläutern Sie Ihre Bedenken. Dies macht die Leute auf die Änderung aufmerksam und fordert sie auf, ihre Meinung mitzuteilen.
  • Markieren Sie mehr Personen in Ihren PRs und benötigen Sie vor dem Zusammenführen mindestens 2 oder 3 Genehmigungen.
#12
+1
Adam Smith
2019-06-01 00:34:08 UTC
view on stackexchange narkive permalink

Mein Arbeitgeber weist jedem Projekt zwei technische Leads zu. Einer ist der gleichnamige "Engineering Lead", der für die Beauftragung des Projekts und die direkte Beantwortung der Produktion und der Qualitätssicherung verantwortlich ist und im Wesentlichen ein "Buck Stopps hier" -Typ ist. Der andere ist ein "Principal Engineer", dessen Aufgabe im Wesentlichen darin besteht, "der Typ zu sein, der alles weiß".

Principal Engineers legen häufig architektonische Richtlinien für das Projekt fest und schreiben vor, dass bestimmte Technologien verwendet (oder nicht verwendet) werden. und Best Practices in der Codebasis durchsetzen. Bis zu einem gewissen Grad ist diese Codebasis ihr Baby und sie sollten keinen Makel auf der Schale einer der vielen vielen Schildkröten zulassen. Zu diesem Zweck sollte der Auftraggeber selbst einen angemessenen Anteil der eingehenden PRs überprüfen oder zumindest die Bewertungen .

Wenn Sie einen Ingenieur in einem haben In ähnlicher Weise empfehle ich dringend, dass Sie sich mit Ihren Bedenken an sie wenden. Sie scheinen begründet zu sein. Wenn Sie dies nicht tun, empfehle ich dringend, dass Sie diese Rolle (angesichts Ihres Dienstalters) selbst mit dem Buy-off Ihres Abteilungsleiters ausfüllen.

#13
+1
Wayne Werner
2019-06-01 02:30:20 UTC
view on stackexchange narkive permalink

Hier gibt es viele gute Antworten, aber ich habe niemanden bemerkt, der dies in Ihrer PR vorgeschlagen hat:

  • Erwähnen Sie, was Sie behoben haben
  • Erwähnen Sie, wie Sie getestet
  • Bitten Sie sie, sich bestimmte Dinge anzuschauen

Eine andere Sache, die Sie tun könnten, und ich mache dies mit meinen eigenen PRs, ist Nachdem Sie Ihre PR eingereicht haben, überprüfen Sie sie selbst .

Das bedeutet, dass Sie Ihren Hut "Ich habe das geschrieben" abnehmen und Ihren Hut "Jemand anderes hat das geschrieben" aufsetzen / p>

Stellen Sie sich vor, es sei Ihr jüngster Entwickler im Team, der den Code geschrieben hat, und überprüfen Sie den Code genau so, wie Sie es erwarten würden. Kommentieren Sie Ihre PR so, wie Sie es von Leuten erwarten würden.

Bei der Überprüfung meines eigenen Codes habe ich einige Male festgestellt, dass ich vergessen habe, Code zu reparieren / zu debuggen Ich habe vergessen zu entfernen.

Es klingt auch so, als ob Sie einen kulturellen Wandel haben, den Sie vornehmen müssen. Als leitender Entwickler haben Sie etwas Gewicht zu werfen, aber Sie müssen sich entscheiden, ob Sie das politische Kapital ausgeben möchten, um Dinge per Fiat zu fordern, oder ob Sie die Zeit verbringen möchten, um die Teamfähigkeiten aufzubauen, die Sie suchen . Letzteres ist wahrscheinlich effektiver, obwohl es länger dauern kann.

#14
+1
Level River St
2019-06-01 13:50:59 UTC
view on stackexchange narkive permalink

Da dies Workplace.SE und nicht Software Engineering SE ist, werde ich diese Frage unter dem allgemeinen Gesichtspunkt "New Engineering Hire" beantworten.

Sie haben einen neuen Job in einem kleinen Team. Als solches benötigen Sie eine Anleitung, wie die Dinge in diesem Unternehmen und in dem Projekt, an dem Sie arbeiten, erledigt werden. Aber als kleines Team, das sich wahrscheinlich bis zu Ihrer Einstellung damit abfinden musste, unterbesetzt zu sein, ist es wahrscheinlich, dass es einen Arbeitsstau gibt, der erledigt werden muss. Hast du das gefragt?

Wir haben einen neuen Mitarbeiter in unserem Unternehmen (Engineering, keine Software). Zuerst wurde ihm nur ein Projekt zugewiesen - eines meiner Projekte - und er war eindeutig frustriert, dass er nicht die Aufsicht erhielt, die er gerne hätte . Aber ich hatte dringende Dinge zu tun (da wir seit einigen Monaten unterbesetzt sind) und konnte ihm nur bei Dingen helfen, die JETZT perfekt erledigt werden müssen (d. H. Dinge, die außerhalb des Unternehmens an den Kunden und die Lieferanten gingen). Er nahm es proaktiv auf sich, eine Stückliste für den unternehmensinternen Gebrauch für das Projekt zu erstellen (nicht auf dem Firmenformular, da ihm nicht gezeigt wurde, wo es sich befand). Sein Format stellte sich als enorme Verbesserung des Firmenformulars heraus Ich sagte ihm, er solle dabei bleiben, aber einige Anpassungen am Inhalt vornehmen. Er hat jetzt mehrere Projekte zu bearbeiten, damit das Problem behoben ist. Tatsächlich ist er nur ein paar Wochen später zu beschäftigt, um meine Anleitung zu akzeptieren, wenn ich sie anbiete, und wir müssen einen für beide Seiten geeigneten Zeitpunkt festlegen.

Punkt ist, Sie müssen herausfinden, ob das, was passiert, eine vorübergehende Situation ist oder ob es das ist, was sie immer dort tun. Sie haben eindeutig das Gefühl, dass das Schreiben von "ihrem Code" in ihrer Verantwortung liegt und wichtiger ist als das Überprüfen von "Ihrem Code", was eindeutig falsch ist. Dokumentieren Sie, was passiert, damit Sie, wenn sich jemand beschwert, dass Ihr Code nicht funktioniert oder den Unternehmensstandards entspricht, mit "Ich war neu im Unternehmen und niemand hat mir eine Anleitung gegeben" kontern können. Das ist das Beste, was Sie tun können.



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