Wie konvertiere ich einen Copy / Paste / Spaghetti-Programmierer, um das Licht zu sehen?

35

Diese Frage wurde von diesem inspiriert . Obwohl diese andere Frage als lokalisiert angesehen wurde, glaube ich, dass das zugrunde liegende Problem in unserer Branche äußerst verbreitet ist. Ich weiß, dass es einige Entwickler gibt, die dies lesen und denken, ich erfinde das Zeug, und dann antworten sie vielleicht, wie sehr sich jeder um ihre Arbeit kümmert und lernen möchte, aber sie schauen sich nur andere Programmierer-SE-Beiträge an (ein typischer Fall ). Ich weiß, dass das nicht allgemeingültig ist.

Nehmen wir also an, Sie haben jemanden in Ihrem Team (oder vielleicht die Mehrheit), dessen Standardverfahren das Kopieren / Einfügen ist und der glaubt, dass alles gelöst werden kann, wenn Sie nur genügend Funktionsaufrufe und Variablen hinzufügen. Diese Person hat noch nie von TDD, DRY oder SOLID gehört und außerhalb von 40 Stunden bei der Arbeit, wenn sie beschäftigt ist, hat sie noch nie ein einziges Methoden- / Praxis- / Designbuch gelesen.

In der Vergangenheit habe ich (und andere) gefragt, wie Sie OOD unterrichten sollen . Aber jetzt denke ich, dass das nicht die richtige Frage ist. Die eigentliche Frage ist, wie Sie sich einer solchen Person / einem solchen Team nähern und sie neugierig machen, wie sie die Dinge besser angehen können. Wie inspirierst du sie zum Lernen? Ohne das scheint es, als wären alle Unterweisungen, Besprechungen, Vorträge und Diskussionen nutzlos, wenn sie vollkommen glücklich sind, an ihren Schreibtisch zurückzukehren und das zu tun, was sie immer getan haben.

Ich arbeite mit so vielen Leuten. Eigentlich sind sie ziemlich kluge Individuen, aber ich hasse es, wenn ich höre: "Ich bin mit dem Programmieren fertig, muss nur umgestalten und in mehrere Klassen aufteilen, um DXM glücklich zu machen." Sie werden nicht für saubereren, lesbaren und wartbaren Code umgestaltet, sondern nur, weil sie sonst gescholten werden. Ich weiß, dass sie lernfähig sind, es scheint nur, dass es an allgemeiner Motivation mangelt.

Wenn ich Arbeit liefere, hat es im Allgemeinen viel weniger Bugs und die Arbeit, die ich besaß, wurde nie zur Monstrosität einer Klasse mit 5000 Zeilen. Andere machen Kommentare wie "Ihr Code ist viel sauberer und lesbarer als unser Zeug", so dass sie den Unterschied sehen. Aber zur gleichen Zeit habe ich das Gefühl, dass sie glauben, für 40 Stunden bezahlt zu werden, unabhängig davon, was sie tun. Es macht ihnen also nichts aus, wenn sie 3 volle Tage in der Qualitätssicherung verbringen, um nach einem Fehler zu suchen, der nicht hätte eingeschleppt werden dürfen den ersten Platz. Oder dass sie eine Woche brauchen, um eine Klasse zu modifizieren, weil es so viele Abhängigkeiten gibt, die sie am Ende berühren. Die Frage "Vielleicht hätte diese Klasse anders geschrieben werden sollen" scheint jedoch nie zu laut zu werden.

Kann in diesen Situationen etwas unternommen werden? Hat es jemand geschafft? Oder ist es am besten, eine solche Einstellung auf nicht kritische Teile des Projekts zu beschränken und den Schaden zu minimieren?

HINWEIS: Wenn ich "mangelnde Motivation" sage. Ich glaube nicht, dass es an Motivation mangelt, zu arbeiten oder einen guten Job zu machen, weil sie einfach aufgehört haben, sich darum zu kümmern. Der Großteil unseres Teams ist genau das Gegenteil. Sie interessieren sich definitiv für das Produkt. Wir haben Leute, die Nächte und Wochenenden arbeiten werden. Der Teil, den ich versuchen durchzuhalten, ist mit verbesserten Gewohnheiten und Fähigkeiten, sie müssten tatsächlich nicht so viel arbeiten. Ich denke, dass "40 Stunden" dazu geführt haben, dass dieser Beitrag etwas zu negativ klang.

