Mitarbeiter zu besseren Codierungspraktiken inspirieren?

24

In der Frage Umgang mit meinen veralteten Mitarbeitern diskutierten verschiedene Personen Strategien für den Umgang mit Mitarbeitern, die nicht bereit sind , ihren Workflow in den des Teams zu integrieren.

Ich möchte, wenn möglich, einige Strategien für „Lehre“ ein Mitarbeiter lernen , die nur ist unwissend von modernen Techniken und Werkzeugen, und möglicherweise ein wenig apathisch.

Ich habe angefangen, mit einem Programmierer zu arbeiten, der bis vor kurzem in einem anderen Teil des Unternehmens in relativer Isolation gearbeitet hat. Er verfügt über umfassende Fachkenntnisse und vor allem über gute Fähigkeiten zur Problemlösung , die vielen Kandidaten zu fehlen scheinen.

Der tatsächliche (C #) Code, den ich gesehen habe, ist jedoch ein Rückfall auf die VB6-Tage. Prozedurale Struktur, ungarische Notation, globale Variablen (Missbrauch von static), keine Schnittstellen, keine Tests, keine Verwendung von Generika, Werfen System.Exception... Sie bekommen die Idee.

Dieser Programmierer ist ein bisschen älter als ich und sucht zumindest nach dem ersten Eindruck nicht aktiv nach einer positiven Veränderung. Ich werde nicht sagen , dass ich gegen Veränderungen resistent bin , denn ich denke, das ist hauptsächlich eine Frage, wie das Thema angesprochen wird , und ich möchte darauf vorbereitet sein.

Programmierer neigen dazu, hartnäckige Leute zu sein, und es ist sehr wahrscheinlich, dass sie nicht das Endergebnis erzielen, das ich will , wenn sie mit brennenden Waffen und der Einführung von Codeüberprüfungen und strikt durchgesetzten Richtlinien vorgehen. Wenn dies eine neue Einstellung wäre, ein Juniorprogrammierer, würde ich nicht zweimal überlegen, ob ich eine "Mentor" -Stellung einnehmen soll, aber ich bin äußerst vorsichtig, einen erfahrenen Mitarbeiter als ahnungslosen Neuling zu behandeln (was er nicht ist - er hat es einfach nicht) mit bestimmten Fortschritten auf dem Gebiet Schritt gehalten).

Wie könnte ich vorgehen, um den Code-Qualitätsstandard dieses Entwicklers auf die Weise von Dale Carnegie anzuheben, durch sanfte Überzeugung und immaterielle Anreize? Was wäre die beste Strategie, um subtile, schrittweise Änderungen vorzunehmen, ohne eine kontroverse Situation zu schaffen?

Waren schon andere Leute - insbesondere leitende Entwickler - in einer solchen Situation? Mit welchen Strategien konnte das Interesse geweckt und eine positive Gruppendynamik erzeugt werden? Welche Strategien waren nicht erfolgreich und sollten besser vermieden werden?


Klarstellungen:

Ich habe wirklich das Gefühl, dass mehrere Personen aufgrund persönlicher Gefühle antworten, ohne alle Details der Frage zu lesen. Bitte beachten Sie das Folgende, das hätte impliziert werden sollen, aber ich mache es jetzt explizit:

  • Dieser Mitarbeiter ist aufgrund seines Alters nur mein "Senior". Ich habe nie gesagt, dass sein Titel, sein Einflussbereich oder seine Jahre in der Organisation meinen übersteigen, und tatsächlich ist keines dieser Dinge wahr. Er ist ein LOB-Programmierer, der in die Hauptentwicklungsabteilung aufgenommen wurde. Das ist es.

  • Ich bin kein Neuling, Junior-Programmierer oder anderer naiver Idiot mit großen Plänen, das Unternehmen über Nacht zu verändern. Grundsätzlich bin ich für den Softwareprozess verantwortlich, aber so viele, die als "Leads" gearbeitet haben, wissen, dass Verantwortlichkeiten nicht immer genau mit dem Organigramm korrelieren.

  • Ich frage die Leute nicht , wie sie meinen Weg finden sollen . Ich könnte das tun, wenn ich wollte, mit dem Nettoergebnis, dass diese Person ärgerlich wird und / oder aufgibt. Bitte versuchen Sie zu verstehen, dass ich nach einer sozialen , kooperativen Methode suche, um Veränderungen voranzutreiben.

  • Die Erwähnung von "... globalen Variablen ... keine Tests ... werfen System.Exception" sollte zeigen, dass die Probleme nicht nur oberflächlich oder ästhetisch sind . Praktiken, die für relativ kleine CRUD-Apps funktionieren, funktionieren möglicherweise nicht unbedingt für große Unternehmens-Apps, und tatsächlich hat bisher keiner der Codes die Integrationstests bestanden.

