Ab wann ist „konstruktive“ Kritik an Ihrem Code nicht mehr hilfreich?


39

Ich habe vor kurzem als Junior-Entwickler angefangen. Ich bin nicht nur eine der am wenigsten erfahrenen Personen im Team, sondern auch eine Frau, die alle möglichen Herausforderungen in einem von Männern dominierten Umfeld bewältigt. Ich hatte in letzter Zeit Probleme, weil ich das Gefühl habe, zu viel ungerechtfertigte pedantische Kritik an meiner Arbeit zu bekommen. Lassen Sie mich Ihnen ein Beispiel geben, was in letzter Zeit passiert ist.

Der Teamleiter war zu beschäftigt, um einige von mir hergestellte Filialen einzuschieben, sodass er sie erst am Wochenende erreichte. Ich überprüfte meine E-Mails, die eigentlich keine Arbeit bedeuteten, und stellte fest, dass meine beiden Zweige auf der Grundlage von Variablennamen abgelehnt wurden, wodurch Fehlermeldungen aussagekräftiger wurden und einige Werte in die Konfigurationsdatei verschoben wurden.

Ich halte es nicht für sinnvoll, meine Branche auf dieser Grundlage abzulehnen. Viele Leute arbeiteten über das Wochenende und ich hatte nie gesagt, dass ich arbeiten würde. Einige Personen wurden wahrscheinlich blockiert, weil ich keine Zeit hatte, die Änderungen vorzunehmen und erneut einzureichen. Wir arbeiten an einem Projekt, das sehr zeitkritisch ist, und es scheint mir nicht hilfreich zu sein, Code vollständig abzulehnen, basierend auf Dingen, die für den Client transparent sind. Ich kann mich irren, aber es scheint, dass diese Dinge in Patch-Commits behandelt werden sollten, wenn ich Zeit habe.

Nun kann ich sehen, dass dies in einigen Umgebungen die Norm ist. Die Kritik scheint jedoch nicht gleichmäßig verteilt zu sein, was zu meinem nächsten Problem führt. Die Grundlage für die meisten dieser Probleme war die Tatsache, dass ich mich in einer Codebasis befand, die jemand anderes geschrieben hatte, und versuchte, minimal invasiv zu sein. Ich ahmte die Variablennamen nach, die an anderer Stelle in der Datei verwendet wurden. Als ich das sagte, wurde mir unverblümt gesagt: "Ahme andere nicht nach, tu einfach, was richtig ist." Dies ist vielleicht die am wenigsten nützliche Sache, die mir hätte gesagt werden können. Wenn der bereits eingecheckte Code nicht akzeptabel ist, wie soll ich dann feststellen, was richtig und was falsch ist? Wenn die Basis der Verwirrung aus dem zugrunde liegenden Code stammte, glaube ich nicht. '

Ich fühle mich in dieser Situation wirklich ausgelassen und frustriert. Ich bin viel besser darin geworden, die erwarteten Standards zu befolgen, und ich bin frustriert, dass ich, wenn ich zum Beispiel einen zuvor fehlenden Code für die ADD-Fehlerprüfung überarbeite, nur das Gegenteil davon erfahren habe Machen Sie die Fehler ausführlich genug (und die Verzweigung wurde auf dieser Grundlage abgelehnt). Was wäre, wenn ich es noch nie hinzugefügt hätte? Wie ist es in den Code gekommen, wenn es so falsch war? Deshalb fühle ich mich so herausgehoben: Ich treffe ständig auf diesen bestehenden problematischen Code, den ich entweder nachahme oder überarbeite. Wenn ich es nachahme, ist es "falsch", und wenn ich es überarbeite, werde ich dafür getadelt, dass ich nicht genug tue (und wenn ich den ganzen Weg gehe, Fehler einführe, usw.). Wiederum, wenn dies ein solches Problem ist, verstehe ich nicht, wie Code in die Codebasis gelangt.

Wie gehe ich damit um? Bitte denken Sie daran, dass ich oben gesagt habe, dass ich eine Frau bin, und ich bin mir sicher, dass diese Jungs sich normalerweise keine Sorgen um Anstand machen müssen, wenn sie den Code anderer Jungs überprüfen, aber ehrlich gesagt funktioniert das bei mir nicht und das führt dazu, dass ich weniger produktiv bin. Ich mache mir Sorgen, wenn ich mit meinem Manager darüber spreche, wird er denken, dass ich nicht mit der Umwelt umgehen kann.


