Umgang mit meinem veralteten Kollegen

Ich bin ein relativ junger Programmierer und arbeite in der IT-Abteilung eines mittelständischen Unternehmens. Ich habe einen Kollegen, und er ist ein wirklich guter Visual Basic 6-Programmierer. Und ich meine wirklich gut. Ehrlich. Er kann in der Zeit, in der ich meine erste Tasse Kaffee holen und meinen Computer booten muss, funktionierende Anwendungen bereitstellen, die nur sehr wenige Fehler enthalten. Er ist einfach so gut.

Wir arbeiten mit einem Team und sein Arbeitsstil ist völlig veraltet. Er glaubt nicht an Versionssoftware (wenn Sie nur sicherstellen, dass Ihr Code korrekt ist, brauchen Sie diesen ganzen Unsinn nicht). Glaubt nicht an die Bereitstellung (ich kann eine funktionierende ausführbare Datei bereitstellen. Wie diese bereitgestellt wird, müssen die Sysadmins herausfinden). Glaubt nicht an Abstraktion. ('Wenn Sie eine Unterroutine erstellen möchten, fahren Sie fort, aber rufen Sie keine Unterroutinen von dieser Unterroutine auf. Auf diese Weise wird es chaotisch, und der Code ist schwer zu befolgen. Auf diese Weise kann jeder jedem Schritt auf dem Weg folgen. 'oder' Ja, sicher, Sie können diese Bibliothek verwenden, um das für Sie zu tun, aber auf diese Weise verstehen Sie nicht wirklich, was los ist ') und glauben sicher nicht an OOP. (wir arbeiten in VB.net)

Er ist so gut in dem, was er tut, dass er Anwendungen viel schneller als ich liefern kann. Aber es funktioniert einfach nicht in einem Team. Unser anderes Teammitglied ist ruhig und spricht nicht gern, obwohl er eher zustimmt. Unser Manager glaubt, dass ich gültige Punkte mache, ist aber kein Programmierer.

Es fällt mir wirklich schwer, die von ihm geschriebenen Programme zu pflegen, und das sorgt nicht für eine gute Teamatmosphäre. Was denkst du, ist das Beste, was ich tun kann?

Das klingt wie einer von denen "Er ist ein guter Kerl, aber ...", bei denen Sie wissen, dass die Wahrheit kommt. Und die Wahrheit klingt, als wäre er kein so guter Ingenieur. Bei guter Software geht es nicht nur um Arbeits- und Entwicklungsgeschwindigkeit. Es geht auch um die anderen Dinge, die Sie erwähnt haben - Wartbarkeit, Kompatibilität, Abstraktion (für zukünftige Effizienz) usw.

Abgesehen davon klingt es so, als hätten Sie ein Problem mit dem Entwickler. Schlimmer für Sie ist, dass er sich bewährt hat und sich wahrscheinlich auf seine Art und Weise verhält. Also was kannst du tun?

• Arbeite um ihn herum.
• Bemühen Sie sich, Ihre Projekte nach einem möglichst engen Zeitplan zu realisieren.
• Und wenn Sie nicht können, erzielen Sie ein besseres Ergebnis.
• Mit der Zeit werden sich die bewährten Konzepte, die er ablehnt, für Sie auszahlen.

Auf der anderen Seite, wenn Sie gezwungen sind, auf seine Weise zu arbeiten, gehen Sie.

Versuchen Sie nicht, Ihren Kollegen zu ändern. Sie beschreiben ihn als jemanden, der funktionierende Software liefern kann. Es ist wahrscheinlich zu spät, um es in das Team zu integrieren.

Sie haben also zwei Möglichkeiten:

• Passen Sie sich an. Vielleicht können Sie ihn mit der Zeit von der Nützlichkeit eines Versionsverwaltungssystems überzeugen? Sie müssen Ihren Einflusskreis vergrößern . Je widerstandsfähiger er gegen Veränderungen ist, desto mehr Zeit wirst du brauchen.