DXM
quelle
Welches Land ist das?
3
@ ThorbjørnRavnAndersen - USA. Jetzt musst du eine Antwort schreiben, da ich sehr gespannt bin, wie sich diese Information darauf ausgewirkt hat :) Ich dachte immer, wir wären alle Menschen und diese Art von Zeug war universell. Und nein, diese Frage hat nichts mit Outsourcing zu tun.
DXM
8
Die kulturellen Unterschiede zwischen den Ländern können erheblich sein, und jeder Versuch, Veränderungen einzuführen, muss dies berücksichtigen. Was in einer Kultur funktioniert, wird höchstwahrscheinlich in einer anderen nicht funktionieren. In Ihrem Fall glaube ich, ist es der beste Weg, das Management die Messlatte für das, was akzeptabel ist, offiziell höher legen zu lassen.

Antworten:

18

Sie fanden den Grund: "Ich weiß, dass sie lernfähig sind, es scheint nur, dass es an allgemeiner Motivation mangelt."

Es gibt Menschen, die ihre Arbeit leidenschaftlich lieben. Und es gibt andere, die manchmal kompetent genug sind und nur für Geld arbeiten . Sie kennen sich aus, aber sie mögen ihre Arbeit nicht. Sie werden keine zusätzliche Zeit für zusätzliche Umgestaltungen aufwenden, um den Code lesbar zu machen oder ein faszinierendes Problem zu lösen, wenn ein schneller und hässlicher Hack die Aufgabe erledigen kann.

Dieses Phänomen gibt es in jedem Job. Es ist nur so, dass manche Jobs nicht besonders aufregend sind (haben Sie schon als Kind einen Buchhalter gesehen, der seinen Job liebt und davon geträumt?), Aber beim Programmieren gibt es viele Leute, die wirklich lieben, was sie tun (ansonsten) Programmierer.SE wird ziemlich leer sein). Dies bedeutet, dass wir als leidenschaftliche Entwickler, die täglich mit anderen leidenschaftlichen Entwicklern sprechen, eher überrascht sein können, wenn wir jemanden sehen, der nur für Geld programmiert.

Was können wir tun? Nicht zu viel. In jedem Fall liegt es nicht an Ihnen, sondern an den Humanressourcen, Menschen auszuwählen, die wirklich motiviert sind¹. Und feuert Leute, die es nicht sind.

Sie können versuchen, Ihre Kollegen selbst zu motivieren, aber es ist äußerst schwierig. Wenn Sie ihnen Bücher zum Lesen geben, geben sie sie einige Wochen später ungeöffnet zurück. Wenn Sie ihnen einen Rat geben, werden sie nicht zuhören, weil sie sich nicht darum kümmern².

Sie können:

  • Überzeugen Sie Ihren Chef, eine Reihe strenger Regeln in Ihrem Unternehmen festzulegen : Stilrichtlinien usw. Dies motiviert die Mitarbeiter nicht, bessere Arbeit zu leisten, aber sie sind zumindest nicht in der Lage, Quellcode zu schreiben, der nicht den Anforderungen entspricht .

  • Arbeiten Sie an den Anforderungen, insbesondere an nicht-funktionalen Anforderungen . Was ist mit einer Anforderung, die besagt, dass ein bestimmtes Projekt weniger als 5 000 Zeilen IL-Code enthalten muss (nein, ich spreche nicht von dem bedeutungslosen LOC ) ³? Was ist mit dem Erfordernis, spezifische Ergebnisse bei zyklomatischer Komplexität oder Klassenkopplung zu erhalten ?

  • Erhöhen Sie die Anzahl der Stunden, die Sie in Ihrem Unternehmen mit Code-Überprüfungen verbringen . Geben Sie an, was überprüft werden soll: Wenn Sie eine Checkliste haben, fügen Sie die Punkte in Bezug auf Umgestaltung, Lesbarkeit, saubere und nützliche Kommentare usw. hinzu. Wenn Sie keine Checkliste haben, müssen Sie dies tun.

  • Verwenden Sie [mehr] Paarprogrammierung . Dies kann dazu beitragen, die Codequalität zu verbessern und weniger motivierte Mitarbeiter zu motivieren.

  • Verwenden Sie das Kompensationssystem ähnlich wie bei Fog Creek.