18
Ich bin ein junger Mann (in dieser Firma) und ich habe mich in einer ähnlichen Doppelmoral gefühlt. Die Codebasis sieht oft beschissen aus, und dennoch wird von mir erwartet, dass ich einem viel höheren Standard folge. Nun, es stellte sich heraus, dass Mist durch "Todesmärsche" reingekommen ist, die in der Vergangenheit gemacht wurden. Außerdem sehe ich anscheinend 5 Jahre jünger aus als ich bin. Als meine Kollegen mein wirkliches Alter herausfanden, wurde ich über Nacht viel schlauer. Menschen sind unvollkommene Affen. Es hilft, wenn Sie mit ihnen zu Mittag essen und über ihre Witze lachen, aber übertreiben Sie es nicht. Jungs interpretieren ALLES als Flirt.
Job

4
@Job: Nun, wenn die Codebasis Mist ist, sollte es besser sein, daher müssen Ihre Commits einen höheren Standard haben. Sonst wäre es noch beschissener geworden, oder? :)
Macke

@Marcus, du hast recht, aber was wirklich hilfreich wäre, wenn die Regeln klar formuliert und für alle die gleichen Regeln gelten würden. Außerdem gibt es etwas zu sagen, was das Einfügen in dieselben Codestandards angeht, wie der Fragesteller erwähnt hat. Ich habe gesehen, wie ein Junior als Sündenbock entlassen wurde. Das Management beschwerte sich, dass die Ingenieure zu viele Fehler produzierten. Die Ingenieure konnten keine anständige Arbeit leisten, weil das Management ihnen feste Fristen gibt. Wenn also etwas schief geht, gibt es immer einen jungen Mann, der die meisten Fehler begangen und losgelassen hat. en.wikipedia.org/wiki/Dedovshchina
Job

3
Eine Sache, die mir auffiel, war: "Sie sind an Jungs gewöhnt, damit sie keinen Anstand benutzen." Ich würde sagen, Sie müssen das absaugen, es sei denn, es handelt sich eindeutig um Diskriminierung. Würden Sie auf eine Baustelle gehen und erwarten, dass Sie anders behandelt werden als der Rest der Gestalter? Abhärten. Wenn Sie in einem von Männern dominierten Umfeld arbeiten, müssen Sie in der Lage sein, die unterschiedlichen sozialen Normen genauso zu bewältigen und sich an diese anzupassen wie sie. Sei nicht so "empfindlich".
Rig

1
Ich weiß, dass dies einige Jahre zu spät ist, aber ich denke, dass dies ein wichtiges Thema für zukünftige Leser ist. Schließen Sie nicht die Möglichkeit aus, dass Ihr Teamleiter es einfach besser weiß. Er ist wahrscheinlich älter und hat ein Gespür für problematische Stilprobleme entwickelt. Ich fordere jeden in dieser Situation auf, dies als Gelegenheit zum Lernen und Wachsen zu betrachten. Bitten Sie respektvoll um Klärung von Fragen, die Sie nicht verstehen, und achten Sie darauf, die trockene Persönlichkeit eines Kollegen nicht als böswillig zu interpretieren.
weberc2

Antworten:


41

Es besteht die Möglichkeit, dass Sie als Frau ausgewählt werden, aber es ist auch möglich, dass Sie nur ein Junior-Entwickler sind und neu im Job sind.

Fehlerprüfung und aussagekräftige Meldungen sind wichtig. Wenn Sie dem Code etwas hinzufügen möchten, stellen Sie sicher, dass es den Standards des Teams entspricht. Wenn Sie den Code einer anderen Person ändern, versuchen Sie, ihn nach Möglichkeit zu verbessern. Schreiben Sie das Ganze nicht neu, sondern lassen Sie es ein wenig sauberer, als Sie es vorgefunden haben.

Gibt es eine schriftliche Version der Kodierungsstandards, die Ihr Team befolgt? Wenn nicht, ist es möglicherweise eine gute Idee, alles aufzuschreiben. Sie können den Aufwand vorantreiben, indem Sie die Fehler, die Sie machen, aufschreiben und zu einer Checkliste zusammenfassen, auf die Sie sich beziehen können, bevor Sie Ihre Änderungen zur Überprüfung einreichen. Als Nebeneffekt können Sie diesen schriftlichen Standard verwenden, um gegen zukünftige Ablehnungen Widerspruch einzulegen.