• Entferne dich von der team. Sie haben viele Punkte, um dies zu rechtfertigen. Vielleicht sollten Sie es seine eigenen Anwendungen in Ruhe lassen und sich neuen Dingen widmen.

• Entferne dich von der company. Manchmal ist dies die einzige Lösung.

Wenn ich Sie wäre, würde ich jetzt mein eigenes Versionsverwaltungssystem einrichten. Beginnen Sie, es für alles zu verwenden, was Sie codieren, und verwalten Sie es, damit Ihre anderen Teammitglieder über Konten verfügen und darauf zugreifen können. Ihre anderen Mitarbeiter werden wahrscheinlich begeistert davon sein, es zu verwenden.

Ihr Kollege, der nicht an solche Praktiken glaubt, ist möglicherweise nicht leicht zu überzeugen. Jeder Code, mit dem Sie arbeiten müssen, der von ihm geschrieben wurde, sollte jedoch in die Versionskontrolle aufgenommen werden, damit Sie damit arbeiten können. Wenn er Zugriff auf Ihre Änderungen benötigt, senden Sie ihm eine einfache, schrittweise Anleitung zum Abrufen Ihres Codes aus dem Repository.

Sie müssen nicht kämpferisch sein oder über ihn hinausgehen, um ihn in modernere Prozesse einzubeziehen. Manchmal ist es effektiver, einfach nur seinen eigenen Weg zu gehen und eine Führungspersönlichkeit zu haben, als jemanden mit Worten zu überzeugen. Kleine Schritte. Wenn er schneller auf die Versionskontrolle reagiert, fangen Sie an, Unterprogramme umzugestalten und Komponententests hinzuzufügen, um sich vor den Änderungen zu schützen. Automatisieren Sie die Tests und zeigen Sie ihm, wie er sofort nach dem Einchecken auf die Ergebnisse zugreifen kann.

Oft sind die Leute nur widerstandsfähig, weil sie Veränderungen nicht mögen. Wenn ihnen die Änderungen jedoch schrittweise und so präsentiert werden, dass sie sie leicht nachvollziehen können, werden sie die Vorteile oft sehr schnell bemerken.

Machen Sie ihm vor allem alles so einfach wie möglich (Keep It Simple Stupid). Erlauben Sie ihm, diese Praktiken zu seinen eigenen Bedingungen auszuführen. Aber lass dich nicht runterziehen.

Ich bin ehrlich, Sie malen kein gutes Bild von ihm. Archaische Methoden, schwer zu pflegende Software, hartnäckige neue Arbeitsweisen, gegen Abstraktion etc etc

Wenn er, wie Sie gesagt haben, FASCHER fehlerfreie Software produziert als Sie, ohne wiederverwendbare Bibliotheken und Entwurfsmuster, die auf eine schnelle Anwendungsentwicklung abzielen, sagt er mehr über sich selbst aus als über ihn ...

..über ihn..ja, finde einen Weg, NICHT mit ihm zu arbeiten und NICHT mit seiner Arbeit verbunden zu sein. Scheint, als hätte er eine typische egoistische Einstellung zu seiner Arbeit. Mit so jemandem kann man nicht arbeiten, man kann nur beobachten, wie er arbeitet und aufräumt (so wie Sie es derzeit sind).

Ich habe das schon gesehen ,

Und ich bin fast bereit zu wetten: Dieser Typ erscheint nur "schnell", weil er eine Reihe von erprobten "Mustern" im Kopf hat. 99% der Line of Business-Apps sind CRUD , grundlegende Dinge.

Wahrscheinlich verwendet er eine Tonne Copy & Paste aus seinem eigenen Code (daran ist nichts auszusetzen).

Aber..

In dem Moment, in dem er auf etwas Komplexes stößt, fällt es runter, warum? weil es nicht mehr zu den grundlegenden "Mustern" passt.

Eine kleine Herausforderung ...

Ich würde nebenbei ein Projekt erstellen, ein komplexes, das wirklich von der Wiederverwendung von OOP und Code profitiert.