Bitte nehmen Sie die Frage zum Nennwert, akzeptieren Sie, dass ich tatsächlich weiß, wovon ich spreche, und beantworten Sie entweder die Frage, die ich tatsächlich gestellt habe, oder fahren Sie fort.

PS: Mein aufrichtiger Dank gilt denen, die konstruktive Ratschläge gegeben haben, anstatt mit der Prämisse zu streiten. Ich werde dies noch eine Weile offen lassen, da ich hoffe, mehr über die Erfahrungen der realen Welt zu erfahren.

Aaronaught
quelle
9
Ich war in dieser Situation und habe nie gesehen, dass sie wirklich erfolgreich gelöst wurde. Viele Menschen, wie Sie beschrieben haben, haben vor Jahren aufgehört, über Programmierung nachzudenken. Derzeit interessieren sie sich nur für Lösungen für ihren Geschäftsbereich. Ich werde mich den Bandwagons auf dieser Seite nicht anschließen, die solche Leute verurteilen. in der Tat denke ich, dass sie das Salz der Erde sind. Wenn sie in Ihrem Code funktionieren, sollten Sie darauf drängen, zumindest Ihre Konventionen einzuhalten. Es fiel mir nicht schwer zu verkaufen, dass die Leute bestehende Konventionen befolgen sollten, wenn sie zu einem Projekt beitragen.
Jeremy
1
Was hat Ihr Chef gesagt, als Sie diese Besorgnis über ihn geäußert haben?
2
@Aaronaught, da sein Code funktioniert, ist dies kein technisches, sondern ein politisches Problem, das wahrscheinlich von oben auferlegt werden muss, wenn Sie etwas ändern möchten. Mit anderen Worten von Ihrem Chef. Habe gute Argumente parat!
2
@Thor: Du denkst also, es ist absolut unmöglich, dass sein Stil einfach das Produkt niedriger Erwartungen, keiner Beurteilung durch Fachkollegen und eines geschäftigen Lebens ist, das sich nicht gut zum selbständigen Lernen während der eigenen persönlichen Zeit eignet? Nicht fürsorglich zu sein ist kein festverdrahtetes Persönlichkeitsmerkmal, es ist ein Produkt der eigenen Umwelt und kann geändert werden. Nicht zu wissen ist noch einfacher zu ändern, aber es muss immer noch mit einem gewissen Maß an Diplomatie angegangen werden.
Aaronaught
1
@Aaronaught, entweder hast du es kläglich versäumt, eine Inspiration zu sein (was nicht ausgeschlossen werden kann) oder er will nicht inspiriert werden. Würden Sie in Betracht ziehen, Ihre Unit-Tests in Lisp oder Haskell zu programmieren, wenn Ihnen ein jüngerer Kollege sagen würde, dass dies viel intelligenter ist als das, was Sie jetzt tun?

Antworten:

10

Ausgangspunkt ist das Kennenlernen Ihres Publikums . Sie scheinen dies bereits zu verstehen, weil Sie den Unterschied zwischen der Betreuung eines Junior-Mitarbeiters und der Beeinflussung eines Senior-Mitarbeiters kennen.

Sie müssen noch herausfinden, was diese bestimmte Person motiviert. Was bei einem alten Knacker (wie mir) funktioniert, funktioniert bei Ihrem alten Knacker möglicherweise nicht.

Wenn er gerne andere unterrichtet, können Sie sich einem Problem mit Fragen wie "Warum machen Sie das so?" Nähern. Das kann zu einem Dialog führen, in dem Sie ihn bitten können, neuere Ansätze zu bewerten und seine Meinung zu äußern.

Wenn das nicht funktioniert, können Sie auf Fehler hinweisen, die vermieden werden können, indem Sie die Methoden oder Stile verwenden, die er übernehmen soll. Dies erfordert viel mehr Arbeit, da Sie die Fehler finden und zeigen müssen, wie das Verhalten, das Sie fördern möchten, helfen würde.

Wenn er bereit zu sein scheint, anderen zu helfen, könnten Sie seinen Wunsch ansprechen, den Neulingen zu helfen . Erklären Sie, dass "Kinder heute" nicht daran gewöhnt sind, seinen Codierungsstil zu sehen, und dass dies die Wahrscheinlichkeit erhöht, dass sein Code dadurch beschädigt wird.

Manchmal muss man ihm nur ins Gesicht sehen und die Angelegenheit erzwingen. Sie müssen diese Schlachten sorgfältig auswählen. Beginnen Sie mit einem Thema, von dem Sie wissen, dass Sie ihm beweisen können, dass Sie einen besseren Weg haben.

