Wie gehe ich mit "fast gutem" Code eines Junior-Entwicklers um? [geschlossen]

95

Ich habe eine Frage zum Teammanagement. Im Moment habe ich es mit einem Nachwuchsentwickler zu tun, der aus der Ferne in einer Codierungsfabrik arbeitet. Der Typ ist offen für Kritik und lernwillig, aber ich habe einige Zweifel, wie viel ich ein paar Sachen pushen soll.

Gerade jetzt, wenn etwas klar und offensichtlich ist, verstößt es gegen bewährte Praktiken: Zum Beispiel gegen die SRP, Gott wendet sich gegen nicht aussagekräftige Namen für Methoden oder Variablen. Ich weise darauf hin, was er reparieren muss und versuche zu erklären, warum es falsch ist.

Meine Frage ist: Wann höre ich auf? Im Moment, wenn es einige geringfügige Verstöße gegen den Codierungsstil gibt, wie z. B. Variablennamen in der falschen Sprache (das vorherige Team hat Spanisch und Englisch gemischt und ich versuche, das zu beheben), oder einige geringfügige strukturelle Probleme, die ich loslassen und beheben möchte, wenn Ich habe keine Freizeit oder muss die problematische Klasse ändern. Ich denke, das ist gut für die Moral des Teams, also drücke ich nicht ständig den Code zurück, was einem Neuling wie kleine Details erscheinen mag, was ziemlich frustrierend sein kann, aber ich mache mir auch Sorgen, dass es den Kerl davon abhalten könnte, zu "weich" zu sein vom Lernen, wie man ein paar Sachen macht.

Wie balanciere ich die Grenze zwischen Unterrichten und nicht mit ständiger Kritik ausbrennen? Für einen Junior kann es frustrierend sein, wenn man ihm sagt, er solle Dinge wiederholen, die für seine Augen funktionieren.

Zalomon
quelle
7
Wie viel Zeit haben Sie damit verbracht, sicherzustellen, dass er Ihre Erwartungen kennt?
Blrfl
13
@gnat Ich denke, es ist nicht der gleiche Fall, mein Problem ist nicht, dass wir Schätzungen überschreiten oder Code übertreiben. Tatsache ist, dass wir dem Zeitplan voraus sind. Meine Frage ist, wie man die Grenze zwischen dem Lehren des Jungen und dem Ausbrennen von ihm mit ständiger Kritik ausbalanciert. Für einen Junior kann es frustrierend sein, wenn man ihm sagt, er solle Dinge wiederholen, die für seine Augen funktionieren.
Zalomon
4
Ich habe das editiert, um mehr über das Thema zu erfahren. Ich glaube, dass dies auch anders ist als die verknüpfte doppelte Frage.
Enderland
3
Einige Dinge, die ich versucht habe, helfen dabei: Paarprogrammierung - Gewinnen Sie einen Einblick in seine Arbeitsweise und sein Denken und setzen Sie ihn möglicherweise Ihren Denkprozessen aus, während Sie Ihren Code durcharbeiten. Finden Sie die Aufgaben, in denen er gut ist - manchmal erzielen Sie bessere Ergebnisse, wenn Sie eine Menge kleiner Fehler auf ihn werfen, im Vergleich zu großen Aufgaben. Tech-Designs - geben Sie ihm den ersten Einblick in das Entwerfen von Software, ohne den Code zu berühren. Dies lässt ihn über Struktur und Prozess nachdenken, anstatt seinen Kopf zu senken und Code zu produzieren. Zum Schluss viel Glück. Manchmal dauert es länger als erwartet, aber es lohnt sich, wenn er produktiv wird.
Sandy Chapman

Antworten:

84

Wenn Sie der Meinung sind, dass der Code vor dem Zusammenführen repariert werden sollte, machen Sie Kommentare. Am liebsten mit "warum", damit der Entwickler lernen kann.

Denken Sie daran, dass Code viel häufiger gelesen als geschrieben wird. Dinge, die "geringfügig" erscheinen, können also wirklich wichtig sein (z. B. Variablennamen).