Es hört sich so an, als gäbe es einen Mangel an Verständnis zwischen Ihnen und dem Teamleiter. Es kann hilfreich für Sie sein, ein persönliches Gespräch mit ihm anzufordern und zu besprechen, was Sie tun können, um sich zu verbessern. Sie können mit etwas wie "Ich habe das Gefühl, dass mir immer noch viele Feinheiten fehlen, was ich tun soll. Als Junior-Entwickler möchte ich wachsen und mich verbessern. Können Sie mir dabei helfen, dorthin zu gelangen?" und sehen, was passiert.


Annas Antworten sind im Allgemeinen sehr vernünftig. +1. Ich denke, das Arbeiten dort, wo du arbeitest, würde mich verrückt machen. Ist es Ihrem Management nicht wichtig, Termine einzuhalten? Wenn der Code funktioniert, versenden Sie ihn. Räumen Sie später auf. Du könntest es sogar am Montag aufräumen und in der nächsten Veröffentlichung durchziehen. Dieses Verhalten Ihres Managers würde niemals an meinem Arbeitsplatz auffliegen, und ich bin froh, dass ich mich darauf konzentrieren kann, Termine einzuhalten, anstatt Politik zu betreiben. Ich hoffe, Ihre Situation wird besser und Sie finden eine Lösung. :)
jmort253

11
@ jmort253 Danke. :) Das heißt, "Wenn der Code funktioniert, versende ihn" kann eine gefährliche Einstellung sein. Arbeitscode ist nicht immer guter Code (obwohl er auf jeden Fall besser ist als fehlerhafter Code), und die Codequalität ist langfristig wichtig. Ein späteres Aufräumen passiert so gut wie nie, da andere Fristen angezeigt werden und dringendere Dinge auftauchen. Es gibt einen Begriff dafür - "technische Schulden".
Adam Lear

@Anna, stimmen Sie der Wichtigkeit von konformem Code zu. Ich habe gelesen, dass es für Linus Thorvalds ausreicht, einen nicht konformen Code zu verwenden, um einen eingereichten Patch für Linux sofort abzulehnen (aber ich kann ihn derzeit nicht finden).

@ Anna / Thorbjorn - Manchmal muss man nur tun, was der Kunde will, wenn es eine Frist gibt. Ihr Kunde wird nicht sehr verständnisvoll sein, wenn er Einnahmen im Wert von 15.000 US-Dollar einbüßt, weil Sie lediglich Kapitalisierungsfehler beseitigen wollten. Leider ist der Versuch, 100% der technischen Schulden zu beseitigen, nicht immer möglich. Es wäre ähnlich wie 40 Jahre zu warten, um genug Geld zu sparen, um Ihr Traumhaus zu kaufen, anstatt eine Hypothek aufzunehmen. Sicher, Sie wären frei und klar, aber Sie hätten Ihr ganzes Leben damit verbracht, sich mit schattigen Vermietern auseinanderzusetzen.
jmort253

Open Source-Projekte unterscheiden sich von Profit-Projekten. Viele Open Source-Projekte können es sich leisten, strengere Standards zu haben, weil nicht immer Gewinn zu haben / zu verlieren ist. Proprietäre Projekte haben unterschiedliche Ziele, und manchmal haben diese Geschäftsziele Vorrang. Ich sage nicht, dass Code nicht konform sein sollte, nur, dass Sie manchmal nur das tun müssen, was Sie tun müssen, und die Disziplin haben, das Problem nach der Bereitstellung zu beheben.
jmort253

25

Es hört sich so an, als würdest du dieses Zeug ein bisschen zu persönlich nehmen. Nicht; So etwas passiert die ganze Zeit.

Die Gründe für die Ablehnung Ihres Check-ins (Variablennamen, Kommentarqualität, Konfigurationsort) erscheinen mir ziemlich normal.

Der Zeitpunkt dafür war die Entscheidung Ihres Teamleiters, und ich würde mir keine Sorgen machen, wenn ich Sie wäre. Wenn jemand über das Wochenende gesperrt ist, kann der Teamleiter das Einchecken zulassen und Sie bitten, das Problem anschließend zu beheben. Wenn er es für angebracht hielt, es zurückzutreten, obwohl es andere Entwickler blockieren könnte, liegt das in seiner Verantwortung.