Jimreed
quelle
Dies scheinen einige gute allgemeine Strategien zu sein. Ich sollte klar sein, dass dies nur VB6-alt ist, nicht COBOL-alt. Vielleicht 5-7 Jahre hinter der Zeit, nicht 20-30 Jahre. Also kein Geezer / Dinosaurier.
Aaronaught
1
Ich würde nicht fragen "Warum machst du das so?" Dies könnte sich nachteilig auswirken, da er / sie sofort in die Defensive gerät. Es könnte sein, dass der Mitarbeiter es einfach nicht weiß und Sie nicht möchten, dass er sich unwissend fühlt. Fragen Sie stattdessen "Haben Sie diese Methode in Betracht gezogen?"
IAbstrakter
@IAbstract Wenn er gerne unterrichtet, wird er nicht defensiv, sondern genießt die Gelegenheit zu unterrichten. Ton und Haltung werden einen großen Unterschied machen. Wenn es so klingt, als könnten Sie am Ende der Frage leicht "Idiot" hinzufügen, dann tun Sie es nicht richtig? :-) Nach meiner Erfahrung sind die meisten Menschen bereit, aufrichtige Fragen zu beantworten.
1.
@IAbstract: Ich bin mir ziemlich sicher, ob ich gefragt habe, ob Sie hier eine Abhängigkeitsinjektion in Betracht gezogen haben. die antwort wäre "huh?" Natürlich besteht die Möglichkeit, dass ich angenehm überrascht bin, aber ich denke, Jim hat Recht. Es ist ein besserer Gesprächsstarter, zu fragen: "Warum haben Sie sich entschieden, hier ein FooObjekt mit globalem Geltungsbereich zu verwenden ?" Ich sehe nicht voraus, dass dies als Angriff interpretiert wird. Ich bin es, der versucht, das existierende Design zu verstehen.
Aaronaught
@Aaronaught: fair genug;) Während die Reaktion auf DI "huh?" Sein mag, könnte sie ein interessantes Gespräch auslösen, wie "nun, ich habe davon gehört, aber ..." ... meine Sorge ist hauptsächlich der Ton (wie Jimreed betont) Natürlich muss man, wie Jimreed sagt, seine Schlachten auswählen - manchmal bedeutet es, einen großen Stock zu tragen, manchmal bedeutet es, zusammen im Sandkasten zu spielen.
IAbstrakter
4

Ich denke, dass Sie die richtige Einstellung haben. Stellen Sie einfach sicher, dass Sie darauf hinweisen, all die netten Dinge zu sagen, die Sie bereits gesagt haben - großartige Fähigkeiten zum Lösen von Problemen, hervorragende Kenntnisse des Geschäfts usw., und bitten Sie ihn nur um ein wenig Zeit, um ihm den aktuellen Standard der Gruppe zu zeigen Verwenden Sie und geben Sie ihm die Gelegenheit, einige Fragen zu stellen.

Wenn Sie sich treffen, bringen Sie ihm einen Kaffee oder etwas, und lassen Sie ihn wissen, dass das Einhalten der Standards ihm hilft, indem es ihm leichter fällt, Ihren vorhandenen Code zu unterstützen, und es auch erleichtert, dass jemand ihm helfen kann, wenn er es tut wird in der Arbeit abgedeckt (ein großes Plus für jemanden, der isoliert gearbeitet hat), etc.

Stellen Sie sicher, dass er engagiert ist und gute Erklärungen dafür erhält, warum Sie die Dinge tun, die Sie tun, und konzentrieren Sie sich nicht darauf, warum er die Dinge, die er getan hat, nicht tun sollte. Bringen Sie andere Leute mit, wenn Sie müssen, und lassen Sie sie es Ihnen erklären. Stellen Sie sich anschließend zur Verfügung, wenn er Fragen hat, und geben Sie einige Stellen an, auf die er sich beziehen kann, um Beispiele für Ihre Standards zu erhalten.

Wenn er danach nicht interessiert ist, können Sie sich auf die erste Frage beziehen, die Sie verlinkt haben.

DKnight
quelle
4

Es ist wirklich die Aufgabe Ihres Managers

  1. Stellen Sie fest, dass das Unternehmen einen Kodierungsstandard haben muss . Jedes etwas professionelle Unternehmen hat dies, egal wie groß das Unternehmen ist.
  2. Bringen Sie alle dazu, sich zusammenzusetzen und einen Standard zu erarbeiten. Auf diese Weise kann jeder mitreden und ist motivierter, dem Standard zu folgen.

Wenn Ihr Vorgesetzter dies nicht selbst merkt, ist er nicht für seinen Job qualifiziert. Und wenn ja, sollten Sie ihnen einen Anstoß über die beiden oben geben. Die Vorteile eines Kodierungsstandards sind so vielfältig, dass es wirklich keine Argumente gegen einen gibt. (Wenn einige Programmierer das Gefühl haben, "Künstler" zu sein und nicht an die Grenzen der Professionalität gebunden zu sein, sollten sie stattdessen einen Job in der bildenden Kunst bekommen.)