Zeigen Sie ihm dann das Projekt und bitten Sie ihn, es Feature für Feature zu implementieren.

Ich würde dann wetten, dass sein Code mit ziemlicher Sicherheit 10x größer und 10x hässlicher sein wird, wenn er ihn auf seine Weise implementiert hätte.

Betrachten Sie dies von der geschäftlichen Seite.

Sie nehmen sich mehr Zeit, um fehlerhaften Code zu erstellen. Sie produzieren weniger Einnahmen, deshalb saugen Sie.

Wenn Sie dies im Laufe der Zeit rückgängig machen können, können Sie dies rückgängig machen.

Aber vielleicht, nur vielleicht, kann Ihnen dieser antiquierte Programmierer tatsächlich ein paar Dinge beibringen, wie man Code schnell und so fehlerfrei produziert? Vielleicht sind seine Techniken nicht so altmodisch, wie Sie denken?

Ich vermute, dass jemand so großartigen Code ohne einige sehr gute Praktiken produzieren kann. Möglicherweise können Sie diese Praktiken erlernen und auf die "Best Practices" und trendigen Dinge anwenden, die Sie verstehen.

Wenn Ihr Manager kein Programmierer ist, versuchen Sie es mit Begriffen, die er verstehen wird.

• Wir sollten sourecontrol verwenden, da wir sonst große Probleme haben könnten, uns zu erholen

• Ich brauche x mehr Zeit, weil er sich weigert, ein paar recht einfachen Prozessen zu folgen.

Stellen Sie andererseits sicher, dass Sie nicht zu sehr in Perfektion verfallen, dh dies ist eine bewährte Vorgehensweise, die wir befolgen müssen. Es ist wahrscheinlich, dass Ihr Kollege eine Menge hinzuzufügen hat. Möglicherweise müssen Sie ihn nur langsam in die richtige Richtung schubsen.

Scheint so, als hätten Sie sich noch nie in einem Team entwickelt. Diese Art von Solo-Guru-Partner erlaubt keine gute Gruppendynamik. Erzählen Sie Ihrem Vorgesetzten davon und versuchen Sie, die Vor- und Nachteile mit Ihrem Partner zu besprechen, bevor Sie dies tun. Wenn Sie es besser machen könnten, aber wenn er ablehnt, steigen Sie in das Kommando ein

Sprechen Sie ganz einfach mit Ihrem Manager, wie Sie es hier getan haben. Hier gibt es Potenzial für Wachstum - wenn Ihr Mitarbeiter gut ist, wie Sie sagen, sollte er nicht viel Überzeugungsarbeit leisten, um ihn dazu zu bringen, auf die Verwendung von Quellcodeverwaltung und .Net mit geeigneten OO-Konzepten umzusteigen.

Ich würde mit anderen reden, um ein umfassenderes Bild davon zu bekommen, wie die Dinge aussehen, wo Sie sind. Vielleicht gibt es dort einige Separationen, damit sich sein Code nicht zu sehr mit anderen vermischen muss, da es das Potenzial gibt, ihn auf eine Weise in seinen eigenen Bereich zu trennen, die behandelt werden könnte, obwohl dies eher für ein höheres Level wie ein Regisseur oder CIO zu machen, anstatt ein Entwickler.

Vielleicht möchten Sie mit ihm sprechen, um zu sehen, welche Art von größeren Systemen er gebaut hat, da es einige große Unternehmenssysteme gibt, die in der Regel viele Bausteine ​​enthalten, in denen Spaghetti-Code in das Land von "Oh, das ist der Grund, warum OOP" laufen kann kann gut sein! " Dies ist jedoch manchmal der Fall, wenn es sich als sehr nützlich herausstellt, zu sehen, wie nützlich dies in der eigenen Toolbox sein kann.

