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

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.

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.

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.

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

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.

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.

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.

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.

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!

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.