Der Kodierungsstandard an sich sollte sich in erster Linie darauf konzentrieren, gefährliche Praktiken und gefährliche Bibliotheksfunktionen zu verbieten. Arbeiten Sie auf eine sicherere und reinere Untergruppe der von Ihnen verwendeten Sprache hin. Halten Sie den Codierungsstandard frei von "Codierungsstil", da der Codierungsstil weitaus schwieriger zu vereinbaren und bei weitem nicht so wichtig ist. Es ist ziemlich klassisch, dass sich ein Unternehmen für einen Kodierungsstandard entscheidet und dann sofort in einer heftigen Unsinndiskussion feststeckt, wo die {} Klammern platziert werden sollen.

Lesen Sie als Referenz, wie die Standards MISRA-C / C ++ und CERT C / C ++ / Java geschrieben wurden.


quelle
Dies ist die (falsche) Annahme, dass ich für einen Software-Publisher mit vertikaler Struktur arbeite. Weniger als 10% der Entwickler arbeiten für Software-Publisher, und es liegt nicht unbedingt in der Verantwortung einer Führungskraft oder eines mittleren Managers, die Entwickler im Mikromanagement zu verwalten.
Aaronaught
2
@Aaronaught Nun, dann ist das die wahre Quelle deines Problems. Wenn Sie nicht in einem Team mit einem Kodierungsstandard und mindestens einem erfahrenen Programmierer sind, der die anderen anführt und führt, ist das eine schlechte Organisation. Jeder wird nach dem Zufallsprinzip wegcodieren und sich als "Künstler" betrachten, mittelmäßige, instabile und nicht zu wartende Ergebnisse erzielen und nicht lernen, wie man sich verbessert.
2

Zunächst müssen Sie klären, WARUM Sie die Arbeitsweise dieser Person ändern möchten. Wenn es nur aus ästhetischen Gründen ist, sollten Sie es sich überlegen, denn diese Person hat gezeigt, dass ihre Arbeitsweise tatsächlich funktioniert.

Wenn es jedoch einen technischen Grund dafür gibt, sollten Sie darüber nachdenken, sich mit etwas wie Folgendem an diese Person zu wenden:

Ich habe einen Vorschlag, wie Sie mühsame Zeit für Sie und Geld für das Unternehmen sparen können. Bist du interessiert?

Beachten Sie, dass dies niedrig hängende Früchte sein sollten, da sie höchstwahrscheinlich eine Änderung bestehender Gewohnheiten erfordern, die immer zusätzlichen Aufwand erfordern.

Selbst wenn Sie eine Unmenge von Vorschlägen haben, wählen Sie einfach einen oder zwei aus und zeigen Sie, dass dies eine Veränderung zum Besseren sein wird.

Entweder funktioniert dies, und Sie werden gefragt, ob Sie weitere Vorschläge haben, oder es wird nicht funktionieren, und dann ist der Schaden auf ein oder zwei Vorschläge beschränkt.

Beachten Sie, dass es sehr wichtig ist, dass es ein Erfolg wird und es schnell erledigt.

Auch müssen Sie vorsichtig sein. Es mag sehr gute Gründe dafür geben, Dinge so zu machen, wie sie gemacht werden, aber Sie sind zu neu, um zu verstehen, warum. Seien Sie daher respektvoll gegenüber Ihrem Ältesten und fragen Sie, bevor Sie davon ausgehen, dass Ihr Vorschlag besser ist. Sie könnten ein oder zwei Dinge lernen.

Aaronaught
quelle
Vielen Dank für die konstruktive Antwort - obwohl ich denke, dass es ohne den ersten Absatz hätte auskommen können.
Aaronaught
@aaronaught, sorry, aber es ist eigentlich ganz wichtig.
Nein, das ist wirklich nicht wichtig. Es wird eine völlig andere Frage beantwortet, und ich habe bereits einige klarstellende Kommentare und Änderungen vorgenommen, um darauf hinzuweisen, dass sie nicht relevant sind. Die Unfähigkeit der Benutzer dieser Site (und meistens nur dieser Site), die Frage "Soll ich" von "Wie kann ich" zu trennen, wirkt sich aktiv auf die Gesamtqualität und Kohärenz des hier behandelten Diskurses aus. Ihre Einschränkung ist gültig, aber irrelevant und leicht anstößig. Zu diesem Thema gibt es sogar eine sehr hoch bewertete Meta-Frage .
Aaronaught
1
@aaronaught, der einzige Grund, aus dem Sie angeben, dass Sie den Codierungsstil dieser Person ändern möchten, ist, dass er sich vom Rest des Teams unterscheidet, und dass Sie dann implizit seinen Stil angeben, dass Ihr Stil besser ist. Daher mein Kommentar. Wenn Sie seinen aktuellen Codierungsstil in Ihrer Codebasis nicht akzeptieren können, nehmen Sie ein persönliches Gespräch mit ihm auf und sagen Sie dies. Sie sind bereit, große Anstrengungen zu unternehmen, um zu lernen, wie Sie seinen Code benötigen.
1
@Aaronaught, für jemanden, der ohne den ersten Absatz hätte auskommen können, finde ich Ihre Wortwahl überraschend anstößig. Glaubst du, dass es ein Beispiel ist, andere als erbärmlich zu bezeichnen?
1