Wenn Sie jedoch Kommentare machen, die Ihnen langweilig erscheinen, sollten Sie Folgendes in Betracht ziehen:

  • Sollte Ihr CI-Prozess diese abfangen?
  • Haben Sie einen klaren "Entwicklerleitfaden" zum Nachschlagen (oder ist alles in Ihrem Kopf dokumentiert)?
  • Tragen diese Kommentare tatsächlich zur Codequalität bei?

Viele Menschen opfern Produktivität am Altar des Prozesses oder der Perfektion. Pass auf, dass du das nicht tust.

Versuchen Sie, Ihren Kollegen möglichst persönlich zu besuchen. Oder nutzen Sie Videoanrufe. Der Aufbau einer Beziehung erleichtert die Verwaltung von Kritik (auch von Codeüberprüfungen).

Wenn Sie feststellen, dass ein Codeteil zu viele Hin- und Herbewegungen aufweist, fordern Sie die Überprüfung für kleinere Codeteile an. Inkrementelle Änderungen vermeiden mit größerer Wahrscheinlichkeit einige der bedeutenderen Entwurfsprobleme, da sie per Definition kleiner sind.

Aber absolut nicht zusammenführen und dann zurückgehen und es reparieren. Dies ist passiv aggressiv und wenn der Entwickler feststellt, dass Sie dies tun, werden Sie deren Moral töten.