Was den Teamleiter angeht, der Ihnen sagt, dass Sie andere nicht imitieren, sondern das Richtige tun sollen, scheint es, als würde er versuchen, Ihnen eine Initiative zu geben, um die Codebasis zu verbessern. Das ist ein gutes Zeichen. Er vertraut darauf, dass Sie Ihr Urteilsvermögen einsetzen. Machen Sie also weiter und tun Sie, was Sie wissen, dass es richtig ist. Das bedeutet nicht, dass Sie den Code aller anderen ändern müssen, aber Sie sollten die Verantwortung für die Qualität des Codes übernehmen, den Sie schreiben.


2
+1 Sie konzentrieren sich auf die Beziehungen und Emotionen. Die Programmierer, mit denen Sie arbeiten, klingen sehr trocken, konzentrieren sich jedoch nur auf die Code-Probleme. Das ist ziemlich häufig in Programmierumgebungen, in denen ich gearbeitet habe. Ich habe das übrigens unabhängig vom Geschlecht gesehen.
Michael Durrant

14

Eine Ergänzung zu den anderen Antworten:

Als leitender Entwickler bin ich in der Regel wählerischer bei den Junior-Entwicklern, weil sie viel geschmeidiger sind als die Leute, die seit einigen Jahren arbeiten. (Meine ppl Fähigkeiten sind noch nicht so gut ...)

Es ist sehr schwer, jemanden zu ändern, der eine Weile gearbeitet hat (und ein anständiges Gehalt verdient) und mit seiner Code-Ebene zufrieden ist (obwohl die Qualität verbessert werden könnte). Diesen Jungs ist es egal, ob Sie versuchen, sie zu besseren / großartigen Programmierern zu führen. Sie arbeiten gerne in der Code-Factory.

Neue Leute wie Sie, OTOH, sehnen sich normalerweise nach Anleitung und wissen, was richtig ist und was nicht. Außerdem sind sie in der Lage, Rückschläge zu absorbieren und ihre Verhaltensweisen zum Besseren zu verändern. Sie sind nicht auf andere Weise festgelegt.

Wenn Sie sich diese Ratschläge zu Herzen nehmen und sie zu einem Teil Ihres Alltags machen, werden Sie feststellen, dass Sie in kürzester Zeit Code schreiben werden, der einem Großteil der vorhandenen Codebasis überlegen ist.

So ...

Es könnte sein, dass Sie mehr Feedback erhalten, nur weil Sie das Potenzial haben, etwas daraus zu machen. :)


Dies wirft viele gute Punkte auf.
Sevenseacat

13

Es ist durchaus möglich, dass Sie ausgewählt werden, weil Sie ein Junior-Entwickler sind.

Ihrer Beschreibung zufolge haben Sie den Standard nicht befolgt, da der Teamleiter dies wahrnimmt .

Die Lösung ist einfach:

  • Wenn dies der Standard ist, befolgen Sie ihn.
  • Wenn Sie den Standard nicht verstehen, bitten Sie um Klarstellung.
  • Wenn Ihre Interpretation des Standards oder der Anweisungen von der des Teamleiters abweicht, bitten Sie um Klärung

Mach keinen Kampf daraus; Wenn du versuchst, die Mannschaft "falsch" zu führen, verlierst du, auch wenn du gewinnst. Lerne die passende Lektion und wachse weiter.


1
Der Versuch, einem "Standard" bis zum "T" zu folgen, wenn man es mit Dorken zu tun hat, wie sie es beschreibt, bringt nicht viel. Es wird ein endloser Streit über Definitionen und Semantik sein.
MrDatabase

4
@ MrDatabase Sie klingen für mich nicht sehr nach Dorks. Ein bisschen wählerisch vielleicht, aber der Teufel steckt oft im Detail und sobald Sie anfangen, Ihre Standards zu verlieren, kann Ihre gesamte App schnell bergab gehen.
Adam Lear

3
Es ist wahr, dass Standards eingehalten werden sollten. Sie zeigt jedoch deutlich, dass es sich nicht wirklich um einen Standard handelt (frühere Entwickler hielten sich nicht daran). Daher sind ihre Kollegen, die ihr den "Standard" aufzwingen (ohne etwas zu sagen wie "Hey, sieh mal ... wir wissen, dass er inkonsistent scheint, aber wir versuchen wirklich, unsere Codebasis zu verbessern"), scheinheilig und nicht hilfreich. Wenn Kollegen so handeln, müssen Sie einen anderen, intelligenteren Ansatz wählen.
MrDatabase

