Einem Teammitglied helfen, mit meinen hohen Anforderungen umzugehen

Dieses Thema liegt mir sehr am Herzen (so sehr, dass ich in der Tat meine Geschichte überprüfen musste, um sicherzustellen, dass ich es nicht geschrieben habe)!

Letztendlich widerspreche ich allen Vorschlägen, dass Sie Ihre hohen Standards schleifen lassen. Codierungsstandards bieten einen echten Mehrwert und Sie werfen sie nicht weg, weil sie hart sind ... aber als Lead liegt es in Ihrer Verantwortung, sie lächerlich einfach zu befolgen.

Denken Sie daran, dass dieser Entwickler nicht Sie sind. Er könnte der kompetenteste Entwickler der Welt sein, aber seine Erfahrungen und Vorlieben werden sich (vielleicht stark) von Ihren unterscheiden. Es wird für ihn viel schwieriger sein, nach Ihren Erwartungen zu programmieren, weil Ihre Standards für ihn nicht selbstverständlich sind.

Ich bezweifle, dass Ihr Entwickler frustriert ist, weil er bestimmte Standards erfüllen muss (wenn er das tut, haben Sie ein größeres Problem), wahrscheinlicher beruht seine Frustration auf dem Gefühl, dass er versucht, ein sich bewegendes Ziel zu treffen .

Sie müssen die Dinge für ihn vereinfachen:

• Sind Ihre Standards dokumentiert? Wenn Sie diese nicht irgendwo (nirgendwo) niedergeschrieben haben, können Sie nicht erwarten, dass sich jemand daran hält. Selbst die anerkanntesten Best Practices neigen dazu, online einen oder zwei halbwegs kompetente Kritiker zu haben. Entwickler sind sich nicht immer einig, also machen Sie es konkret: Schreiben Sie Ihre Erwartungen auf.
• Ist diese Dokumentation lesbar? Das ist eine große Sache ... Ich habe viele Standarddokumente gesehen, die sehr detailliert sind, aber es sind 60 Seiten an Material! Kein Entwickler kann das in einer Sitzung aufnehmen. Selbst kleinere 3-seitige Dokumente können mehr Stichpunkte enthalten, als Sie sich wahrscheinlich merken werden, wenn Sie sich auf ein bestimmtes Problem konzentrieren. Tun Sie Ihrem Entwickler einen Gefallen und stellen Sie eine Checkliste mit wichtigen „Erinnerungspunkten“ zusammen, die er überprüfen sollte, bevor er einen Commit durchführt. Betrachten Sie es als einen Spickzettel zur Codeüberprüfung , der ihm hilft, seinen eigenen Code zu überprüfen, bevor er zu Ihnen kommt.
• Verwenden Sie Tools zur Codequalität? Sie erwähnen nicht, welche Sprachen Sie verwenden, aber für fast jede Sprache gibt es statische und dynamische Code-Scanning-Frameworks, die Ihren Code aktiv kritisieren können, während Sie tippen. Recherchieren und nutzen Sie diese, wenn Sie können! (Einige schnelle Beispiele sind Checkstyles , SonarQube ) Es gibt nichts Besseres, als herauszufinden, dass Sie in der IDE etwas falsch machen, während Sie es tun , damit Sie das Problem in Echtzeit beheben können. Selbst das Finden von Problemen während der Kompilierung ist besser, als wenn es auf eine Überprüfung zurückkommt. Diese Tools stärken den Entwickler und sparen viel Zeit während des Überprüfungsprozesses. Sie können einige Anfangsinvestitionen erfordern, um sie richtig einzurichten, aber ich verspreche Ihnen, dass Sie die langfristigen Ergebnisse mögen werden.
• Haben Sie ein Mentoring- oder Shadowing-Programm? Jeder Profi könnte davon profitieren, einem erfahrenen Teammitglied über die Schulter zu schauen. Ermutigen Sie, wie @Marc Q. erwähnte, diesen Entwickler, sich mit anderen Entwicklern zusammenzusetzen, sich einzuarbeiten und ständig danach zu streben, sich zu verbessern. Proaktive Persönlichkeitsentwicklung ist so viel besser für die Moral, als ständig auf negatives Feedback zu reagieren. Selbst wenn Sie ihn nur auf Ihre geheimen Websites einlassen, auf denen Sie Online-Hilfe suchen, kann dies für ihn zu einer unschätzbaren Information werden.
• Ermutigst du ihn? Das ist mit Abstand der wichtigste Punkt! Die Ergebnisse einer Überprüfung sind selbst für das stärkste Ego ein Schlag. Legen Sie diese Kritik zwischen Lob dafür, dass Sie das Richtige getan haben. Weisen Sie auf clevere Lösungen für Probleme hin, die er gelöst hat. Beachten Sie seine allgemeine Verbesserung. Programmieren kann selbst unter den besten Bedingungen ein quälendes Unterfangen sein, aber wenn Sie das Gefühl haben, auch nicht geschätzt zu werden, kann es seelenzerstörend sein. Stellen Sie sicher, dass Sie ihm bei jeder Korrektur immer eine positive Verstärkung geben. Es kann sein, was er braucht, um den ganzen Tag durchzuhalten.