¹ Darum geht es in Interviews: Bevor Sie eingestellt werden, muss die Personalabteilung nicht nur Ihr technisches Niveau, sondern auch Ihre Motivation fördern . Leider vergessen einige Unternehmen diesen zweiten Teil des Interviews und stellen Leute ein, die nicht besonders gerne programmieren. Glücklicherweise macht die Arbeit in diesen Unternehmen in den meisten Fällen nie Spaß, und der Joel-Test überschreitet selten 2.

² Es ist ihnen wirklich egal, auch wenn sie weniger Geld verdienen. Ich stehe einem meiner Kunden ziemlich nahe (ich bin freiberuflich tätig), der glaubt, dass es seine Aufgabe ist, Websites für seine eigenen Kunden zu entwickeln. Er hat auch einen Designer. Ich habe ihnen oft gesagt, wie sie ihre Produktivität um 2 oder mehr steigern können. Wenn sie nur eine kompetente Person anheuern würden, würden sie ihren Umsatz um mindestens 3 steigern. Aber sie haben genug Geld und kümmern sich nicht um die Qualität oder die Kosten für die ignoranten Kunden, im Vergleich zu jemandem, der produktiv ist.

³ Was ich meine, ist die Anzahl der Zeilen von IL-Code, die Sie in den Codemetriken in Visual Studio sehen , die Metrik, die tatsächlich etwas bedeutet. Der tatsächliche LOC spielt keine Rolle, und Sie müssen ihn nicht messen. Es ist eine der dümmsten Metriken überhaupt. Das Erzwingen von IL-Codezeilen bedeutet, dass Entwickler gezwungen sind, Code tatsächlich umzugestalten und nicht nur zehn Codezeilen in einer einzigen unlesbaren Zeile zu reduzieren.

Arseni Mourzenko
quelle
3
Ich bin anderer Meinung: Motivation zum Arbeiten und Motivation zum Lernen sind zwei völlig getrennte Dinge. Zum Beispiel lieben manche Menschen ihre Arbeit und ihren Job, aber sie denken vielleicht, "SOLID" ist nur ein weiteres Bullshit-Bingo-Schlagwort, oder "TDD" ist ein Elfenbeinturm-Konzept, das in der realen Welt keine Verwendung findet.
Nikie
5
@maple_shaft ist richtig: Manche Leute arbeiten 70 Stunden pro Woche und produzieren die schlechteste Menge an Spaghetti-Code ohne Tests (sie haben keine Zeit für solchen Unsinn!). Zwar sind sie leidenschaftlich und verbessern ihre Fähigkeiten ständig, aber gehen nach 40 Stunden nach Hause, weil sie wissen, dass sie sowieso nicht länger produktiv sein können. Verwechseln Sie die beiden Dinge nicht!
Nikie
13
Nein nein Nein. Bereitschaft, von einem Arbeitgeber ausgenutzt zu werden! = Fähigkeit, Qualitätscode zu erstellen. Es gibt viel zu viel von diesem Unsinn "bis 2 Uhr morgens zu bleiben, um es zu erledigen", der in unserer Branche bereits passiert, ohne dass wir ihn mit irgendeinem mythischen idealen Entwickler in Verbindung bringen. Wenn Sie gerne 80 Stunden pro Woche arbeiten, haben Sie mehr Kraft. Ich habe Dinge, die mir neben der Arbeit wichtig sind. Zu dem Schluss, dass ich schlecht in dem bin, was ich mache, ist bestenfalls falsch. Keine andere Branche kommt mit dem davon, was wir haben, und es liegt an uns, das zu ändern, wenn es sich ändern wird.
Dan Ray
6
Bis 2 Uhr morgens arbeiten zu müssen, um an einem Projekt zu arbeiten, ist eine sehr effiziente Möglichkeit, die Liebe zu diesem Projekt zu töten, insbesondere für diejenigen mit familiären Verpflichtungen.
2
Ich denke, alle hier gemachten Aussagen sind gültig, aber einige von Ihnen haben MainMa möglicherweise falsch verstanden. Er sagte nie Arbeit bis 2 Uhr morgens, weil Sie aufgrund von Fristen gezwungen sind. Stattdessen bezog er sich einfach auf Menschen, die so begeistert sind, etwas zu sehen, dass sie es manchmal lieber tun als schlafen gehen. Das kann ich nachvollziehen. Für mich war ein extremes Beispiel eine Aufgabe, an der ich gearbeitet habe, um unserer Video-Streaming-Bibliothek Tunneling-Unterstützung hinzuzufügen. Es wurde auf 5 Tage geschätzt, aber mit unserer neuen Pipeline-Architektur
passte
12