@ user15859: wenn du dich auf meine antwort beziehst, war das überhaupt nicht meine absicht. Ich glaube, ich habe genau das gesagt, was Anna in ihrer Antwort gesagt hat. Es war keine Beleidigung beabsichtigt. Die von Ihnen genannten Verstöße gegen Standards sind wichtig für die langfristige Wartung. Unklarheiten bei der Anwendung der Standards müssen mit Ihrem Teamleiter beseitigt werden. Wenn du faul wärst, hättest du nicht hier gepostet. Wenn Sie inkompetent wären, würde es Sie nicht so sehr interessieren. Ich glaube nicht, dass Sie einer von denen sind.
Steven A. Lowe

1
Ich denke, sie bezieht sich auf das, was Woot4Moot gesagt hat, als er in seinem Kommentar "Faulheit und Inkompetenz" verwendete. Ich denke, Ihre Antwort ist in Ordnung, da sie dem OP einen gewissen Rückgriff und Handlungsspielraum gibt, der auf ihrer Interpretation dessen beruht, was wirklich vor sich geht.
jmort253

10

Anmerkung des Verfassers

Ein paar Jahre später; Ich habe dies bearbeitet, um genauer zu reflektieren, wie ich die Situation einschätze. Ich füge meiner Antwort mehr Nuancen hinzu, weil ich in diesen Situationen mehr über Nuancen lerne. Es ist leicht, eine "schwarz oder weiß" Antwort zu erhalten, aber wir alle wissen, dass es nicht so einfach ist. Meine Antwort spiegelt dies jetzt wider.

Nach dem, was Sie beschrieben haben; Das von Ihnen erlebte Verhalten scheint nichts mit Ihrem Geschlecht zu tun zu haben. Das heißt nicht, dass Sie keine geschlechtsspezifische Behandlung erfahren (ich hoffe, dass Sie dies nicht tun), nur, dass das, was Sie beschreiben, nicht geschlechtsspezifisch zu sein scheint.

Als Teamleiter habe ich alle gleich behandelt. Es gibt keinen Platz in der Technik, um jemanden aufgrund seines Geschlechts schlecht zu behandeln. Ich weiß nicht, wie ich damit umgehen soll, wenn es dir passiert.

Es ist wichtig, dass Sie darauf vertrauen, dass Ihr Teamleiter Männer und Frauen gleich behandelt. Wenn es Beweise dafür gibt, gilt das alte Sprichwort: Ändere deine Umgebung oder ändere deine Umgebung.

Gleichermaßen meine ich, dass er alle gleich behandelt, ohne Rücksicht auf das Geschlecht. Wenn er seine Arbeit richtig macht, sollten Sie nicht sehen, dass er jemand anderen kritisiert. und sie sollten nicht sehen, wie er dich kritisiert. Vor anderen ist es für den Teamleiter sehr wichtig, Vertrauen zu zeigen, auch wenn er nur die letzten fünf Minuten damit verbracht hat, das Verhalten privat zu korrigieren.

Nun zu den Themen, die Sie angesprochen haben:

Sie haben Code eingecheckt, der nicht dem von ihm festgelegten Standard entspricht, sodass er Ihre Filiale abgelehnt hat. Wenn ich in seinen Schuhen stecke, hätte ich nicht dasselbe auf die gleiche Weise getan, aber ich würde dafür sorgen, dass meine Untergebenen (seltsames Wort; ich denke nicht, dass ein Führer den Menschen, die sie sind, überlegen ist) führen, aber es beschreibt die Situation genau (nicht angemessen)) wissen, was das Richtige ist. Wenn sie die Standards nicht kennen, ist das meine Schuld als Anführer. Es liegt an mir, das zu korrigieren. In diesem Fall haben Sie vielleicht einen Fehler gemacht, aber die bloße Tatsache, dass es passiert ist, bedeutet, dass Ihnen entweder 1) nicht gesagt wurde, was das Richtige zu tun war, oder 2) nicht angemessen betreut wurde. Weder ist deine Schuld.

Einer der wichtigsten Aspekte eines Programmierers ist die Erkenntnis, dass die Codebasis, an der Sie arbeiten, von vielen verschiedenen Personen gewartet werden muss. Alle variablen Messups oder andere Dinge, die das Lesen des Codes beeinträchtigen, sind für den Kunden nicht transparent , da das Beheben von Problemen in schwer lesbarem Code länger dauert.