Konzentrieren Sie sich auf eine Sache nach der anderen, warten Sie, bis dieser Standard erfüllt ist, und führen Sie dann eine andere ein.

Das Problem ist, dass ihm ein bestimmtes Tempo erlaubt wurde und er jetzt an Standards herangeführt wird, die er zuvor nicht erfüllen musste.

In der Zwischenzeit müssen Sie einige Dinge schleifen lassen. Lassen Sie ihn wissen, dass Sie ihm dabei helfen werden, den Standard zu erreichen, und dass Sie die Dinge vorerst schleifen lassen, aber es ist nur vorübergehend .

Seien Sie geduldig mit ihm, weil er in dieser Situation ist, weil er teilweise wegen Ihnen in diesem Schlamassel steckt. Sie können nicht einfach einen Schalter umlegen und erwarten, dass die Person die Standards erfüllt.

Also zusammenfassend:

• Sei geduldig
• Standards einzeln einführen
• Machen Sie deutlich, dass dies ein laufendes Projekt für ihn ist

Paarprogrammierung könnte helfen. Entwickler (dieser spezielle Kollege und andere) akzeptieren meiner Erfahrung nach Vorschläge in Echtzeit viel leichter als Kritik im Nachhinein. Und es könnte die gegenwärtige Untergebenen-Vorgesetzten-Beziehung (so klingt es) in eine Mitwirkenden-Beziehung verwandeln (wenn auch einige älter als andere). 'Hoffe das hilft!

Als jemand, der seine Karriere als Teilzeit-Codierer beginnt, werde ich versuchen, Ihnen einen Einblick zu geben, wie ich mir wünschen würde, dass mich jemand auf solche Themen ansprechen würde.

Wie kann ich meinem Programmierer helfen, eine positivere Einstellung dazu zu haben, dass ich seinen Code häufig für Änderungen zurücksende?

Wie Sie in Ihrer Frage erwähnt haben, geben Sie ihm bereits ein detailliertes Feedback. Sie beschreiben es so, dass er Ihr Feedback nicht versteht. In diesem Fall kann er es entweder nicht verstehen oder er will es nicht verstehen. Im ersten Augenblick. Sie müssen seine technischen Fähigkeiten überprüfen. Was weiß er, was weiß er in der Partition und was weiß er nicht. Wenn dies geklärt ist, geben Sie ihm eine Anleitung, wo er die benötigten Informationen finden kann, und wiederholen Sie diesen Vorgang für jeden Punkt auf Ihrer Liste.

Im zweiten Fall wird es schwierig sein, ihn davon abzuhalten, frustriert zu sein, da es möglicherweise andere Faktoren gibt, die ihn daran hindern, Ihre Codierungsrichtlinien zu befolgen.

Ist das ein Zeichen dafür, dass ich andere Dinge falsch mache?