Enderland
quelle
65
@ 9000 Es ist erstaunlich, wie oft Menschen frustriert sind, wenn sie nicht ihren Standards entsprechen, obwohl diese Standards nirgendwo dokumentiert sind ...
enderland
32
Variablennamen sind äußerst wichtig für die Beschreibung der Absicht des Codes. Methoden- / Funktionsnamen, umso mehr. Die richtigen Namen zu finden ist kein unnützer Perfektionismus, sondern wird für die Wartbarkeit benötigt.
9000,
9
@ Zalomon Erwähne es ihm auf jeden Fall; mehr, verwandle es in eine Diskussion. Als Junior-Entwickler habe ich mit einigen Senior-Entwicklern zusammengearbeitet. Meine beste Erfahrung machte ich mit einem Entwickler, der mir alle seine Empfehlungen durchsprach - sogar "kleine" wie ein etwas besserer Name für eine Variable. Ich lernte nicht nur eine Menge von ihm, sondern fühlte mich auch so gut, dass er meinen Gedankengängen zuhörte und mich in die Diskussion einbezog. Ich wollte, dass er meinen Code mehr überprüfte, damit ich mehr lernen konnte. (Fortsetzung)
dj18
6
@Zalomon (Fortsetzung) Auf der anderen Seite war ein älterer Entwickler, der Änderungen hinter meinem Rücken vorgenommen hat (auch wenn Sie ihm später sagen, dass es immer noch hinter seinem Rücken liegt), total demoralisierend - ich hatte das Gefühl, mit einem Autokraten zu arbeiten, den ich habe musste herausfinden, wie man bitte.
18.
6
Meine (kleine) Erfahrung im Mentoring von Junior-Entwicklern zeigt, dass es sich lohnt, einen Entwickler dazu zu bringen, über den richtigen Namen nachzudenken und den Zweck der Daten im Variablennamen auszudrücken . Es hilft den Entwicklern dabei, zu verstehen, was ihr Code tut, und zwar auf eine viel weniger wellenförmige Weise, als sie es gewohnt sind. Es führt manchmal dazu, dass sie logische Fehler im Code finden oder einfach bessere Möglichkeiten, Dinge auszudrücken. (Dasselbe funktioniert für mich; der Unterschied besteht darin, dass ich die Disziplin dank strenger Code-
9000
19

Behalten Sie die Kritik am Code und nicht am Schreiber.

Jede Arbeit, die produziert wird, hat eine emotionale Bindung. Ziehen Sie in Betracht, dies zu vereinfachen, indem Sie den Code so weit wie möglich vom Writer trennen. Die Qualität des Codes sollte konsequent als gemeinsames Ziel festgelegt werden, das Sie beide gemeinsam verfolgen, und nicht als Reibungspunkt zwischen Ihnen.

Eine Möglichkeit, dies zu erreichen, besteht darin, Ihre Worte mit Bedacht zu wählen. Obwohl MINT-Individuen sich gerne als höchst logisch betrachten, sind Emotionen ein Teil der menschlichen Natur. Die verwendete Sprache kann der Unterschied zwischen verletzten oder verschonten Gefühlen sein. Die Angabe "Dieser Funktionsname würde den Konventionen besser entsprechen, wenn er in englischer Sprache verfasst wäre" ist der Angabe "Sie haben diesen Funktionsnamen falsch geschrieben und er sollte in englischer Sprache verfasst sein" vorzuziehen. Während letzteres noch zahm ist und alleine in Ordnung scheint, werden im Vergleich zu ersteren seine Fehler offensichtlich - wenn Sie vorbereiten, was Sie persönlich oder per E-Mail sagen sollen, prüfen Sie, ob Ihr Kontext, Ihre Worte und Ihr Fokus eher auf den Themen als auf den Themen liegen die Person .

Körpersprache

Während Wörter wichtig sind, ist die meiste Kommunikation nonverbal. Achten Sie auf die Körpersprache, auch auf scheinbar unbedeutende Feinheiten wie z. B. Orientierungsprobleme. Viele Interaktionen zwischen Senioren und Junioren finden von Angesicht zu Angesicht statt, doch ein Nebeneinander wäre für Ihr gewünschtes Ergebnis viel förderlicher.

Geben Sie ehrliches positives Feedback

Eine Vielzahl von Studien zeigt, dass Informationen schneller gelernt und besser gespeichert werden, wenn wir gutes Verhalten belohnen, anstatt schlechte zu bestrafen. Manchmal bemerkte ich nur, dass die Leistung durch einen einfachen "guten Job" oder ein spezifischeres "Ich habe in letzter Zeit bemerkt, dass Ihr Stil unseren Standards zu einem Abschlag entsprach, großartige Arbeit!" Selbst wenn Sie diese Erkenntnis der Verbesserung ergänzen, indem Sie sich von einer anderen Person zu den von ihr geänderten Themen beraten lassen, kann dies den entscheidenden Unterschied für Ihren Junior-Entwickler und seine Arbeit ausmachen.

Legato
quelle
2
Zum Wortlaut: Wenn Sie ein Personalpronomen verwenden müssen, entpersönlicht die Auswahl von "wir" anstelle von "Sie" nach meiner Erfahrung auch die Kritik auf beiden Seiten der Codeüberprüfung.
Josh Caswell
6

Der Typ ist offen für Kritik und lernwillig, aber ich habe einige Zweifel, wie viel ich ein paar Sachen pushen soll.

Schieben Sie alles, was Sie können. Wenn der Typ lernt und es Ihre Aufgabe ist, seinen Code zu überprüfen, haben Sie beide viel zu gewinnen, wenn er gute Arbeit leistet.

Das bedeutet, dass Sie in Zukunft weniger Code überprüfen müssen und möglicherweise Ihrem Team ein Einstellungsziel geben müssen.

Auch wenn Sie sich zurückhalten, helfen Sie nicht, sondern bevormunden.

Allein die Tatsache, dass Sie Ihre Frage hier gepostet haben und gefragt haben, ob Sie zu viel tun, zeigt mir bereits, dass Sie diesen speziellen Rat nicht benötigen ein Idiot sein.

Mentor zu sein ist keine leichte Aufgabe. Sie müssen ihm auch etwas Platz einräumen, um einige Fehler zu machen und sie selbst zu korrigieren. Stellen Sie nur sicher, dass er das an einem Ort tut, der keinen wirklichen Schaden anrichtet.

Machado
quelle
5

Nach Ihrer Beschreibung würde ich es so belassen: "Das ist gut. Es gibt ein paar Dinge, die ich anders gemacht hätte, aber sie sind nicht sehr wichtig."

Wie Sie zu begreifen scheinen, ist Kritik mit Kosten verbunden, und wenn Sie viel Zeit damit verbringen, Details in den Griff zu bekommen, wird dies zu einem moralischen Problem. Im Idealfall werden alle Codierungsstandards automatisch überprüft und Sie können erst dann erstellen, wenn Sie sie befolgen. Dies spart viel Zeit und Sie können sich an die Arbeit machen. Wenn Sie Ihre Kritik für "Dinge, die wichtig sind" reservieren, hat Ihr Rat viel mehr Wirkung und Sie werden als geschätzter Mentor angesehen. Es ist wirklich wichtig, zwischen Dingen zu unterscheiden, die nicht gut sind, und Dingen, die nicht genau so sind, wie Sie es tun würden.

Ich glaube an das Konzept des lehrbaren Moments . Wenn der Entwickler über genügend mentale Fähigkeiten verfügt, fragt er möglicherweise nach den Details, was Sie anders machen würden. (S) er könnte nicht und das ist in Ordnung. Die Leute sind ausgebrannt und zu Beginn ihrer Karriere kann es eine Menge geistiger Energie kosten, Dinge zu erreichen, die später einfach erscheinen.

JimmyJames
quelle
Eine Möglichkeit, endlose Zyklen von Codeüberprüfungen zu vermeiden, besteht darin, Änderungen klein zu halten. Keine Pull-Anfrage ist lächerlich klein, wenn sie eine vorteilhafte Änderung bewirkt (ich habe meinen Anteil an 1-Zeichen-PRs gemacht). Je kleiner desto besser. Reduzieren Sie gnadenlos den Umfang der Tickets, die Junior-Entwicklern ausgehändigt werden, und sorgen Sie dafür, dass sie die Dinge erledigen. Sobald sie den gesamten Prozess zum Lesen, Verstehen, Testen, Überprüfen und Bereitstellen von Code beherrschen, kann sich der Umfang erhöhen.
9000,
1
Ich denke nicht, dass es eine gute Idee ist, dem Entwickler mitzuteilen, dass sie nicht sehr wichtig sind, wenn sie wichtig genug sind, damit das OP später zurückkehren und sich ändern kann.
Enderland
3
@enderland Nach meiner Erfahrung gibt es keinen perfekten Code. Sie können es später immer noch verbessern, das ist hier also nicht wirklich relevant. Das OP sagt, dies sind Dinge, um "das Problem zu beheben, wenn ich Freizeit habe". Es gibt zwei Arten von Problemen. Dinge, die repariert werden müssen und Dinge, die nicht repariert werden müssen. Letztere können festgelegt sein oder auch nicht, und diese klingen so, als würden sie in diese Kategorie fallen. Es ist in gewisser Hinsicht ein Urteilsspruch, aber ich denke, wenn Sie als erfahrener Entwickler nicht sicher sind, ob es sich lohnt, es als Muss zu ändern, dann ist es das wahrscheinlich nicht.
JimmyJames
5

Ich würde in Betracht ziehen, seine Arbeit anzunehmen, wenn sie akzeptabel und nicht perfekt ist. Und dann ist die nächste Aufgabe nach einem Gespräch, es sofort umzugestalten, indem Sie alle kleinen, aber wichtigen Änderungen vornehmen, die Sie möchten.

Wenn also die Arbeit zum ersten Mal angenommen wird, ist Ihre Botschaft, dass sie nicht schlecht war, und einige Orte hätten sie als gut genug angenommen - aber nicht Orte, an denen Sie als Nachwuchsentwickler sein möchten, der sein Handwerk richtig erlernen möchte.

Sie sagen also nicht "Ich lehne Ihre Arbeit ab, weil sie nicht gut genug ist". Sie sagen (a) "Ich akzeptiere Ihre Arbeit, weil sie gut genug ist" und dann (b) "Aber ich will es besser".

gnasher729
quelle
3
Oder "(b) Und ich weiß, dass Sie es besser machen können." Wenn er fragt "lehre mich", weißt du, dass er auf dem richtigen Weg ist. :)
Machado
1
In meiner vorherigen Position haben wir Stash / BitBucket als Tool zur Codeüberprüfung verwendet. Sie hatte die Möglichkeit, eine Pull-Anfrage zu blockieren, indem sie entweder eine ausstehende Aufgabe festlegte oder die Pull-Anfrage komplett ablehnte. Ich würde diese nur für notwendige Änderungen verwenden. Wenn es eine kosmetische Änderung gab (z. B. geringfügige Codelesbarkeit, bessere Datenstruktur, Umgestaltung), würde ich mit Vorschlägen darauf hinweisen, aber keine Blockierungsaufgabe hinzufügen, wenn Sie Zeit haben. Dies verhindert auch das Ausbleiben von Terminen bei geringfügigen Problemen.
Hand-E-Food
4