"Ich bin fertig mit dem Programmieren, muss nur umgestalten und in mehrere Klassen aufteilen, um DXM glücklich zu machen".

Diese Denkweise, dass es in jedem Team Krebs gibt, kann die Motivation des gesamten Teams zerstören, wenn nicht sofort dafür gesorgt wird. Ich beziehe mich natürlich auf die Tatsache, dass Sie aufgrund Ihres Dienstalters und / oder Verdienstes eine Position mit technischer Kompetenz haben, die Ihnen die Möglichkeit gibt, Einfluss auf Ihr Team zu nehmen und bewährte Praktiken in Ihr Team zu bringen.

Das ist alles gut und schön, aber wenn Ihr Team eindeutig über diese Prozesse informiert wäre, würde es Sie nicht in Aussagen wie diesen hervorheben, die eindeutig einen Mangel an Respekt für den Prozess und einen Mangel an Respekt in Ihnen zeigen. Sie sehen diese bewährten Methoden immer noch als Hindernis, das von Ihnen verursacht wurde, und nicht als einen Prozess des Teams , den Ihr Team aus eigener Kraft verteidigen wird.

Sie haben in früheren Kommentaren erwähnt, dass andere Teammitglieder diese Praktiken und Standards tatsächlich gut befolgen und sie korrekt anwenden. Konzentrieren Sie sich zuerst darauf, die Unterstützung durch sie zu stärken, und fragen Sie sie, was funktioniert, was nicht funktioniert, was sie mögen und was sie gerne geändert sehen würden. Wenn Sie dies tun und ihre Meinung ernst nehmen, werden sie die Standards ganz anders beurteilen, als wären sie eine Gemeinschaftsentscheidung anstelle eines Verfahrens, das ihnen von einem Vorgesetzten überlassen wurde.

Sie stärken die Unterstützung für Best Practices und Standards, indem Sie dem Team mitteilen, wie sie den Softwareentwicklungsprozess oder die Qualität der Software verbessert haben.

Halten Sie eine Abstimmung über die Themen zur Diskussion und dokumentieren Sie die Ergebnisse. Idealerweise sollte jede Entscheidung aus Gründen der Legitimität einstimmig sein. Wenn Sie sich jedoch mit Obstrukteuren der harten Linie befassen, kann dies unmöglich sein und jede Frage einfach zum Erliegen bringen. Verwenden Sie in dieser Situation eine Mehrheit. Wenn die Mehrheit gegen Ihre vorgeschlagenen Standards und Praktiken verstößt, haben Sie den Raum bereits verloren, geben Sie ihn einfach an diesem Punkt auf.

Sie werden besitzen diese Standards und Verfahren und erzwingen sie , so dass Sie nicht zu tun haben. Als Technologieführer sollten Sie keine Erlasse und Dekrete erlassen müssen, das ist eine schlechte Art, ein Führer zu sein.

Sobald das Team das Gefühl hat, die Verfahren zu besitzen, sind Mitglieder des Teams, die beginnen, Sie mit bestimmten Verfahren und bewährten Praktiken zu kennzeichnen, nicht mehr berechtigt, dies zu glauben. Ihr Team wird dazu beitragen, diese Einstellung bei anderen zu korrigieren.

maple_shaft
quelle
1
+1 für die Betonung auf die Fokussierung auf Beziehungen statt Prinzipien
Sunwukung
5