Nicht unbedingt. Wenn er sich seiner Fehler bewusst ist, müssen Sie ihn ermutigen. Sagen Sie ihm, dass er abgesehen von den Dingen, die Sie in Ihrem Beitrag erwähnt haben, einen guten Job macht und dass er das verbessern kann (natürlich nur, wenn dies der Fall ist) . Ich würde der Antwort von @The Snark Knight zustimmen, dass Sie ihm nicht alles auf einmal aufzwingen sollten, sondern eine Sache nach der anderen. Stellen Sie jedoch sicher, dass dieser Aspekt verstanden und gut demonstriert wird.

Irgendwelche Vorschläge, wie ich diesen Übergang ein wenig besser glätten könnte?

Was Sie brauchen, ist Zeit und Geduld mit ihm. Was Ihren und seinen Schmerz lindern könnte, ist, ein 4-Phasen-Modell zu erstellen (ich kenne nur den deutschen Begriff und habe keine englischen Links gefunden).

1. Auftrag: ihm, Dinge zu tun: hier braucht er Anleitung, was und wie Dinge zu tun sind.
2. Erklären Sie: warum Dinge so gemacht werden sollten
3. Teilnehmen: Überprüfen Sie, ob Ihre Richtlinien eingehalten werden. besprechen Sie mit ihm/dem Team, ob und wie sie sich verbessern sollten
4. Delegierter: Diese Phase ist meiner Meinung nach in diesem Fall nicht anwendbar.

Prüfen Sie bei jeder Aufgabe bzw. Standard, in welcher Phase Sie ihn absetzen und entsprechend handeln würden. Seien Sie sich bewusst, dass einige Leute nicht unbedingt zur nächsten Phase übergehen werden.

Eine allgemeine Anmerkung, die völlig auf Meinungen basiert und nicht als Beleidigung verstanden werden sollte. Ich denke, Sie haben eine großartige Gelegenheit mit ihm verpasst, als Sie ihn die unkritischen Aufgaben lockern ließen, denn wenn Sie ihn damals gedacht hätten, müssten Sie jetzt nicht kämpfen. Wenn ein neuer Mitarbeiter in Ihr Team kommt, stellen Sie sicher, dass Sie von Anfang an Maßstäbe setzen.

Ein Feature so weit zu entwickeln, dass es akzeptiert wird, braucht Zeit. Es dauert weniger Zeit, wenn Sie niedrigere Standards haben, es dauert länger, wenn Sie höhere Standards haben (obwohl erwartet wird, dass die zusätzliche Zeit später durch weniger unvorhergesehene Probleme zurückkommt).

Das Problem, das Sie beide frustriert, ist, dass sich dieser Mitarbeiter derzeit zu sehr darauf konzentriert, schnell zu liefern, und Sie konzentrieren sich darauf, in hoher Qualität zu liefern, und dies kollidiert (ich gehe davon aus, dass die Zeit bis zur Annahme seines Codes nicht das Problem ist, sondern die drei- oder viermal vor und zurück ist). Machen Sie also deutlich, dass eine längere Lieferzeit kein Problem ist, sondern dass er versucht zu liefern, wenn die Arbeit erst zur Hälfte erledigt ist.

Ich denke, der Versuch zu erklären, warum Änderungen vorgenommen werden sollten, könnte zu Frustration führen. Das sollte er wissen. Er könnte von einem Ort kommen, der wegen lächerlicher Fristen unter schlechter Qualität gelitten hat, und tut, was in diesem Umfeld am besten ist – was an Ihrer Stelle nicht angemessen ist.

Das Problem ist nur sein Entwicklungsprozess. Sein Entwicklungsprozess ist derzeit: 1. Code schreiben, der funktionieren könnte (keine offensichtlichen Fehler). 2. Es gibt keinen Schritt 2. Also sagen Sie ihm einfach, dass der Prozess sein sollte: 1. Schreiben Sie Code, der funktionieren könnte (keine offensichtlichen Fehler). 2. Schreiben Sie Tests, die bei Fehlern fehlschlagen würden. 3. Beheben Sie beim Testen gefundene Fehler und wiederholen Sie den Vorgang, bis keine Fehler mehr gefunden werden. 4. Gehen Sie alle Arbeiten durch und machen Sie sie so weit wie möglich wartbar und zukunftssicher. (Man könnte argumentieren, dass diese vier Schritte nicht optimal sind, aber sie sind besser als nur ein Schritt).