Ich möchte Sie dringend davon abhalten, ihm ins Gesicht zu sehen, da sich die Situation dadurch sehr schnell verschlechtern würde. Mir ist klar, dass es sich um eine letzte Maßnahme handelt, aber meiner Erfahrung nach hat der Entwickler zu diesem Zeitpunkt die Teilnahme praktisch eingestellt.

Das Erzwingen des Problems könnte die Person in einen Feind verwandeln, in dem sie mit jeder Ihrer Aktionen kämpft. Das hätte wirklich negative Auswirkungen auf das Team und hört nicht auf, bis jemand aufgibt oder entlassen wird.

Wenn diese Person wirklich Domänenwissen hat, das Sie benötigen / möchten, lassen Sie sie dieses Wissen dokumentieren.

Ken Brittain
quelle
1
-1 Die Frage besagt bereits, dass das OP nicht die Absicht hat, dies konfrontativ anzugehen. Bitte lesen Sie die Frage des OP sorgfältig durch und beantworten Sie diese spezifische Frage , anstatt das Thema im Allgemeinen zu diskutieren.
HedgeMage
1

Beginne damit, es ihm sanft zu sagen: Ich weiß nicht, wie erfahren und wie gut du darin bist, Feedback zu geben. Sie könnten ja schon folgendes wissen, anstellen oder sogar abgelehnt haben, aber hier geht es trotzdem. Es gibt einige Richtlinien, wie Sie Feedback geben können, wenn Sie das Verhalten einer Person ändern möchten. Die Konversationsstruktur, über die ich nachgedacht habe und die ich immer noch in Situationen einsetzen möchte, in denen ich Feedback geben möchte (weil sie funktionieren), sind die folgenden:

  1. Beschreiben Sie das Verhalten, das Sie sehen. Dies muss ein konkretes Verhalten sein. Beispiel: "Ich sehe, dass Sie viele statische Variablen in Ihrem Code verwenden"
  2. Beschreiben Sie, wie sich das auf Sie / Ihr Team auswirkt. Beispiel: "Ich finde solchen Code schwer zu pflegen"
  3. Bieten Sie eine vernünftige Lösung. (Mögliche Lösungen werden in anderen Antworten erwähnt, und ich werde mich später selbst mit dieser Antwort befassen.)
  4. Geben Sie ihm die Gelegenheit, die Lösung zu besprechen. Fragen Sie ihn, was er von der Lösung hält. Nehmen Sie seine Antwort zum Nennwert. Sie haben ihm Ihre Meinung mitgeteilt, und er kann sie akzeptieren oder nicht. *

Eine schnelle Quelle für Feedback finden Sie beispielsweise unter http://managementhelp.org/communicationsskills/feedback.htm (obwohl es im Internet eine Unmenge solcher Dinge gibt).

Was nun den Lösungsteil betrifft, so ist er nach dem, was ich in Ihrer Antwort lese, ziemlich schlau und hat die richtige Einstellung, aber er ist in modernen guten Praktiken nur im Rückstand. Diese erfordern Zeit und Mühe, um sie zu meistern, abgesehen davon, dass Sie sie tatsächlich kennenlernen. Sie müssen ihm also die Möglichkeit geben, dies zu tun. Das bedeutet wahrscheinlich, Lernressourcen (Web, Magazin, Bücher usw.) als Ausgangspunkt zu sammeln und ihm Zeit zum Lernen zu geben. Ich könnte mir vorstellen, ihn jeden Freitagnachmittag zu geben, um seinen Horizont für den Programmierstil zu erweitern, wo er alles tun kann, was seiner Meinung nach diese Ziele fördert. Die Menschen wollen sich von Natur aus verbessern. Stellen Sie die Materialien und die Zeit zur Verfügung, und sie werden sie gut nutzen.

Am wichtigsten ist möglicherweise, dass Sie nicht über Nacht mit Veränderungen rechnen müssen. Er hat lange Zeit alles auf seine Art gemacht und ist wahrscheinlich ziemlich gut darin geworden. Es wird einige Zeit dauern, bis er auf eine neue Art und Weise so gut wird, und für eine Weile wird er wahrscheinlich nicht viel Wert auf neue Art und Weise sehen, denn am Anfang gibt es keine. Sein alter Weg wird wahrscheinlich für eine Weile effektiver sein.