Gute Frage! Ich denke, die Antwort hängt davon ab, warum die Leute ihre Fähigkeiten nicht verbessern wollen. Mögliche Antworten sind:

  • Sie denken, dass sie zu beschäftigt sind, um etwas Neues zu lernen, oder sie denken, dass die neue Art, Dinge zu tun (wie all diese Tests zu schreiben), länger dauert und sie haben keine Zeit dafür. Dann wäre die offensichtliche Antwort: Geben Sie ihnen mehr Zeit. Etwas zu lernen oder etwas wie TDD auszuprobieren, wenn Sie die Dinge immer anders gemacht haben, wird die ersten paar Male mehr Zeit in Anspruch nehmen. Wenn Ihre Programmierer diese Zeit nicht haben, können Sie ihnen nicht die Schuld geben, es nicht versucht zu haben.
  • Sie haben eine andere Wahrnehmung ihrer eigenen Fähigkeiten, dh sie denken, dass sie sehr gute Programmierer sind, die hochwertigen Code produzieren. Dies ist ein schwieriges psychologisches Terrain, weil es sehr demotivierend sein kann, diesen Glauben zu zerstören. Vielleicht kann eine Art informeller Wettbewerb helfen (wer produziert die wenigsten Fehler / Merkmale? Der kürzeste Code? Die wenigsten WTFs / Minute in einer Codeüberprüfung?).
  • Möglicherweise liegt ein tatsächliches Motivationsproblem vor (dh sie möchten nur "ihre Zeit auf sich nehmen und in Ruhe lassen", bis die Geschäftszeiten abgelaufen sind). Zum Glück ist das zu allgemein / nicht programmierbezogen, da ich wirklich keine Antwort darauf habe.
  • Sie sind Anfänger und wissen es nicht besser. In diesem Fall können Schulungen, Codeüberprüfungen oder ein "Buchclub" hilfreich sein, in dem ein Teammitglied jeden Monat ein neues technisches Buch besprechen muss.
  • Sie haben schon einmal Silberkugeln gesehen (und waren bitter enttäuscht) und denken, was immer Sie versuchen, sie zu verkaufen, ist nur ein weiteres neues Schlagwort, das theoretisch gut klingt und in der Praxis wenig Sinn macht. In diesem Fall kann es hilfreich sein, die Vorteile bei Codeüberprüfungen und Paarprogrammierungssitzungen zu demonstrieren. Versuchen Sie, dabei kein absoluter Besserwisser zu sein.

Die beste Lösung hängt wirklich vom eigentlichen Problem ab: Zum Beispiel können formale Codierungsrichtlinien, Metriken und Überprüfungen für Anfänger funktionieren, aber Menschen mit der "falschen Wahrnehmung ihrer eigenen Fähigkeiten" können gegen sie kämpfen oder die Metriken spielen, weil sie sie sehen sie als kontraproduktive bürokratische Hindernisse für die Erledigung ihrer Arbeit.

Nikie
quelle
Gute Argumente. Das erste gefällt mir besonders gut - und ich möchte sogar verallgemeinern: Zuerst muss klargestellt werden, dass Lernen am Arbeitsplatz gefördert wird und dass es in Ordnung ist, explizit Zeit dafür vorzusehen.
Sleske
Wenn Menschen ihre Fähigkeiten unterschiedlich wahrnehmen, messen sie den Erfolg vielleicht nur anhand verschiedener Parameter? Wenn Sie die Qualität des Codes messen und darüber nachdenken, wie schnell der Code erstellt werden kann, ist das Ergebnis natürlich unterschiedlich. In solchen Fällen sollten Sie sich fragen, wie sie den Erfolg messen. Unterschiedliche Menschen haben unterschiedliche Denkweisen.
tp1
3

Die eigentliche Frage ist, wie Sie sich einer solchen Person / einem solchen Team nähern und sie neugierig auf eine bessere Vorgehensweise machen? Wie inspirierst du sie zum Lernen? Ohne das scheint es, als wären alle Unterweisungen, Besprechungen, Vorträge und Diskussionen nutzlos, wenn sie vollkommen glücklich sind, an ihren Schreibtisch zurückzukehren und das zu tun, was sie immer getan haben.

Das ist es! Dies ist in der Tat eine echte Frage.

Wir haben einfach keine Zeit, um viel formales Training zu absolvieren - aber gelegentlich, wenn ich es tue, sehe ich immer noch kein Licht Ich bin so oft Zeuge, dass sie ihnen kaum beibringen , wie man denkt.

Die Frage, die ich ihnen stelle, ist nicht, wie man sie unterrichtet - sondern wie man sie zum Lernen bringt? Der Unterschied ist subtil, aber es ist das, was den Unterschied ausmacht.

Ich weiß nicht, ob ich recht habe. aber oft glaube ich im dialog einer matrix an den film - "es ist die frage, die uns antreibt!" Am wichtigsten ist es, sie zum Nachdenken zu bringen und sie zu fragen, warum! Und natürlich sind die meisten, die denken, dass sie bereits alles über einige Designmuster wissen , weil sie gute Noten in Universitätskursen bekommen haben, dort am schwierigsten.

Wie kommst du dazu, ihnen solche Fragen zu stellen? Mein allgemeiner Ansatz ist „ dass sie in dem Teich werfen , wenn Sie wollen , zu schwimmen lernen“ . Ich bin damit einverstanden, dass die Leute nicht einverstanden sind; und ich werde gerne zustimmen, mit ihnen nicht einverstanden zu sein. Wenn Sie sie in den Teich werfen, lernen sie nicht automatisch zu schwimmen. Aber es löst einen Überlebensinstinkt aus, der sie zum Nachdenken anregt - sobald dies geschieht, werden sie natürlich über WIE und WARUM nachdenken.