Wenn Ihr Team Kodierungsrichtlinien erstellt hat, befolgen Sie diese. Wenn dies nicht der Fall ist, sollte es eine Art Community-Konvention für Ihre Sprache geben (für .NET und C # hat Microsoft einen Standard , dem viele Unternehmen folgen).

Fragen Sie Ihren Teamleiter nach den Kodierungsrichtlinien, damit Sie sicherstellen können, dass Sie diese befolgen. Nehmen Sie zwei Check-ins in Ihre Meetings mit, bei denen zwei andere Entwickler die Richtlinien nicht konsequent befolgt haben. Wenn er sagt, dass es keine gibt, können Sie darauf hinweisen, dass andere Probleme damit zu haben scheinen und jeder davon profitieren würde diese Richtlinien.

Wenn er Sie fair behandelt, wird er das sehen und das sollte ganz oben auf seiner Liste der zu erledigenden Dinge stehen. Wenn er Sie nicht fair behandelt, haben Sie Munition, wenn es weitergeht.

Es ist schlecht zu sagen, "ich komme später dazu". Später passiert das nie. Nehmen Sie sich Zeit, es richtig zu machen. Es erfolgt keine spätere Programmierung.

Es ist schwer, wenn Sie ein Junior-Entwickler sind. Sie haben das Gefühl, unter Druck zu stehen, und viele Leute sehen Sie an, und jeder Fehler, den Sie machen, ist für immer an Ihren Namen in der Quellcodeverwaltung gebunden.


1
Ich werde den Kommentar zu "Ich komme später dazu" unterstützen. Wenn ich jedes Mal, wenn ich das höre, einen Nickel hätte, wäre ich nicht hier, um diesen Kommentar einzutippen. :-)
Eric King

Für .Net gibt es Style Cop. Aktivieren Sie diese Option, damit der Code erst erstellt wird, wenn StyleCop zufrieden ist. Dies beseitigt die menschliche Subjektivität und ist Mobbing durch die Belegschaft. Sie sehen, die Technologie kann Ihnen bei der Entscheidung helfen, ob Michael Phelps die Nummer 1 oder die Nummer 2 war. In Eiskunstlaufen, aber ... figureskating.about.com/od/famousskaters/tp/scandals.htm sollte ein Team führen , dass nicht über Power-Auslösung sein. Es sollte keine Favoriten in einer Mannschaft geben. Man muss darauf achten, dass sich ein solcher Eindruck nicht bildet. Ein guter Weg, dies zu tun, besteht darin, Regeln zu aktivieren, die den Code überprüfen und Ihnen eine unvoreingenommene Antwort geben.
Job

3

Nirgendwo in Ihrem Beitrag erwähnen Sie, wie andere in der Umgebung behandelt werden. Sie wiederholen immer wieder, dass Sie sich "herausgehoben" fühlen, weil Sie "eine Frau" sind.

Ich denke, Sie werden ungeachtet Ihres Geschlechts wie ein Junior-Programmierer behandelt, und Sie sollten dafür dankbar sein, denn das bedeutet Gleichheit. Ich habe auch das Gefühl, dass Sie viel Aufhebens um geringfügige, 5 Minuten lange Änderungen an der Code-Ästhetik machen, die Sie jetzt vornehmen müssen, anstatt sie auf eine To-Do-Liste zu setzen und sich nie darum zu kümmern.

Nirgendwo in Ihrem Beitrag haben Sie erwähnt, dass Sie am Wochenende dazu aufgefordert wurden. Es kann durchaus in Ordnung sein, die Korrekturen am Montagmorgen einzuchecken.

Ihr Teamleiter mag für meinen Geschmack etwas umständlich sein, aber von Ihrem Posten aus sehe ich nichts Falsches an seinen oder ihren Anfragen.

Bitte hören Sie auf, umsonst die Geschlechtskarte zu spielen . Ich halte dies für unwürdig und untergräbt das Konzept der Gleichstellung der Geschlechter.


1