* Hinweis: Das Lustige an Gesprächen ist, dass sie sehr schwer zu modellieren sind. Sie haben ein Eigenleben, und obwohl es auf dem Papier gut aussieht, neigt es dazu, ein bisschen matschig zu werden.

Martijn
quelle
0

Erklären Sie, wie Sie die Dinge erledigen möchten, und zeigen Sie ihm, wie es mit den Design- und Architekturentscheidungen funktioniert, die Sie zu Beginn des Projekts getroffen haben, an dem er arbeiten wird. Setzen Sie sich eins zu eins (und privat) und erklären Sie die Probleme, die Sie in seiner vorherigen Codierung gesehen haben, und warum sie ein Problem für dieses Projekt sind. Fragen Sie ihn, was er braucht, um besser zu werden, aber stellen Sie klar, dass es keine Option ist, nicht besser zu werden.

Verwenden Sie dann die Codeüberprüfung als Werkzeug, um ihn zu veranlassen, seine Arbeitsmethoden anzupassen. Planen Sie eine gute Zeit für den ersten ein und sprechen Sie wirklich darüber, warum Sie dies dem vorziehen und lassen Sie ihn seine Argumentation erklären. Stellen Sie sicher, dass Sie ihm wirklich zuhören. Die Menschen können sich besser verändern, wenn sie das Gefühl haben, dass ihre Bedenken ausgeräumt wurden. Erwarten Sie in Ihrer Planung (aber sagen Sie ihm das nicht), dass Sie die erste Aufgabe überarbeiten und nicht annehmen, bis sie den Standards Ihres Teams entspricht. Sobald er weiß, was Sie erwarten und dass Sie es nicht im Interesse der Zeit verrutschen lassen, wird er wahrscheinlich zu Ihrer Arbeitsweise kommen. Möglicherweise möchten Sie die Codeüberprüfung jedoch als Lehrmittel für mehrere Iterationen verwenden. Sie müssen nicht böse sein, wenn Sie die Arbeit nicht akzeptieren, bis sie Ihren Standards entspricht, aber Sie müssen sie konsequent und konsequent umsetzen. Don'

HLGEM
quelle
-1

Die 64.000-Dollar-Frage ist, ob er seine Projekte pünktlich liefert und die Funktionsanforderungen erfüllt. Wenn ja, macht er es richtig. In der Softwareentwicklung gibt es keinen objektiven Weg nach rechts oder nach rechts. Letztendlich geht es darum, Probleme zu lösen. Und wenn Probleme zur Zufriedenheit des Kunden gelöst werden, dann wird die Softwareentwicklung per Definition korrekt durchgeführt.

Es wird eine ganz andere Frage natürlich , wenn seine Projekte Arent abgeschlossen. An diesem Punkt müssen Änderungen von Ihren Vorgesetzten vorgenommen werden, möglicherweise mit Ihrer Eingabe. Aber nur weil er Ihren persönlichen Sinn für Code-Ästhetik oder die heutige konventionelle Weisheit verletzt, heißt das noch lange nicht, dass er "falsch" ist. Sie sind nicht der Schiedsrichter der Definition von 'gutem Code'. Er könnte immerhin eine geringe Meinung zu Ihrem Code haben.

Also ... wenn es nicht tatsächlich ein Problem mit seiner Arbeit gibt (was Sie nicht angegeben haben), tun Sie nichts. Ein Teil des Erfolgs eines Entwicklers besteht darin, zu lernen, Ihren Code mit den Stilen anderer Entwickler zusammenzuführen.

Er könnte schließlich hierher kommen und eine ähnliche Frage zum Umgang mit einem weniger erfahrenen Entwickler stellen, der sich mehr darum kümmert, mit Modeerscheinungen Schritt zu halten, als Projekte abzuschließen. Es geht nur um Perspektive.