Ein praktisches Beispiel, das ich den Leuten gebe, ist, sie in ein sehr komplexes Projekt zu stecken, als sie es sich erhofft hatten, und sie ihren eigenen Kampf führen zu lassen. Als sie anfingen, den Code zu entwirren und es schwierig finden, ihn aufzuspüren, merkt man, dass sie anfangen, gute Fragen zu stellen.

Das mag ein bisschen extremistisch klingen, das mag nach Ressourcenverschwendung klingen . Und ich bin sicher, es gibt viele andere, die mir den Rat geben werden, dies nicht zu tun. Aber das hat bei mir geklappt!

Unabhängig davon, welche Zahlungspakete und HR-Tags Sie zuweisen, wird das grundlegende Motivationsproblem nicht gelöst. Denn dieser einzige Weg ist, dass sie herausgefordert werden; Wenn Sie diesen menschlichen Grundgeist auslösen, funktioniert alles andere. Wenn Sie nicht können, ist es ein loses loses Spiel.

PS: Nur nebenbei habe ich hier eine Antwort gepostet: https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - und ich habe alles verprügelt; In erster Linie glauben die meisten Menschen, dass es sich Unternehmen nicht leisten können, Ressourcen zu verschwenden! Ich bin mir sicher, dass diese Antwort hier möglicherweise eine ähnliche Behandlung erfährt. Aber die Wahrheit ist, dass es ein Thema der menschlichen Psychologie ist, Menschen zur Arbeit zu bringen und sie dazu zu bringen, einen guten Job zu machen, um den Lehrplan des Kurses zu erstellen.

Wie auch immer, die Aufgabe, die Sie hier beschreiben, besteht darin, die innere Leidenschaft für große Veränderungen zu entfachen. Und das System wird schwieriger. Fangen Sie mit jüngeren Kollegen an, die immer noch über einen guten Job verfügen, und fordern Sie den Status Quo heraus.

Dipan Mehta
quelle
danke, dass du matrix erzogen hast, jetzt muss ich 2 Stunden meines Lebens damit verbringen, es mir noch einmal anzusehen :) Es ist lustig, aber ich fand, dass "Neulinge" diejenigen sind, die alles absorbieren, was du auf sie wirfst. Ich bin selbst Absolvent eines guten CS-Programms und mache sehr deutlich, was ich von ihrer "Ausbildung" halte, und meistens stimmen sie mir zu. Ich finde, die größten Probleme sind die Leute, die das seit 10, 15, 20 und mehr Jahren machen. Ich stimme auch Ihrem Ansatz der "Feuerprobe" zu. Genau so habe ich gelernt, was ich nicht tun soll. Das Problem ist, a) dass die meisten Teams sich lange Zeit nicht leisten können und b) wenn sie in einem Team arbeiten ...
DXM
.. Einstellung (wage ich zu sagen "semi-agil", hasse mich nicht S.Lott :)), wir haben keine alleinige Eigentümerschaft, die Trial-by-Fire erfordert. Wenn sie etwas schreiben, das fehlschlägt, greift jemand ein und repariert es. Als jemand, der im Teich war und es meistens geschafft hat, war ich neugierig, ob es etwas gibt, das getan werden kann, um diese Denkweise zu übertragen, ohne dass Ihr gesamtes Team durch den Teich geht.
DXM
@DXM Ich bin mit Ihren Bedenken einverstanden, dass besser nicht das gesamte Team auf einmal zum Teich wirft . Ja. Der Punkt ist, einige von ihnen dann eins nach dem anderen zu werfen! Zumindest ist das eine gute Vereinbarung zwischen uns. Ich denke, dass die Einstellung, die seit vielen Jahren gewachsen ist, einige Zeit und Ausdauer in Anspruch nehmen wird, um sich zu ändern.
Dipan Mehta
@DXM, um die Dinge konkreter zu machen - versuchen Sie es mit kleinen Initiativen auf einmal - zeigen Sie die Erfolge und zeigen Sie, dass Management Geschäft bedeutet, um hier gute Arbeit zu leisten. Und fördern Sie die Denkweise - Schritt für Schritt. Ausdauer wäre ein Muss, aber ich hatte so etwas in meiner letzten Firma erreicht. Im Laufe der Zeit gab das Management meinem Team immer wieder ein Beispiel dafür, wie man es gut macht.
Dipan Mehta
1
Ich mag Ihre Antwort, besonders wenn sie für Sie funktioniert. Das Folgende ist also keine Kritik, sondern nur ein Hinweis: Leider funktioniert dies nicht in jedem Fall. Ich hatte mehrere Fälle, in denen nicht motivierte Entwickler große Projekte gestartet haben. Es endete jedes Mal gleich: Das Projekt schlug fehl und sie gaben der Geschäftsleitung oder ihren Kollegen die Schuld oder die Tatsache, dass nicht genügend Zeit oder Ressourcen zur Verfügung standen oder dass die Anforderungen nicht klar genug waren. Ich frage mich, was den Unterschied zwischen denen ausmacht, die schwimmen lernen, und denen, die eher die Schuld am Wasser tragen.
Arseni Mourzenko
2