Ziemlich offene Frage, aber hier sind ein paar Ideen.

  1. Peer Reviews (vom Junior-Entwickler)

    Der beste Weg für jemanden, den "richtigen" Weg zu lernen, besteht darin, zu sehen, wie andere es tun. Führen alle Ihre Entwickler Codeüberprüfungen durch? Es ist möglicherweise keine schlechte Idee, sie auch von Ihrem Junior-Entwickler ausführen zu lassen (obwohl Sie auch mindestens eine Überprüfung von einem Senior-Entwickler benötigen sollten). Auf diese Weise wird er gute Programmierer in Aktion sehen und feststellen, dass es Überprüfungskommentare gibt, die sich an andere Ingenieure als ihn selbst richten, was bedeutet, dass dies nicht persönlich ist.

  2. Frühes Feedback / Aufgabenüberprüfungen

    Ermöglichen Sie dem Entwickler, an seiner eigenen Aufgabenaufschlüsselung teilzunehmen. Lassen Sie ihn sein beabsichtigtes Design in den Aufgabennotizen aufzeichnen und eine "Codeüberprüfung" ohne Änderungssatz und nur die Aufgabe einreichen. Auf diese Weise können Sie seinen Plan überprüfen, bevor er eine einzelne Codezeile geschrieben hat. Sobald seine Aufgabe überprüft wurde, kann er mit dem Codieren beginnen (danach legt er eine weitere Codeüberprüfung vor). Dies vermeidet die demoralisierende Situation, in der der Entwickler ein paar Sachen geschrieben hat und Sie ihm sagen müssen, dass er sie umschreiben soll.