GroßmeisterB
quelle
2
Aus diesem Grund habe ich darauf hingewiesen, dass er aus einem anderen Unternehmensteil stammt. Er hatte kein Problem damit, ihre Anforderungen zu erfüllen, aber ihre Anforderungen sind nicht unsere Anforderungen. Insbesondere wurden ihre Anforderungen nicht weiter entwickelt als die von CRUD. Und ja, es gibt ein Problem mit dem Code. Es funktioniert möglicherweise isoliert, besteht jedoch keine Integrations-, Leistungs- oder Zuverlässigkeitstests. Ich glaube nicht an strenge Methoden wie XP oder TDD oder was auch immer, aber dies ist keine Frage der Ästhetik oder konventionellen Weisheit, es ist eine Frage der Wartungsanforderungen.
Aaronaught
3
Ich habe dies auch nicht aus den oben genannten Gründen abgelehnt, sondern weil Sie mehrere ungerechtfertigte Annahmen treffen. (a) Ich bin nicht weniger erfahren, (b) keines der Dinge, über die ich spreche, wird zu Recht als "Modeerscheinung" bezeichnet, und (c) dies ist die lächerlichste Annahme - er ist nicht der produktivste Entwickler Das Team und sicherlich nicht produktiver als ich.
Aaronaught
Wenn es tatsächlich ein Problem mit dem gibt, was er produziert, dann ist es, wie gesagt , ein Problem für Ihren Vorgesetzten oder für wen auch immer Ihr gegenseitiger Vorgesetzter ist. Aber Sie haben nicht gezeigt, dass es ein Problem mit dem gibt, was er an den Kunden liefert, nur dass Ihnen das, was er an Sie liefert, nicht gefällt. Das ist mein Punkt, er schreibt keine Software für Sie. Also, bevor Sie für Aufsehen sorgen, stelle ich sicher, dass er nicht weniger entbehrlich ist als Sie.
GroßmeisterB
Was Modeerscheinungen betrifft, bleiben Sie eine Weile in der Branche und Sie werden feststellen, dass die heutigen Best Practices schlechte Praktiken im VB6-Stil von morgen sind. Was Downvoting angeht, fühlen Sie sich frei. Ich beantworte nur die Frage, wie sie veröffentlicht wurde. Ich kann nicht auf Details antworten, die Sie nicht zur Verfügung gestellt haben.
GroßmeisterB
1
Ich kenne Ihren Lebenslauf nicht, noch kenne ich Ihren Lebenslauf Ihrer Mitarbeiter. Ich weiß nur, was Sie in die Frage gestellt haben. Wenn es sich um wichtige Informationen handelte, sollten Sie diese einbeziehen. Und basierend auf Ihren Antworten auf andere Antworten können Sie davon ausgehen, dass Sie einiges ausgelassen haben, was viele Annahmen seitens der Antwortenden erforderlich macht. Wenn Sie jedoch eine Antwort wünschen, müssen Sie, vorausgesetzt Sie sind nicht sein Vorgesetzter, Ihr Vorgesetzter oder das Problem Ihres gegenseitigen Vorgesetzten, sich Sorgen machen, wie Sie kein Aufsehen erregen können. Lehnen Sie einfach den Code ab, der beim Testen ein Problem verursacht, und teilen Sie Ihrem Kollegen das Problem mit.
GroßmeisterB
-1

Als Junior-Entwickler im Gespräch mit einem Senior-Entwickler ist es zu riskant, ihn mit besseren Ideen als seinen eigenen anzusprechen.

Der beste Weg, um damit umzugehen, besteht darin, zu versuchen, Ihren / seinen Chef von einer besseren Vorgehensweise zu überzeugen und herauszufinden, ob er es zu einem Dekret machen wird, dass der gesamte Code bestimmten Standards folgen und durch Peer-Code-Überprüfungen nach diesen Standards durchgesetzt werden muss.

Ein beträchtlicher Teil der Menschen ist (auch wenn sie unterbewusst sind) rachsüchtig, egoistisch und defensiv, auch wenn sie sich ihrer eigenen unterbewussten Motive nicht bewusst sind. Sie werden beleidigt, wenn Sie versuchen, sie zu ändern oder implizieren, dass sie falsch sind sowieso.

Die Befehlskette ist der sicherste Weg, weil er auf seinen Chef hören muss und ihn auch nicht mögen muss. Lass den Chef der Böse sein, dafür ist er da.

Wenn Sie den Chef nicht verkaufen können oder er der Chef ist, dann gehen Sie einfach mit seinen Fehlern um und gehen Sie in IHREM Code mit gutem Beispiel voran.

maple_shaft
quelle
1
Dies beantwortet eine ganz andere Frage als die, die ich gestellt habe. (a) Ich bin kein Junior-Entwickler, (b) mein Chef delegiert bereits die meisten wichtigen Design- und Code-Entscheidungen an mich, (c) sein Code ist nicht als fehlerhaft bekannt, nur für C # nicht gut strukturiert / funktionales gemischtes Paradigma, und (d) das Wesentliche meiner Frage war, wie ich mich dem Thema so nähere, dass sie nicht beleidigt werden.
Aaronaught
1
@Aaronaught, a) "Dieser Programmierer ist ein bisschen älter als ich" Ich habe aus dieser Aussage abgeleitet, dass Sie sein "Junior" sind. b) Hört sich dann so an, als ob Sie der technische Leiter sind. Sie hätten diese Informationen in Ihre Frage stellen sollen, sie ändern die Dinge erheblich. c) Wenn er nicht den Best Practices folgt und sein Code nicht fehlerhaft ist, was ist dann das Problem? Warum sollten Sie sich wegen irgendetwas an ihn wenden? Repariere nicht, was nicht kaputt ist. d) Wenden Sie sich auch hier nicht an ihn, wenn er keine Fehler mit schlechter Codequalität verursacht. Das eigentliche Problem ist, dass Sie keine Kodierungs- und Entwicklungsstandards haben, an die sich jeder halten muss.
maple_shaft
Ich dachte, dass es ziemlich klar impliziert ist, wenn ich mich darauf beziehe (nicht), "mit Waffen zu arbeiten, die lodern, und Codeüberprüfungen durchzuführen und Richtlinien strikt durchzusetzen" - warum sollte ich das überhaupt erwähnen, wenn ich ein Junior wäre? ? Und wer hat gesagt, dass wir keine Standards haben? Er hat noch nie zuvor mit unserem Team zusammengearbeitet und ich versuche, die Standards einzuführen, ohne darüber nachzudenken .
Aaronaught
-1 Hat die gestellte Frage nicht beantwortet.
HedgeMage
-1