Wie Sie betonen, ist es die Motivation. Verwechseln Sie sie nicht damit, dass sie sich nicht darum kümmern, dass sie es nicht wissen. Sie wissen genau, was zu tun ist. Sie kümmern sich einfach nicht darum . Wenn dies der Fall ist, lautet die eigentliche Frage: Was macht Ihr Management falsch, was es so unmotiviert lässt? Bist du das neueste Mitglied des Teams? Vielleicht haben sie das alles schon einmal durchgemacht, was nur zu Problemen seitens ihres Managements geführt hat. Sie bleiben also bei der geringsten Menge an Arbeit, die zur Aufrechterhaltung ihres Arbeitsplatzes erforderlich ist, da sie nicht glauben, dass der Arbeitgeber auf mehr Arbeit reagiert.

GroßmeisterB
quelle
Ich bin der Teamleiter und bin seit fast 9 Jahren im Team, habe aber vor ungefähr einem Jahr die Führung übernommen. Ich denke, es gibt einen Unterschied zwischen "kümmere mich nicht um die Arbeit oder die Qualität meines Codes" und "kümmere mich nicht darum, neue Fähigkeiten zu erlernen". Wir haben tatsächlich viele Verbesserungen auf der Managementseite vorgenommen und viele unserer Teamkollegen sind jetzt ziemlich glücklich. Einige sind jedoch ziemlich zufrieden damit, das zu tun, was sie immer getan haben. Sie haben tatsächlich zusätzliche Stunden eingeplant, ohne gefragt zu werden, sind sehr reaktionsschnell, scheinen aber immer noch sehr zufrieden damit, ihre eigenen Fehler in 75% der Fälle zu beheben.
DXM
1
Nun, wie in jedem Beruf wird sich nicht jeder in der oberen Hälfte der Glockenkurve befinden. Es ist möglich, dass Sie nur ein paar Leute für den Gehaltsscheck dabei haben.
GroßmeisterB
Weißt du, jedes Jahr wählen wir ein Team-Zitat aus und 2011 war "es ist was es ist", aber wir stehen kurz vor dem Beginn eines neuen Jahres und zumindest vorerst werde ich es ablehnen zu akzeptieren, dass es das ist, was es ist. obwohl ich Ihnen zustimme, dass es die meiste Zeit wirklich so ist. Ich habe mehr über diese Frage nachgedacht und tatsächlich eine Idee, die Potenzial haben könnte. Da kann ich nicht meine eigene Frage (persönliche Sache, nicht Systembeschränkung) beantworten, wenn 2 weitere Abstimmung Menschen wieder zu öffnen programmers.stackexchange.com/questions/127080/... poste ich werde da drin :)
DXM
2

Es scheint mir, dass dies ein Management- und Führungsproblem ist - wenn es Ihr Team ist, können Sie daran arbeiten, die Verbesserung (persönlich und des Codes) zu einem Kernattribut Ihres Teams zu machen. Die Frage ist, ob dies von Ihrem Management unterstützt wird Sie werden Dinge tun wollen, die Zeit brauchen (sie werden einen Nettogewinn erzielen, da Sie neue technische Schulden abbauen und bestehende technische Schulden zurückzahlen sollten).

Wenn Sie also behaupten, dass Sie möchten, dass sich das Team verbessert, stimmen Sie zu, dass dies eine gute Sache ist (dass das Team als Ganzes daran arbeitet, die Qualität seines Codes zu verbessern), und starten Sie dann ein Programm, um dies zu erreichen passieren - es klingt so einfach ... mir ist bewusst, dass es nicht ist!