Beachten Sie, dass der nächste Job desselben Entwicklers ihn möglicherweise mit einem leitenden Entwickler konfrontiert, der sagt: "Warum verschwenden Sie Ihre ganze Zeit damit, Tests zu schreiben, Ihren Code wartbar und zukunftssicher zu machen, liefern Sie ihn einfach so aus, wie er ist, und lassen Sie die Kunden sich beschweren". Ich hoffe nicht :-(

„Einige der frühen Dinge, an denen diese Person gearbeitet hat, waren weniger geschäftskritisch … Diese Person hat kürzlich begonnen, an wichtigeren Komponenten zu arbeiten … [Ich musste] denselben Code drei- oder viermal zurückschicken … " ... "Lass uns alles richtig machen, bevor wir weitermachen" zu schnell. In diesem Sinne ...

Entwickeln Sie eine dokumentierte Richtlinie, die einfach und leicht zu befolgen ist, und verwenden Sie anerkannte Standards und Verfahren, die:

• Anerkannte Best Practices

Es gibt nichts Schlimmeres als die Idee eines Typen : Die Leute werden sagen: "Wo hast du das gelernt?", und die Antwort lautet: "Jemand hat mir gesagt, ich soll das tun." - Eine nicht übertragbare Fähigkeit.

• Anerkannte Werkzeuge

Es gibt nichts Schlimmeres als irgendeinen schlampigen Hack: Die Leute werden sagen "Wo hast du das gelernt?", und die Antwort ist "Jemand hat mir gesagt, ich soll das tun." - Eine nicht übertragbare Fähigkeit.

• Anerkannte Qualitätskontrolle

Es gibt nichts Schlimmeres als die ausgefallene Idiotenform eines Typen: Die Leute werden sagen: "Wo hast du das gelernt?", und die Antwort lautet: "Jemand hat mir gesagt, ich soll das tun. " - Eine nicht übertragbare Fähigkeit.

Nicht übertragbare Fähigkeiten werden nirgendwo anerkannt, außer an dem Ort, an dem sie entwickelt wurden. Sie entstehen aus Menschen, die nie gelernt haben, wie man Dinge richtig macht, die sich ihren Weg durchs Leben rätseln, sie sind Affen-Schreibmaschine und Ingenieurshammer auf ihre Art.

Ich war an vielen Orten, an denen Leute auf mich zukamen, um zu sagen, dass "sie diese Abteilung seit mehreren Jahren leiten" oder "wir machen das seit Jahrzehnten so" - das ändert nichts an der Tatsache, dass dies der Fall ist falsch, es ist ein Fehler, ein Fehler, der nicht fortgesetzt werden sollte.

Ein Teil meiner Einstellungsbedingungen ist: Ich unterrichte keine Grundlagen, und Grundlagen lehren mich nicht (keine Unterbrechungen durch aussehende Lous und bekennende Experten , es sei denn, Sie möchten das Dreifache bezahlen; denn so viel kostet es). Firmeninhaber verstehen das, nachdem sie es von ein paar Dutzend Leuten gehört oder Best Practices gelernt haben, bevor sie ein Unternehmen gründen.

Indem Sie die Dinge richtig tun, wissen Ihre Mitarbeiter, dass das, was sie tun, einen Wert hat (über den gesunden Gehaltsscheck hinaus). Der Versuch, Menschen dazu zu bringen, Dinge zu tun, von denen sie wissen, dass sie falsch sind, für einen gemeißelten Gehaltsscheck, wird immer auf einigen Widerstand stoßen, manchmal auf großen Widerstand.

• Stellen Sie sicher, dass der Manager eine gute Schule besucht hat und mit den Industriestandards Schritt hält.

Einige nützliche Lektüre ist:

Holzmanns „ The Power of Ten – Rules for Developing Safety Critical Code “.

JPLs „ JPL Institutional Coding Standard for the C Programming Language “ (Version: 1.0).

Finden Sie Ihre eigenen Best Practices heraus und erklären Sie, warum das wichtig ist – es hält sie beschäftigt.

• Verwenden Sie eine Reihe anerkannter automatisierter Checker.

Es ist einfach auszuführen und zu rechtfertigen, außerdem gibt es eine spezifische Liste von Dingen, die behoben oder erklärt werden müssen. Dies reduziert Ihre Arbeitsbelastung, Konflikte und ermöglicht ein einfaches Upgrade auf besseren Code.

• Verwendung von QC

Es gibt BS-, IEEE-, ISO- und MIL-Standards usw. - verwenden Sie das Zutreffende.

• Wenn es wichtig ist - Nicht: Unteres Fass akzeptieren, reinigen, bezahlen oder unterrichten .

Hier einige konkrete Fragen:

Wie kann ich meinem Programmierer helfen, eine positivere Einstellung dazu zu haben, dass ich seinen Code häufig für Änderungen zurücksende?

Erklären Sie den Unterschied zwischen dem, was sie früher taten, und dem, was sie jetzt tun.

Erklären Sie, dass Sie den Code nicht 3 oder 4 Mal zurücksenden möchten, da es schneller und besser wäre, ihn selbst zu reparieren, was den Zweck zunichte macht, ihn oder jemand anderen tun zu lassen.

Wenn sie eine Beförderung und eine höhere Bezahlung wollen, muss es verdient werden, keiner von Ihnen möchte 3 oder mehr Umschreibungen desselben Codes und das Einführen neuer Probleme (einschließlich Zorn) ist etwas, das nicht fortgesetzt werden kann.

Wenn sie die Arbeit nicht erledigen können, muss dies herausgefunden und eine Entscheidung getroffen werden, wie es weitergehen soll.

Manchmal passieren Fehler, das ist verständlich; Die Babysitterzeit muss in naher Zukunft zu Ende gehen. Mission Critical Code ist wie es sich anhört, weder ein Spiel noch ein Witz.

Ist das ein Zeichen dafür, dass ich andere Dinge falsch mache?

„Um es klar zu sagen, meine eigenen Code-Reviews sind nicht einfach „Das ist falsch, beheben Sie es“, sondern beinhalten eine Menge Details, die erklären, was das Problem ist, warum es in Zukunft Probleme verursachen wird und warum es besser sein wird uns allen, es gleich beim ersten Mal richtig zu machen. Ich versuche, der Person zu helfen, zu erkennen, wie wichtig es ist, dies von Anfang an richtig zu machen, auch wenn es dadurch mehr Zeit in Anspruch nimmt.“

Es sieht nicht so aus, als wäre es deine Schuld, außer dem Teil mit dem Übererklären und Babysitten; Vielleicht haben Sie sie zu schnell befördert, das könnten wir Ihnen vorwerfen. Der Eigentümer zahlt genug, nicht wahr?

Irgendwelche Vorschläge, wie ich diesen Übergang ein wenig besser glätten könnte?

Ich schätze, Sie müssen sich etwas zurücknehmen, was ihnen zugeteilt wird, und mehr Zeit dafür einplanen.

Wenn sie einen fertigen Job abgeben, geben Sie das Ganze zurück und sagen Sie, dass Sie sie dazu befördern, ihre eigene erste Codeüberprüfung durchzuführen, und hier sind zusätzliche X Stunden dafür.

Wenn das besser wird, waren die Fristen zu kurz, wenn es nicht besser ist, zu erklären, dass X Stunden zusätzlich angeboten wurden, aber es gibt immer noch eine unannehmbare Anzahl von Problemen.

Das könnte Ihre Arbeitsbelastung durch mehrere Überprüfungen verringern und sie weniger gestresst zurücklassen; eine Win-Win-Situation.

Manche Menschen haben einfach ein Niveau, das „gut genug“ ist, sie sind kurzsichtig und können nicht darüber hinaus sehen. Jegliches Anstacheln oder Erklären über das hinaus, was sie wissen, wird einfach abgelehnt, das ist etwas, wofür Sie nicht bezahlen möchten (im Voraus oder zurück vom Kunden).

Wenn sie "ein mittlerer Ingenieur" sind, sollten sie verstehen, was Sie sagen. Wenn sie weniger als 6 Monate von der Schule entfernt sind, tun sie dies möglicherweise nicht. Vielleicht erfreuen sie sich einfach daran, dass mit der Zeit alles einfacher wird ...