Ich halte es nicht für sinnvoll, meine Branche auf dieser Grundlage abzulehnen. Viele Leute arbeiteten über das Wochenende und ich hatte nie gesagt, dass ich arbeiten würde. Einige Personen wurden wahrscheinlich blockiert, weil ich keine Zeit hatte, die Änderungen vorzunehmen und erneut einzureichen. Wir arbeiten an einem Projekt, das sehr zeitkritisch ist, und es scheint mir nicht hilfreich zu sein, Code vollständig abzulehnen, basierend auf Dingen, die für den Client transparent sind. Ich kann mich irren, aber es scheint, dass diese Dinge in Patch-Commits behandelt werden sollten, wenn ich Zeit habe.

Es ist schwer, irgendetwas Nützliches zu sagen, da jemand weder Ihren Code gesehen hat noch etwas über den Zeitplan Ihres Projekts weiß. Aber wenn sich Ihr Lead verantwortungsbewusst verhält und gute Arbeit leistet, weiß er, dass andere nicht wirklich geblockt wurden und der Sprint nicht zu spät kommt. Mach dir also keine Sorgen. Vielleicht überschätzen Sie die Auswirkungen auf Ihr Commit. Andernfalls: Wenn Ihr Projekt zeitkritisch ist und alle Tests besteht, wäre es zu wählerisch, um Code abzulehnen, der nach der Veröffentlichung im Handumdrehen behoben werden könnte.

Lass es funktionieren Lass es richtig laufen Lass es schnell gehen

Wenn Ihr Lead die Entscheidung getroffen hat, Ihr Commit abzulehnen, sollte er als Fachmann wissen, was er tat.

Nun kann ich sehen, dass dies in einigen Umgebungen die Norm ist. Die Kritik scheint jedoch nicht gleichmäßig verteilt zu sein, was zu meinem nächsten Problem führt. Die Grundlage für die meisten dieser Probleme war die Tatsache, dass ich mich in einer Codebasis befand, die jemand anderes geschrieben hatte, und versuchte, minimal invasiv zu sein. Ich ahmte die Variablennamen nach, die an anderer Stelle in der Datei verwendet wurden. Als ich das sagte, wurde mir unverblümt gesagt: "Ahme andere nicht nach, tu einfach, was richtig ist."

Als Junior ist es schwierig, einen Weg in die Codebasis eines Unternehmens zu finden.

Das Beste: Es gibt dokumentierte Codierungsstandards - und Sie werden hoffentlich lernen, diese in den Griff zu bekommen.

Normalerweise: Es gibt undokumentierte Codierungsstandards - und Sie müssen dies durch Test und Test lernen Irrtum oder soll ich sagen begehen und _reject? Dies ist oft schmerzhaft (wie in Ihrem Fall). Dies ist in Bezug auf die Codequalität manchmal gefährlich und kann zu einer Frachtkultprogrammierung führen , bei der man nicht nur die Benennung von Variablen imitiert , sondern Strukturen und Muster aus der Codebasis nach Treu und Glauben kopiert und einfügt. TU das nicht! Simulieren Sie nicht einmal die Benennung vorhandener Variablen.

Halten Sie sich an Clean Code . Es ist eine gute Übung und gibt Ihnen eine leicht zu verteidigende Position. Wenn es sich um lesbaren, testbaren und wartbaren Code handelt, haben Sie meistens jede Diskussion gewonnen.

Und dies führt zu einem weiteren (letzten) Hinweis: Befolgen Sie die Pfadfinderregel !

Lassen Sie die Codebasis immer in einem besseren Zustand als sie war. Auch wenn der Umgebungscode, mit dem Sie arbeiten, unangenehm ist, machen Sie Ihren sauber - und wenn Sie Zeit haben, reparieren Sie die Umgebung.


0

Nehmen Sie sich ein wenig Zeit, um die verschiedenen Nuancen der Persönlichkeit Ihrer Mitarbeiter kennenzulernen. Nach meiner Erfahrung können Sie irrationale, unnötige, inkonsistente oder einfach nur wertlose Kritik vermeiden, wenn Sie die Macken Ihrer Kollegen umgehen.

Zum Beispiel können einige Mitarbeiter montags verkatert sein. Sie können sehr gereizt sein und sind sehr bemüht, bestimmte Code-Zweige oder Commits abzulehnen. Wenn Sie mit jemandem wie diesem zusammenarbeiten müssen, vermeiden Sie montags das Festschreiben von Code.

Auf der anderen Seite ist ein verkaterter Mitarbeiter möglicherweise zu blasiert, um sich um die Ausführlichkeit von Fehlermeldungen zu kümmern. Daher ist der Montagmorgen möglicherweise der perfekte Zeitpunkt, um Ihren Code zu schreiben :-p