John Wu
quelle
3
Ich mag die Idee des Peer Reviews, im Moment sind es nur zwei von uns im Team, aber ich kann ihn meinen Code überprüfen lassen. Wenn er versteht, was ich tue, und Unstimmigkeiten feststellt, kann dies hilfreich sein, sowohl für die Codequalität als auch für seine Moral. Es hat mir geholfen, als ich lernte zu sehen, dass ich nicht der einzige war, der Fehler +1 machte
Zalomon
2

Wenn der Code objektiv gegen einen geschriebenen, eindeutigen Standard verstößt, sollten Sie nach meinem Dafürhalten so lange zurückschieben, bis alle Probleme behoben sind. Sicher, es könnte für den Entwickler ein wenig ärgerlich sein, die ersten Commits durchzuführen, aber sie könnten die Richtlinien auch eher früher als später lernen.

Wenn Sie hier und da ein paar Verstöße gegen Standards zulassen, werden diese einen schlechten Präzedenzfall darstellen - siehe Theorie der kaputten Fenster . Es ist auch viel einfacher, sich daran zu erinnern, die Standards zu befolgen, wenn sie bereits konsequent auf die Codebasis angewendet werden. Also wirklich, jeder gewinnt, einschließlich der fraglichen Nachwuchsentwickler.

Ich denke nicht, dass die Moral ein großes Problem ist, solange der Kodierungsstandard aufgeschrieben ist. Nur wenn es in subjektiveren "naja, ich hätte es anders gemacht" -Territorium geht, dann sollte man sich Sorgen machen, da der Entwickleransatz vielleicht genauso valide ist.

JacquesB
quelle
2

Ziehen Sie einen Workflow zur Codeüberprüfung in Betracht, bei dem Entwickler ihre vorgeschlagenen Commits an ein Tool wie Github Pull Requests oder Phabricator Diffusion senden und sich von Kollegen abmelden lassen, bevor sie ihre Änderungen in der gemeinsam genutzten Hauptniederlassung ablegen.

Auf diese Weise wird nicht rückwirkend kritisiert oder jemand aufgefordert, das bereits Erreichte zu wiederholen, sondern erst dann gearbeitet, wenn die Prüfung durch Fachkollegen bestanden wurde. Das Hin und Her mit Kollegen ist ebenso Teil des Softwareentwicklungsprozesses wie das Hin und Her mit dem Compiler.