Das kannst du nicht.

Sie können Menschen nicht dazu inspirieren, Dinge zu tun, die sie bei der Softwareentwicklung nicht kennen. Ich spreche aus Erfahrung, weil ich dies in meiner Karriere oft versucht habe, und jedes Mal führt dies dazu, dass mein eigener Status in den Augen des Unternehmens abnimmt. Ich bin sogar entlassen worden oder habe frustriert aufgehört, nachdem nichts passiert ist, nur weil ich versucht habe, die Entwicklungskultur um mich herum durch moderne Praktiken zu verbessern.

Wenn Ihr Mitarbeiter nicht unwissend war, können Sie es ihnen zeigen. Sie können jedoch nichts tun, da sie nicht in der Lage sind oder sich nicht genug um Software-as-Craftmanship kümmern, um nach besseren Codierungspraktiken zu streben. Wenn du es versuchst, werden sie es entweder ignorieren oder herumalbern, ohne wirklich zu verstehen, was aus den Geräuschen, die sie bereits machen, hervorgeht ("Trial and Error Development", dh einfach im Code herumhacken, bis die Fehler aufhören). .

Wayne Molina
quelle
4
Ich schätze die Reaktion, aber ich finde es schwer zu glauben, vor allem, weil ich vor einigen Jahren genau diese Art von Programmierer war, der es einfach hinbekam. Niemand hat es mir gezeigt - ich musste es selbst herausfinden -, aber ich bin sicher, dass ein ausreichend überzeugender Führer (wenn einer existiert hätte) in der Lage gewesen wäre, die gleiche Veränderung herbeizuführen. Nur weil einige Leute dies alles unabhängig voneinander lernen, heißt das nicht, dass jeder andere eine verlorene Sache ist.
Aaronaught
2
Das stimmt, aber meiner Erfahrung nach brauchen Menschen, die sich für Verbesserungen interessieren, wenig Motivation, um sich inspirieren zu lassen, da der Wunsch bereits vorhanden ist - sie brauchen vielleicht einen Anstoß oder Rat, aber sie verstehen und wollen sich verbessern, brauchen nur Anleitung. Ich war genauso; Ich lernte schlechte Methoden und dachte: "Es muss einen besseren Weg geben" und begann zu recherchieren. Was ich jedoch gesehen habe, sind die Menschen, die sich nicht verbessern oder einen Wunsch nach Verbesserung zeigen, verlorene Ursachen, weil sie sich nicht verbessern wollen. Das heißt, viel Glück, wenn ich mich irre :)
Wayne Molina
1
Ich denke, das sind Aussagen, die begründet werden müssen. Ich wäre auf jeden Fall daran interessiert, einige Erfahrungen aus der realen Welt zu hören (und eher dazu bereit zu sein), in Bezug auf das, was Sie erfolglos versucht haben (und warum es erfolglos war).
Aaronaught
1
Dies trifft manchmal zu, z. B. " alter Hund, neue Tricks " - versuchen Sie, jemandem zu erklären, wie Techniken die Effizienz beim Abrufen von Daten um 800% gesteigert haben, und der Mitarbeiter zuckt nur mit den Schultern.
IAbstrakter
2
Der Punkt ist, dass Sie dies tun können und die Leute Ihnen folgen, aber Sie müssen in der Hierarchie einen höheren Rang einnehmen. In den meisten Teams ist dies als einfacher Entwickler nicht möglich. Viele Kollegen können sich nur von jemandem beraten lassen, der in der Hierarchie übergeordnet ist. Wenn Sie auf dem gleichen Level sind, fühlen sie sich verletzt und angegriffen. Denken Sie daran, dass Respekt verdient ist. Wenn du sie gut behandelst und sie nett und angenehm kommunizierst, kann es funktionieren, wenn du dich auch auf der gleichen Ebene befindest.
Falcon