Die Persönlichkeitsmerkmale im Büro oder am Arbeitsplatz sind buchstäblich endlos. Hoffentlich können Sie lernen, wen Sie meiden sollten und wann Sie sie meiden sollten. Sei auch nicht zu streng mit dir selbst :-) Du kannst jederzeit kündigen und einen anderen Job finden!


1
Finden Sie den Job, bevor Sie kündigen, viele Personalchefs werden nicht einmal interviewen, wenn Sie nicht angestellt sind.
Woot4Moo

-2

Ich habe noch nie in einer Umgebung gearbeitet, in der Code abgelehnt wird, weil bestimmte Konventionen nicht befolgt werden. Wenn ich in Ihren Schuhen stecke, wäre ich versucht, eine Anstellung an einem Ort zu suchen, an dem ich mehr die Befugnis habe, die richtigen Entscheidungen zu treffen, und an dem der Kunde im Mittelpunkt steht und nicht der Kodex.

Ich sage nicht, dass sauberer Code und Standards nicht wichtig sind, aber der Kunde und die Produkt-Timeline sollten nicht unter Rechtschreibfehlern leiden, die keine nicht-technische Person, kein Kunde oder kein leitender Angestellter jemals sehen wird.

Trotzdem klingt es so, als würden Sie in einer Umgebung arbeiten, in der die Erwartungen nicht klar sind oder Sie die Anforderungen aus irgendeinem Grund nicht vollständig verstehen.

Unabhängig von der Situation liegt es an Ihnen, die Kontrolle zu übernehmen und klärende Fragen zu stellen. Seien Sie proaktiv, wenn Sie nicht bereits sind. Ihre Teammitglieder und Ihr Teamleiter werden Sie wahrscheinlich mehr respektieren, wenn Sie Fragen stellen, um die Regeln für das Einchecken zu klären. Sie können auch eine "Nachprüfung" anfordern, in der Sie und Ihr Teamleiter besprechen, was Sie stattdessen hätten tun sollen und wie Sie Ich kann den Unterschied feststellen, wann bestimmte Maßnahmen ergriffen werden müssen und wann nicht.

Ich würde vorschlagen, dass Sie sich Zeit nehmen, um zu prüfen, ob Sie alle Hürden überwinden und diese Probleme mit Erfahrung, Kommunikation und dem Erlernen der Standards lösen können. Wenn sich die Situation jedoch nach einigen Monaten nicht geändert hat und die Umwelt immer noch von Unklarheiten geplagt wird, ist es möglicherweise an der Zeit, eine Stelle in einem anderen Unternehmen zu suchen.

Nicht jede Organisation ist so drakonisch, und möglicherweise finden Sie andere Arbeitsumgebungen, die besser zu Ihrer Persönlichkeit, Ihrem Stil und Ihren Kommunikationsanforderungen passen.


2
Dies scheint nicht "drakonisch" zu sein; Konsistenz ist eine wichtige Komponente für die Wartbarkeit, Wartbarkeit ist eine wichtige Komponente für die Qualität, und Qualitätssoftware hat eine viel größere Chance, pünktlich und zu geringeren Kosten als "Kompromisscode" ausgeliefert zu werden. Es mag ermutigend sein, dass etwa 80% der Softwareunternehmen darauf aus sind, die Qualität zu beeinträchtigen und die Konsequenzen zu tragen. Es scheint also keinen Mangel an "nicht drakonischen" Beschäftigungsmöglichkeiten zu geben. :)
weberc2

1
Ich möchte nicht in einer Umgebung arbeiten, in der grundlegende Konventionen nicht durchgesetzt werden. Wenn ein Projekt aufgibt, seine Kodierungsrichtlinien zu verteidigen, ist es auf lange Sicht zum Scheitern verurteilt. Insbesondere das Benennen von Variablen ist keine Kleinigkeit: Egal wie viel vorhandener Code eine bestimmte Matrix Anennt, ich würde niemals ein Commit akzeptieren, das Baus Konsistenzgründen eine andere Matrix aufruft . Natürlich weiß ich nicht, was das OP genau mit "Nachahmen von [...] Namen, die an anderer Stelle verwendet werden" meinte, aber angesichts der Qualität eines Codes, den ich gesehen habe, könnte es in diese Richtung gehen.
cmaster
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.