Sie können Ihre Bedenken als Kommentare zu bestimmten Zeilen veröffentlichen und Diskussionen darüber führen. Er kann dasselbe mit Ihrem Code machen. Die Diskussion konzentriert sich weiterhin auf die spezifischen vorgeschlagenen Codeänderungen und nicht auf die Leistung oder Kompetenz einer Person im Allgemeinen.

Selbst brillante leitende Ingenieure in meinem Unternehmen sind dankbar, wenn Codeüberprüfungen Tippfehler auffangen oder sie zwingen, die Dinge klarer zu machen. Es ist völlig normal, dass Neueinstellungen mehr Iterationsrunden erfordern. Mit der Zeit beginnen Sie, die Probleme, von denen Sie wissen, dass sie Kommentare hervorrufen , reflexartig zu beheben, bevor Sie einen Diff veröffentlichen. Wenn Sie beim ersten Versuch einen höheren Prozentsatz Ihrer Diffs akzeptieren, wissen Sie, dass Sie sich verbessern.

closeparen
quelle
1

Ich drücke nicht ständig den Code zurück, wenn es darum geht, was für einen Anfänger wie kleine Details erscheinen könnte, was ziemlich frustrierend sein kann, aber ich mache mir auch Sorgen, dass zu 'weich' sein könnte, dass der Typ nicht lernt, wie man einiges macht.

Dies sind sowohl echte Möglichkeiten als auch berechtigte Bedenken. Fragen Sie den Entwickler, wie er sich dabei fühlt.

Kevin Krumwiede
quelle
Tatsache ist, dass er mir sagte, er fühle sich dumm. Ich versuche, die Kritik auf der positiven Seite zu halten, und ich sagte ihm, dass ich mit seiner Arbeit zufrieden bin. Ich erklärte ihm auch, dass ich diese Art von Zweifeln hatte, als ich anfing, aber ich muss davon ausgehen, dass ein Teil des Feedbacks zu ihm kam um seine Arbeit zu verbessern, ist es falsch.
Zalomon
2
Erklären Sie, dass Sie Ihre Zeit nicht damit verschwenden würden, seinen Code sorgfältig zu kritisieren, wenn Sie nicht damit rechnen würden, dass er zu einem besseren Programmierer wird. Und seien Sie gewissenhaft bei der Unterscheidung zwischen "Sie müssen dies beheben, damit der Code akzeptabel ist" und "Folgendes können Sie beim nächsten Mal noch besser machen". Das größte Geschenk, das Sie einem Nachwuchsprogrammierer machen können, ist die Bereitstellung einer großen Menge aufschlussreicher und präziser Kritik. Andernfalls werden sie schlechter programmiert. Die Kritik sollte nachlassen. Sie müssen jeden Fehler nur einmal, vielleicht zweimal machen, und es gibt nur so viele Fehler.
David Schwartz
1

Unter der Annahme, dass Sie einen Pull-Request- oder Code-Review-Workflow haben und dies anscheinend auch tun, würde ich empfehlen, Dinge zu notieren, die "unkritisch" oder "bevorzugt" sind.

Wenn Sie eine PR in einem ähnlichen Zustand wie dem sehen, den Sie beschreiben, mit einigen geringfügigen stilistischen Problemen oder wenn Sie eine nichtkritische Überarbeitung benötigen, hinterlassen Sie einen Kommentar, können ihn aber auch gerne genehmigen. Wenn Sie beispielsweise sagen: "Versuchen Sie in Zukunft, Methodennamen wie diesen zugunsten von descriptiveMethodName zu vermeiden", dokumentieren Sie Ihre Meinung, ohne sie zu einer Änderung zu zwingen oder ihre Entwicklung zu blockieren.

Jetzt kennen sie Ihre Präferenz und wenn sie versuchen, sich zu verbessern, würden sie hoffentlich eine solche Situation in der Zukunft bemerken. Es lässt ihnen auch die Tür offen, die sie zu diesem Zeitpunkt tatsächlich ändern, falls sie mit Ihnen einverstanden sind und dies als kritisch genug ansehen.

zak
quelle
0