Apathie könnte ein weiterer Verdächtiger sein, um zu sehen, ob er aus diesem Grund einige Dinge ablehnt, die ich für grundlegend halte, wenn es darum geht, Code zu entwerfen, aber vielleicht hatte ich zu viel von der Kool-Hilfe.

Fordern Sie ihn (auf eine gute Weise) auf, Ihnen das Gegenteil zu beweisen, und zeigen Sie ihm die kühle Seite der Werkzeuge und Methoden. Nicht bevormunden.

Zum Beispiel glaubt er vielleicht nicht an die Versionierung als Hilfsmittel, sondern zeigt ihm, wie Verzweigungen / Zusammenführungen durchgeführt werden können und wie er an mehreren experimentellen Funktionen arbeiten kann, ohne dass ein Schwall an Dateien erforderlich ist.

Zeigen Sie ihm in Bezug auf OOP einige coole / komplexe Entwurfsmuster, z. B. das Befehlsmuster, das Aufgabenmuster und wie es ihm und Ihrem gesamten Team wertvolle Zeit ersparen kann.

Wenn Sie nicht das geringste Interesse an ihm haben ... ist er vielleicht ein verlorener Fall, aber andererseits haben Sie die Werkzeuge für Ihr Team und Sie, um ihn zu übertreffen. Versuchen Sie, eine Repository-Software zu verwenden, die Commit-Nachrichten für Ihren Manager anzeigt / per E-Mail sendet, die Transparenz für Ihren Manager schaffen und Ihren Mitarbeiter vom Bild abhalten.

Am Ende versuchen Sie nicht, mit Worten zu überzeugen, sondern mit unwiderlegbaren Taten. Das ist der beste Weg, um mit hartnäckigen Menschen umzugehen, IMHO (umgekehrte Psychologie funktioniert manchmal auch, lol).

Nun, die Techniken, die Sie erwähnen, sind offensichtlich gut, aber Sie müssen sich auch fragen, ob Sie sie als Ideologie durchsetzen. Ich finde, dass jüngere Programmierer in Bezug auf das, was sie am College gelernt haben, ein bisschen evangelisch sind. Denken Sie daran, dass diese Techniken aufgrund der Ergebnisse gut sind: Die Versionskontrolle ermöglicht die gleichzeitige Entwicklung und übersichtlichere Nachverfolgung von Design-, Entwicklungs-, Test- und Bugfix-Phasen. Wenn Ihre Projekte wirklich kurzfristig sind, ist vieles davon einfach unangemessen und wird Sie weniger agil machen. Es ist einfach nicht der Fall, dass Best Practice bedeutet, jede bestmögliche Best Practice anzuwenden. Abstraktion zum Beispiel kann definitiv mehr eine Verbindlichkeit als eine Hilfe sein, zumindest manchmal. Versionskontrolle ist am sinnvollsten, wenn Sie längere Entwicklungszeiten, komplexen Code und mehrere Programmierer haben - es gibt eine Art von Synergie, die mit Piecemeal nur schwer zu erreichen ist.

Ich denke, der Ausgangspunkt besteht darin, nach einer möglichen Wiederverwendung Ausschau zu halten - im Laufe der Projekte, nach Gemeinsamkeiten oder allgemeineren Rahmenbedingungen. Der Versuch, sich vor den Projekten zu behaupten, wäre ein kraftvoller Schachzug und könnte Sie in mehr Technik arbeiten lassen ...

Sie sollten Ihren Vorgesetzten bitten, für JEDEN eine Präsentation darüber zu halten, warum "Versionierungs" -Software gut ist. Wählen Sie Ihren Mitarbeiter nicht aus.

Ich bin selbst skeptisch gegenüber Software für die Quellcodeverwaltung, weil ich sehe, dass die Leute sie ständig missbrauchen - als eine Möglichkeit, Arbeit zu vermeiden.

Meine Mitarbeiter verschmelzen STÄNDIG und treten einander ständig auf die Zehen. Aber ein guter, freundlicher Vortrag über seine Vorteile wäre eine schöne Sache und würde Diskussionen anregen.