Ich denke, dass es zwei Teile gibt - Ausbildung und Arbeitspraktiken.

  • Bildung Sie können eine Mittagspause pro Woche beginnen - alle essen zusammen, Sie halten eine 20-30 minütige Präsentation mit Fragen und Antworten. Sie beginnen mit den Grundlagen, die Sie möchten - SOLID kann die ersten 2 bis 4 Wochen in Anspruch nehmen - und im Laufe der Zeit können Sie das Team dazu bringen, abwechselnd zu sprechen, und Sie können herausfinden, wer über was zwischen Ihnen spricht. Gewähren Sie den Sprechern eine gewisse Vorbereitungszeit bei der Arbeit. Darüber hinaus die Teilnahme lokaler Nutzergruppen fördern (wenn möglich zumindest teilweise sozial gestalten)
  • Arbeitspraktiken ... nun ja, es hängt davon ab, was Sie jetzt tun und welche Werkzeuge Sie haben, aber Sie sollten vielleicht nach vereinbarten Codierungsstandards suchen, eine Überprüfung des Peer-Codes einführen (ist solide), Unit-Tests durchführen (nicht unbedingt zuerst testen) , Ausführen eines Continuous Integration Servers und Betrachten von automatisierteren Tests (zusätzlich zu Komponententests). Diese müssen jedoch im Wesentlichen mit Zustimmung / Zustimmung eingeführt werden (nicht der Build / CI-Server!) Und Sie müssen die Qualität als Team vorantreiben wollen. Es gibt immer Dinge, die man verbessern kann (Kaizen)

Es lohnt sich auch, sich Kanban anzuschauen (das als Treiber für Veränderung / Verbesserung angesehen wird).

Ein letzter Gedanke: Ich bin ein Berufsprogrammierer, und ich möchte, dass mein Team das gleiche ist, aber mehr als 40 Stunden pro Woche zu arbeiten, ist eigentlich keine gute Sache. Deshalb sollte es das Ziel sein, ein Team zu haben, das seine Arbeit erledigt effektiv und gut innerhalb der normalen Arbeitswoche und in Bezug auf diesem Argument für die Arbeit der Praxis zu verbessern , ist , dass es wahrscheinlicher ist zB: Unit - Tests Hinzufügen von dem fehlerhaften Fall zu demonstrieren , wenn (vor) Bug-Fixing Ihnen das Vertrauen zu , dass es istFest; Ein Build-Server gibt Ihnen das Vertrauen, dass Sie Ihre Lösungen sauber erstellen können. Wenn durch diesen Build auch Bereitstellungspakete generiert werden, bedeutet dies, dass die Bereitstellung erheblich vereinfacht wird. SOLID-Code ist per Definition einfacher zu ändern. und auf ganzer Linie, je weniger technische Schulden Sie haben, desto weniger müssen Sie zurückzahlen ...

Murph
quelle
0

Ich bin vor ungefähr 30 Jahren durch Zufall in das Programmieren geraten. Ich war motiviert, grundlegende Prinzipien der Softwareentwicklung zu erlernen, indem ich beauftragt wurde, den Code anderer zu pflegen / zu unterstützen. In diesen Aufgaben habe ich gelernt, wie ein Codeleser Code erfährt - wie man sich in den Codeleser hineinversetzt. Ich wollte nicht den Schmerz meines schlecht geschriebenen Codes anderen zufügen!

Diese Praxis, neue Programmierer zu beauftragen, den Code anderer Leute zu pflegen / zu unterstützen, ist kein Wundermittel, und sie scheint die Motivation zu bieten, öfter zu lernen, wie man soliden Code erzeugt, als nicht.

David Pointer
quelle
1
Ich habe den gleichen Weg eingeschlagen, allerdings nicht aus Versehen. Dies ist sehr ähnlich zu dem, was Dipan Mehta in seinem Beitrag gesagt hat. Sie werfen eine Person in einen Teich, stellen sicher, dass er nicht zu tief ist, und lassen sie schwimmen. Du warst einer von denen, die schwimmen gelernt haben, aber das ist nicht universell (siehe seine Antwort mit Kommentaren). Ich glaube auch, dass diese Art der Herangehensweise für neue Menschen besser funktioniert als für diejenigen, die bereits tief verwurzelte Gewohnheiten haben. Dann müssen sie nicht nur schwimmen, sondern es ist auch gegen die gängigen Praktiken.
DXM