Ich habe es mit einem Junior-Entwickler zu tun, der aus der Ferne in einer Codierungsfabrik arbeitet.

Das ist leider keine ideale Situation: ein fortgeschrittener Programmierer, der für einen neuen Programmierer zuständig ist, mit geografischer Trennung. Es ist nicht verwunderlich, dass es einige Spannungen gibt, aber die Unterschiede können gemindert werden.

Ich bin gespannt, was meinst du mit "Coding Factory"? Diese Terminologie weist für mich auf eine besorgniserregende Haltung hin, die einige der von Ihnen angesprochenen Managementprobleme verschlimmern könnte.

… Verletzung von SRP, Gottgegenständen, nicht aussagekräftigen Namen für Methoden oder Variablen; Ich weise darauf hin, was er reparieren muss und versuche zu erklären, warum es falsch ist.

Ich denke, das Problem ist, dass Ihr Nachwuchsentwickler Code ausgibt, ohne einen ordnungsgemäßen Entwurfsprozess durchlaufen zu haben. Dies ist ein Fehler für Sie als Manager und leitender Entwickler, Anleitungen zu geben und gute Gewohnheiten bei der Softwareentwicklung zu vermitteln. Sie können verhindern, dass fehlerhafter Code zuerst geschrieben wird, wenn Sie zuerst zusammenarbeiten, um eine Gliederung zu skizzieren. Das wäre der Kritik und dem Umschreiben von Code vorzuziehen, nachdem er erstellt wurde, sowohl in Bezug auf Effizienz als auch auf die Moral.

Wahrscheinlich müssen Sie Ihren Workflow neu anpassen. Es hört sich so an, als würden Sie derzeit davon ausgehen, dass er Ihnen Produkte liefert. Was Sie brauchen, ist eine engere Zusammenarbeit, damit Sie bei jedem Entwicklungsschritt eine Anleitung geben können. Sprechen Sie über das Design und die Oberfläche, bevor Sie mit dem Codieren beginnen. Führen Sie während der Codierung häufigere Checkpoints durch, um Probleme früher zu erkennen. Versuchen Sie nach Möglichkeit die Paarprogrammierung über die Bildschirmfreigabe mit einem Audiokanal.

All dies wird mehr Mühe von Ihrer Seite erfordern, aber es wird sich wahrscheinlich lohnen, wenn man die problematische Beziehung bedenkt, die Sie derzeit haben.

200_erfolg
quelle
-1

Wenn es gegen die Kodierungsstandards verstößt, zeigen Sie ihm, wo es ist, damit er / sie es weiß. Wenn Sie ihm / ihr den gleichen Fehler zeigen müssen, haben Sie möglicherweise ein Problem mit jemandem, der sich entweder nicht an die Regeln hält oder sich weigert. Verwenden Sie nicht Ihre Freizeit, um die Fehler zu beheben. Diese Person sollte ihre eigenen Fehler beheben, damit sie sie nicht erneut macht.

Sagen Sie ihnen immer, was sie richtig gemacht haben und wie sie sich beim nächsten Mal verbessern können. In einigen Bereichen können wir immer besser werden. Feedback ist entscheidend, um in irgendetwas besser zu werden.

Acithium
quelle
-1

Eine andere Idee, um mit "zu viel Kritik" umzugehen, ist, von Zeit zu Zeit eine Aufgabe selbst zu erledigen und einen Junior-Entwickler eine Codeüberprüfung für Sie durchführen zu lassen. Dies hat mindestens zwei Vorteile:

  • Sie können lernen, wie Dinge zu tun sind.
  • In Fällen, in denen es mehrere gute Lösungen oder Variablennamen gibt, akzeptiere ich Vorschläge von verschiedenen, aber (fast?) gleich guten Ansätzen. Wenn ich meinen Code aufgrund eines Kommentars von jemandem korrigiere, zeige ich den Leuten, dass sie respektiert werden, und die Kritik betrifft immer nur Code - unabhängig davon, wer der Autor ist.
BartoszKP
quelle
Ich würde mich freuen zu erfahren, was mit meinem Beitrag nicht stimmt. Eine Ablehnung ist ein verständliches Zeichen für Meinungsverschiedenheiten, aber Stimmen löschen ?!
BartoszKP