Der Gründer antwortete, dass sie überreagieren und dass er aufgrund seines Lebenslaufs und des Vorstellungsgesprächs absolutes Vertrauen in die Fähigkeiten des neuen Leaders hat, was genau der Grund dafür ist, dass er dieser Person überhaupt die Rolle eines Chefentwicklers zugewiesen hat.

Der Chef hat gesprochen. Es handelt sich nicht um eine Regierung oder eine politische Partei. Sie können niemanden hinauswerfen oder einen Aufstand anführen.

Wenn Sie nicht bereit sind, sich damit auseinanderzusetzen, haben Sie wirklich eine Möglichkeit. Man kann sich zusammenschließen und drohen, auszusteigen, wenn nichts passiert.

Ich sage, man kann, sollte aber nicht. Es besteht eine außerordentlich gute Chance, dass das nicht gut ausgeht. Sie versuchen im Grunde, sich vor den Chef zu stellen, der seine Entscheidung getroffen hat, und die Verantwortlichen mögen es nicht, wenn man sie herausfordert.

Ich nehme an, das “Richtige” ist, Ihnen zu sagen, dass Sie Techniken finden müssen, um ihn zu ermutigen, Ihre Denkweise zu erkennen. Aber das werde ich nicht tun. Ich bin ein 30 Jahre älterer Entwickler, und ich kann Ihnen sagen, dass ich mich in meinen grundlegenden Denkweisen weitgehend festgelegt habe. Nein, ich bin kein Spießer wie dieser Typ und ja, ich nehme Vorschläge an. Ich begrüße neue Technologien und so weiter. Dieser Typ hat in vielen Dingen eindeutig Unrecht. Was ich Ihnen jedoch sagen kann, ist, wenn ich mich auf etwas festgelegt habe und überzeugt bin, die richtige Entscheidung zu treffen, stehe ich dazu. Ich nehme Drohungen nicht gut an, und Nötigung oder Manipulation ist noch schlimmer.

Ich will damit sagen, dass er überzeugt ist, er sei “Programmierer Jesus” (was eine traurige, unglückliche Haltung ist), und Sie werden ihn nie ändern, nicht in diesem Stadium seiner Karriere. Er ist überzeugt, dass er Recht hat, und er glaubt, dass seine Erfahrung ihn unterstützt. Leider tut der Chef das auch.

Ehrlich gesagt, ist es wahrscheinlich den Stress von Ihnen und Ihrem Team nicht wert. Ich schlage vor, dass sich jeder von Ihnen auf die Suche nach einer neuen Stelle macht und wieder geht, wenn er eine gefunden hat. Wenn eine Person geht, stellen Sie sicher, dass sie dem Chef sagt, warum sie geht. Irgendwann könnte er es kapieren. Selbst dann ist es keine Garantie.

LÄUFT Im Ernst, ich weiß nicht, warum jemand dabei sein möchte. Fragen Sie sich selbst, ob in dem, was Sie uns erzählt haben, irgendetwas enthalten ist, das dem Produkt nicht schliesslich zum Verhängnis werden könnte. Ich bin sicher, dass Sie das wissen. Ich stelle die grundlegende Intelligenz des Gründers in dieser Angelegenheit in Frage. Entwickler sind normalerweise sehr lausige Projekt-/Programmmanager. Das ist ein separater Kompetenzbereich, und sie müssen sich gegenseitig ausgleichen. Das ist so, als ob man sagen würde: “Wir brauchen keine separaten Tester, das Testen von Entwicklern funktioniert großartig”. Beides sind Rezepte für Katastrophen. Viel Glück. Das meine ich ernst.

Die Beschreibung der Situation durch den OP ist wahrscheinlich einseitig. Das ist in Ordnung.

Ich bin ein alternder Entwickler (~54 yo), der in ein Unternehmen gebracht wurde, um nicht zu regieren, sondern um Erfahrung zu sammeln. (Der IT-Chef sagte tatsächlich “graue Haare”, lol.) Das Entwicklerteam war unterm Strich weit geschickter als jedes Team, mit dem ich zuvor gearbeitet hatte. Sie haben mir viel beigebracht, besonders über Bescheidenheit! Aber wir fanden Orte, an denen ihre technologische Zauberei die Probleme nicht löste, und in einigen Fällen versteckten sie diese Probleme und verschlimmerten sie letztendlich. Hier konnte ich wirklich etwas beitragen.

Ihre Führung klingt stark autokratisch. Es klingt, als hätte er ein Mandat vom Eigentümer erhalten. Der Eigentümer ist mit dem Entwicklungspersonal unzufrieden und hat diesen “hartgesottenen Draufgänger” hinzugezogen, um die Liefergeschwindigkeit zu verbessern.

Sehen Sie sich zunächst Ihre Mitarbeiter an. Haben Sie Schwächlinge - Entwickler, die nicht “die Matrix sehen”? Wenn ja, finden Sie für sie neue Positionen innerhalb des Unternehmens oder geben Sie ihnen eine gute Referenz für einen Arbeitgeber, der ihre einzigartigen Fähigkeiten benötigt.

Er hasst IDEs

Ich kenne einige, die das tun. Es bringt mich dazu, mit den Augen zu rollen, aber letztlich ist mir das egal. Wenn Menschen mit vi produzieren, dann ok. Ich liebe meine IDEs.

Er nimmt kein Refactoring des Codes vor und kümmert sich nicht um den Stil (der in seinem eigenen Code inkonsistent ist)

Rote Flagge im ersten Teil. Ist er ein Copy-Paster? Ich bin auch schuldig, dass ich mich nicht um den Stil kümmere, aber das liegt daran, dass ich meine IDE benutze, um meinen Python-Code sofort PEP8-konform zu machen. Aber er benutzt keine IDE…

Als Randbemerkung: Der Stil wurde zuvor durch einen nächtlichen Build überprüft, der seit der Ankunft des neuen Lead zu scheitern begann.

Er lehnt die Idee eines nächtlichen Builds ab, ebenso wie automatisierte Tests. Seiner Meinung nach “testet jeder professionelle Entwickler seinen Code ohnehin von Hand, so dass es keinen Grund gibt, Zeit mit dem Schreiben automatisierter Tests zu verschwenden”. Auch der nächtliche Build ist seiner Meinung nach Zeitverschwendung.

Dies löst ebenfalls eine rote Flagge aus, aber aus anderen Gründen, als man erwarten würde. Wie oft wurde dem Besitzer vor der Einstellung dieses Mannes gesagt, dass er X nicht machen könne (eine Demo geben, das System benutzen usw.), weil der nächtliche Build fehlgeschlagen sei? Was ist, wenn der Eigentümer feststellt, dass der nächtliche Build das Problem ist? Was würde er dem Lead Ihrer Meinung nach sagen?

Aber ich habe Bedenken bezüglich der Haltung des Lead; automatisierte Tests sind erstaunlich. Wie zuvor versteht der Chef vielleicht nicht den Wert der Tests, aber er weiß sicher, dass Y% der Gehaltsschecks der Entwickler dafür bezahlt werden. Als ich in meiner jetzigen Firma ankam, hatte die “100% Testabdeckungs-Mafia” das Entwicklungspersonal übernommen und die Kosten in die Höhe getrieben. Einen faulen Apfel später schnurrte das Entwicklungsteam wieder…

Er denkt, dass Versionskontrolle meistens nutzlos ist…

Dies ist eine rote Flagge der höchsten Klasse. Er liegt so falsch wie möglich. Er geht unverantwortlich mit dem Geld des Eigentümers um.

Er übertreibt die Bedeutung der Code-Optimierung.

Früher konnte eine Code-Optimierung einen Unterschied machen. Heute sind Maschinen so schnell, dass sie weniger wichtig sind. Stattdessen müssen wir uns jetzt um die Datenbankleistung und den Netzwerkdurchsatz kümmern. Aber seine Gewohnheit der “Code-Optimierung” ist schwer zu durchbrechen, glauben Sie mir. Ich muss mich dazu zwingen, nicht vorzuoptimieren. Zumindest ist sein Verhalten in diesem Fall nicht destruktiv, abgesehen von der Zeit, die er benötigt. (Haben Sie Zahlen für seine “halbe Zeit” oder ist das übertrieben? Wenn Sie Ihren Vorgesetzten kritisieren, darf keine Übertreibung erlaubt werden. Sie müssen pathologisch objektiv sein).

Er schreibt alle SQL von Hand und lehnt die Idee eines ORM ab.

Schuldig im Sinne der Anklage! Ich verstehe die Angst der Menschen vor SQL nicht. Ich verstehe nicht, wie man SQL, das so einfach ist, unter Schichten von ORM vergraben kann, die sich verschleieren. Hier kann ich Ihnen nicht helfen :-D Aber bitte, werfen Sie all Ihr SQL an einen Ort - verteilen Sie nicht alles in Ihrem Code.

und zwei der fünf Entwickler haben SQL noch nie benutzt.

Das ist inakzeptabel. Wir haben das Jahr 2016. Sie müssen sich weiterbilden.

Er lehnt Frameworks und Bibliotheken von Drittanbietern ab, da es viel einfacher ist, Sachen von Grund auf neu zu schreiben.

Er könnte nicht falscher liegen. Ich bezweifle, dass Ihr Unternehmen so besonders ist, dass Ihre Dienstprogramme intern geschrieben werden müssen. Wir hatten ein paar Entwickler, die Tools von Drittanbietern übernommen haben - bis sie etwas auf eine Weise taten, die dem Entwickler nicht gefiel. Es war eine Ausrede, das Tool wegzuwerfen und ihr eigenes zu schreiben. Das erhöht nur die Belastung für die Entwickler und bremst sie weiter aus. Dieser wenig hilfreiche Code ist teuer zu schreiben, zu testen, zu debuggen und zu warten. Wir haben so viel Geld für -null-Nutzen ausgegeben. Diese Entwickler sind jetzt weg.

Er beschloss, alle JavaScript-Bibliotheken und Frameworks außer jQuery aufzugeben, mit der Behauptung, als er vor fünfzehn Jahren mit der Programmierung in JavaScript begann, gab es keine Frameworks, und das Leben war viel einfacher.

Dieser ist nicht so eindeutig. Der Grund dafür, dass das Leben vor 15 Jahren viel einfacher war, ist, dass war die Geschäftsanfrage viel einfacher. Daher rührt das Problem. Das Web wurde als Batchsystem erfunden (ein Formular ausfüllen, abschicken, eine Antwort erhalten, wiederholen), und jetzt versuchen wir, Webanwendungen zu schreiben, die sich wie Desktop-Anwendungen verhalten. Seine Beobachtung ist richtig, die Dinge sind jetzt schwierig. Aber er begreift nicht, warum. Die Komplexität der Tools ist eine Antwort auf eine kompliziertere Geschäftsanfrage. Daher trifft er schlechte Entscheidungen.

Wir verwenden AngularJS und es scheint anständig zu sein. Wie alle leistungsstarken Tools kann es für Gut und Böse eingesetzt werden.

Er glaubt, dass mobile Geräte (einschließlich Tablets) nur ein Hype sind, so dass es keinen Grund gibt, wertvolle Zeit zu verschwenden, um die Kompatibilität der Website mit diesen Geräten sicherzustellen und ein reaktionsfähiges Design zu entwerfen. Bei dem Produkt handelt es sich um eine öffentliche Webanwendung, von der man nicht erwartet, dass sie von mobilen Geräten viel genutzt wird.

Er irrt sich wieder. Sie sind kein Hype. Sie sind hier, um zu bleiben, weil sie nützlich sind. ABER das Unternehmen braucht sie nicht. Entwickeln Sie keine Dinge, die Sie nicht brauchen. Es ist teuer.

Ein reaktionsschnelles Design könnte jedoch sehr interessant für diese App sein,…

Ist es so interessant, dass Sie persönlich für die Entwicklung bezahlen würden? Wenn das eine gute Idee ist, sollten Sie die Idee an den Eigentümer verkaufen können. Ansonsten geben Sie keinen Cent dafür aus.

Er bittet das Team, das Internet (insbesondere StackOverflow) nicht mehr zu benutzen und sich auf ihren Verstand, die Offline-Dokumentation (ich wusste nicht einmal, dass Microsoft immer noch MSDN-CDs verkauft! Das Internet ist dafür hervorragend geeignet. Wenn die Entwickler-Mitarbeiter von Stackoverflow kopieren und einfügen, ohne zu verstehen, wie der Code funktioniert, dann irren sie sich auch. Gibt es Zeit für Schulungen und persönliche Verbesserungen im Entwicklungsplan? Es ist schwer, auf roboterhaftes Kopieren und Einfügen zu verzichten, wenn man ständig unter Druck steht.

Obwohl ich nur begrenzte Informationen habe, gibt es hier viele Probleme. Es klingt so, als hätte der Besitzer den Code, für den er bezahlt, nicht so schnell bekommen, wie er erwartet. Es klingt, als hätte er eine Menge Ausreden über Dinge gehört, die ihn nichts angehen; er konzentriert sich auf das Ergebnis. Wenn ich Recht habe, haben Sie eine selbst zugefügte Wunde, und Sie haben sie mehr als einmal wieder geöffnet. Dieses Lead ist die Lösung des Eigentümers für das Problem, das die Mitarbeiter der Entwicklungsabteilung aufgeworfen haben, und angesichts seiner begrenzten Informationen ist es verständlich.

Ich wette auch, dass Sie ein nicht adipöses Geschäft betreiben und eine schlechte Anforderungsdefinition haben, die sich mit dem Wind ändert. Es gibt keine Isolierschicht zwischen dem Entwicklungspersonal und dem Besitzer. Abgesehen von diesem Lead.

Nun, was können Sie tun?

1) Trainieren Sie den Lead, dass der Einsatz von automatisierten Tests und Code-Management der richtige Weg ist. Es kann einige Zeit dauern, bis man bei ihm Glaubwürdigkeit gewinnt - der Eigentümer hat ihm wahrscheinlich gesagt, dass das Personal defekt ist. Versuchen Sie, ihn daran zu hindern, pauschale Aufträge zu erteilen, wie z.B. “den ganzen nutzlosen Test-Mist zu löschen und den SVN-Server umzuprogrammieren”. Das gibt Ihnen Zeit, Wert zu zeigen.

2) Setzen Sie das Code-Management auf persönlicher Ebene fort. Zumindest dann können Sie sich von Ihren eigenen Fehlern erholen. Sagen Sie ihm nicht, dass Sie das tun, aber lügen Sie ihn auch nicht an.

3) Fahren Sie mit den automatisierten Tests (Unit-Tests, wenn schon nichts anderes) auf persönlicher Ebene fort. Wie zuvor, erwähnen Sie es nicht, verheimlichen Sie es aber auch nicht.

4) Arbeiten Sie mit der Leitung zusammen, um festzustellen, was die tatsächlich wahrgenommenen Probleme sind. Seien Sie aufgeschlossen; ich wette, es gibt echte Probleme mit dem Personal. Arbeiten Sie mit dem Leiter, um die Probleme anzugehen, nicht die Symptome.

5) Besprechen Sie mit dem Leiter verschiedene Entwicklungsthemen, z.B. die Vorteile von Wasserfall und Agilität. Keines von beiden ist perfekt. Stellen Sie ihm Fragen wie: “Unter welchen Umständen würden sich automatisierte Tests lohnen”? Wenn er eine fragwürdige Antwort gibt, fragen Sie ihn, wie erfolgreiche Unternehmen wie Google es geschafft haben, trotz allem erfolgreich zu sein.

Sie sehen also, dass es mir sehr darum geht, den Lead zu engagieren und zu sehen, wo sein Kopf steht. Vertrauen aufbauen. Sich auf Probleme und nicht auf Symptome einigen. Das ist nicht immer einfach, vor allem, wenn man das Gefühl hat, er sei wie Godzilla und zerreißt Ihre Arbeit.

Es besteht die Möglichkeit, dass er keine Kompromisse eingehen kann. Er wird automatisierte Tests zerschlagen. Code-Management ist für unvorsichtige Menschen. My Way or the Highway.

Wenn es jedoch so weit gekommen ist, wird es Zeit für Sie, zu gehen. Die Arbeit in einer werkzeuglosen Werkstatt - und ich meine Software und Software-Engineering-Werkzeuge - trägt nicht zu Ihrem Lebenslauf bei. Sie werden anfangen zu verrotten, so wie der Leiter verrottet ist. In diesem Fall sollten Sie weitermachen.

fünfundzwanzig Jahre in der IT […] ändern seine Einstellung

Das wird nicht funktionieren, tut mir leid.

Ihr wirkliches Problem ist nicht der inkompetente Chefentwickler. Dieses Problem ist unbedeutend im Vergleich zu dem wirklichen Problem, das Sie beschreiben:

Ihr Gründer vertraut einem inkompetenten*Fremden mehr als seinen vorhandenen Mitarbeitern.

Sie müssen herausfinden, wie das Team sein Vertrauen verloren hat und wie Sie es zurückgewinnen können. Dies wäre einfacher gewesen, wenn es schon vor der Einstellung des Fremden geschehen wäre. Jetzt ist das schwer, denn jede gute Arbeit wird dem neuen Teamleiter zugeschrieben, und jede schlechte Arbeit wird Ihnen allen zugeschrieben - also können Sie es nicht durch härtere Arbeit wieder in Ordnung bringen.

Mir fallen nur 2 Dinge ein, um die Situation an diesem Arbeitsplatz zu verbessern:

1. Finden Sie einen Vermittler. Gibt es mehrere Gründer oder so etwas wie Vorstandsmitglieder?

2. Vielleicht ist die Vertrauensfrage eine Frage der Sichtbarkeit. In diesem Fall hilft Ihnen alles, was die Sichtbarkeit fördert. Machen Sie z.B. Sprint-Demos so spannend und interessant, dass der Gründer tatsächlich anwesend ist und sich über den Status und den Fortschritt des Teams informiert.

* Während die meisten Punkte, die vom OP angesprochen werden, den Fremden nicht unbedingt inkompetent machen, macht sein Ansatz zur Versionskontrolle und kontinuierlichen Integration in einem 5-Personen-Team das sicherlich.

Diese Antwort mag ungünstig sein und von manchen als krass empfunden werden, aber…

Die erste rote Flagge ist For a few years, the founder was unhappy about the technical skills of the employees

Haben die Mitarbeiter versucht, das Unglück zu beheben?

Die zweite rote Flagge ist two of the five developers never used SQL before

Es ist schwer, ein effizientes System zu schaffen, wenn die Entwickler nicht mit den Kerntechnologien vertraut sind und nicht wirklich verstehen, was das ORM verdeckt.

• *

Es ist schwer vorstellbar, dass I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a ******. tatsächlich ausgesprochen wurde, aber ich nehme es für bare Münze und glaube Ihnen.

Bedenken Sie jedoch die erste rote Fahne, die ich erwähnt habe, und das “Unglück”, mit dem der Gründer seit Jahren zu kämpfen hat.

Dazu füge ich hinzu: Ihr wisst seit Jahren vom Unglück des Gründers?!

Wie wurde diese Information an Sie weitergegeben?

Ich neige zu der Annahme, dass dieser Typ genau das tut, wofür er angestellt wurde; Sie in Form zu bringen.

Sie in Form zu bringen bedeutet nicht, die schlechten Praktiken des Neuen zu übernehmen, aber es bedeutet, Sie aus Ihrer Komfortzone zu werfen, um auf einer tieferen Ebene zu lernen.

Einige Jahre lang war der Gründer mit den technischen Fähigkeiten der Mitarbeiter unzufrieden und stellte kürzlich einen leitenden Entwickler für die Doppelrolle des technischen Leiters und des Projektmanagers ein. Er war der Einzige, der ein Vorstellungsgespräch führte, und der Einzige, der sich entschied, diese Person einzustellen.

Klingt so, als ob der Gründer Ihnen nicht traut.

Im Laufe von zwei Monaten schätzte das Team sein Profil jedoch sehr viel weniger. Ich hatte die Gelegenheit, mit drei von fünf Mitgliedern dieses Teams zu sprechen, und sie alle hoben drei Punkte hervor:

• Ihrer Meinung nach ist der Kerl ein Idiot und hat keinen Respekt vor den anderen Mitgliedern des Teams. Ein Zitat aus jüngster Zeit, in dem er vor dem Team mit einem Junior-Programmierer sprach, ist sehr anschaulich: “Ich habe fünfundzwanzig Jahre lang in dieser Branche gearbeitet, und Sie? Was haben Sie getan? Sie waren drei Jahre lang ein Code-Affe. Also halten Sie die Klappe, Sie Idiot! Niemand interessiert sich für Ihre Meinung, a*******”

Klingt, als würden Sie nur eine Seite der Geschichte verstehen. Ich kann mir einige Situationen vorstellen, in denen ich selbst einen jungen Besserwisser niederschlagen müsste, und das habe ich getan. Ich spiele hier nur den Anwalt des Teufels, aber es klingt, als wäre er provoziert worden. Was war die Provokation?

• In der Vergangenheit wurden Entscheidungen von allen Teammitgliedern getroffen. Wenn die Mitglieder nicht einverstanden waren, diskutierten sie alles zusammen und kamen zu einer Übereinkunft oder erklärten zumindest denjenigen, die nicht zustimmen wollten, die Gründe dafür.

Offenbar haben die bisherigen Praktiken nicht die Ergebnisse gebracht, die der Gründer wollte.

Jetzt werden alle wichtigen Entscheidungen ausschließlich vom Hauptentwickler getroffen. Diese Entscheidungen können nicht in Frage gestellt oder diskutiert werden, selbst wenn alle fünf Teammitglieder der Meinung sind, dass eine Entscheidung keinen Sinn ergibt.

Auch hier klingt es wie ein Misstrauensvotum des Gründers. Er hat diese Art von Person aus einem bestimmten Grund hinzugezogen.

1. Er hasst IDEs, Autovervollständigung und Funktionen, die Programmierern helfen sollen, Code schneller zu schreiben, und behauptet, dass das Team Notepad++ verwenden sollte, um produktiv zu sein. Auch wenn es unter anderen Umständen sinnvoll ist, ist es schwer vorstellbar, dass C#-Entwickler plötzlich Visual Studio für Notepad++ aufgeben.

IDEs können Sie verlangsamen, wenn Sie ein schneller Programmierer sind. Notepadd ++ ist einigen für schnelle Programmierung überlegen. Die Idee besteht darin, dass Sie Ihren Code schreiben und ihn dann in die IDE zur schnellen Korrektur anstelle von ständigen Unterbrechungen einwerfen.

1. Er refaktorisiert den Code nicht und kümmert sich nicht um den Stil (der in seinem eigenen Code inkonsistent ist), weil “er sich nur um die Dinge kümmert, die wirklich wichtig sind”. Nebenbei bemerkt, der Stil wurde zuvor durch einen nächtlichen Build überprüft, der seit der Ankunft des neuen Leads zu scheitern begann.

Shop-Standards sind etwas, das man mit dem Gründer besprechen sollte, besonders, da Sie es durch den nächtlichen Build laufen lassen. Aber wenn man zwischen den Zeilen liest, sieht es so aus, als ob der Gründer Ihnen nicht vertraut.

1. Er lehnt die Idee eines nächtlichen Builds sowie automatisierte Tests ab. Ihm zufolge “testet jeder professionelle Entwickler seinen Code ohnehin von Hand, so dass es keinen Grund gibt, Zeit mit dem Schreiben automatisierter Tests zu verschwenden”. Der nächtliche Build ist seiner Meinung nach ebenfalls eine Zeitverschwendung.

Er hat Recht, automatisierte Tests erklären nicht das schiere Genie irgendeines Narren, der etwas tut, was nie beabsichtigt war. Ich persönlich habe mehrere Programme, die automatisierte Tests durchlaufen haben, kaputt gemacht.

1. Er denkt, dass Versionskontrolle meistens nutzlos ist und scheint die Verwendung eines solchen missverstanden zu haben. Das führt zu den Situationen, in denen er drei bis fünf Tage lang ein Feature allein entwickelt, und wenn er schließlich seine Änderungen committet, “nimmt er meine” für alle Konflikte. Wenn sich andere Teammitglieder beschweren, dass ihr Code gelöscht wurde, lädt er sie ein, ihn neu zu schreiben. Bei mehreren Gelegenheiten taten andere Mitglieder dasselbe und löschten den Code des Hauptentwicklers. Er sah überrascht aus (es scheint, als wüsste er nicht, wie man svn log oder diffs benutzt), und machte seine Änderungen noch einmal und beschwerte sich, dass “sie auf mysteriöse Weise verloren gingen” und beschuldigte SVN, es vermasselt zu haben.

Hier ist jeder schuld. Macht niemand ein Backup? Wenn er Probleme mit der Versionskontrolle hat, liegt es in der Verantwortung des Teams, als Team zu arbeiten und ihm nicht einfach das Leben schwer zu machen.

1. Er überspitzt die Bedeutung der Code-Optimierung. Sein Ansatz ist richtig, d.h. er lässt einen Profiler laufen, ermittelt einen Engpass und behebt ihn; das Problem ist, dass es keine nicht-funktionalen Anforderungen an die Leistung gibt und keine Elemente, die darauf hindeuten, dass die Benutzer die Anwendung als langsam empfinden könnten (und da sie auf minderwertigen Entwicklungs-VMs gehostet wird, fühlt sich die Anwendung sehr reaktionsschnell an). Er verbringt dagegen praktisch die Hälfte der Zeit mit der Code-Optimierung.

Man kann die Bedeutung der Code-Optimierung gar nicht hoch genug einschätzen. Der Zweck der Code-Optimierung besteht nicht darin, sicherzustellen, dass er richtig läuft heute besteht der Zweck darin, ihn so zu optimieren, dass Sie beheben nicht drei Jahre später irgendein Problem, das mit Code-Optimierung hätte verhindert werden können.

Wenn es Ihnen nur darum geht, dass die Benutzer heute zufrieden sind, werden sie Ihnen morgen an die Tür klopfen.

1. Er schreibt alle SQL von Hand und lehnt die Idee eines ORM ab. Man sollte beachten, dass das aktuelle Produkt auf Microsofts ORM Entity Framework basiert, und zwei der fünf Entwickler noch nie SQL verwendet haben.

Zwei der fünf Entwickler sollten dann gefeuert werden. Wenn Sie sich auf ein ORM verlassen, werden Sie nie in der Lage sein, unter die Haube zu kommen und Dinge manuell zu beheben. Ich beginne zu verstehen, warum er jemanden aus Frustration als “Code-Affen” bezeichnet hat. ORMs sind gut und schön, aber Sie müssen die SQL verstehen, wenn Sie jemals über die Grenzen eines ORM hinausgehen wollen.

1. Er lehnt Frameworks und Bibliotheken von Drittanbietern ab, da es viel einfacher ist, Dinge von Grund auf neu zu schreiben. Er beschloss, alle JavaScript-Bibliotheken und Frameworks außer jQuery aufzugeben, und behauptete, als er vor fünfzehn Jahren mit der Programmierung in JavaScript begann, gab es keine Frameworks, und das Leben war viel einfacher.

Er hat Recht. Frameworks und Bibliotheken von Drittanbietern haben Einschränkungen, und wenn man nicht genug versteht, um selbst einzusteigen und es zu reparieren, versteht man den Code nicht. Ein Argument könnte man so oder so vorbringen. Wenn jedoch niemand im Team ohne die Verwendung der Frameworks programmieren kann, dann haben Sie ein sehr schwaches Team.

1. Er ist der Meinung, dass mobile Geräte (einschließlich Tablets) nur ein Hype sind, so dass es keinen Grund gibt, wertvolle Zeit zu verschwenden, um die Kompatibilität der Website mit diesen Geräten sicherzustellen und ein reaktionsfähiges Design zu entwerfen. Bei dem Produkt handelt es sich um eine öffentliche Webanwendung, von der man nicht erwartet, dass sie häufig von mobilen Geräten genutzt wird. Ein reaktionsschnelles Design könnte jedoch sehr interessant für diese Anwendung sein, da sie sogar auf Desktops sowohl auf 19-Zoll-Monitoren als auch auf großen hochauflösenden Monitoren angezeigt wird.

Nach allem, was Sie gesagt haben, klingt es so, als wäre er in ein sauberes Haus gebracht worden. Wenn mobile Geräte kein Hauptakteur für die Anwendung(en) sind, ist zu viel Zeitverschwendung. Es mag zwar ein “nice to have” auf einem Desktop sein, aber ein “nice to have” ist keine Notwendigkeit für den Rollout.

1. Er bittet das Team, das Internet (insbesondere StackOverflow) nicht mehr zu benutzen und sich auf ihr Gehirn, die Offline-Dokumentation (ich wusste nicht einmal, dass Microsoft noch MSDN-CDs verkauft! Sieht aus, als wolle er wissen, wer seine eigenen Hausaufgaben machen kann und wer geschummelt hat.

Teammitglieder beschwerten sich beim Firmengründer über ihren neuen Vorsprung bei diesen drei Themen. Der Gründer antwortete, dass sie überreagieren und dass er auf der Grundlage seines Lebenslaufs und des Vorstellungsgesprächs absolutes Vertrauen in die Fähigkeiten des neuen Lead hat, was genau der Grund dafür ist, dass er dieser Person überhaupt die Rolle eines Chefentwicklers zugewiesen hat.

Was soll das Team tun, um:

• entweder den Lead aus dem Team oder aus dem Unternehmen zu werfen,

• oder ihn zu zwingen, seine Einstellung gegenüber dem Team zu ändern?

Wie wäre es, mit ihm zu arbeiten und nicht jeden seiner Schritte zu sabotieren?

Ganz ehrlich, es klingt, als wäre er in ein sauberes Haus gebracht worden, angesichts dessen, was Sie gepostet haben, klingt es mehr als gerechtfertigt.

Der Eigentümer ist mit Ihrer Leistung NICHT zufrieden. Es wäre gut, wenn Sie den Rat dieses Burschen befolgen würden, wozu auch immer er gut sein mag. Wir Reliquien haben ein wenig Erfahrung und wir wissen, was Sie aus den Büchern niemals lernen werden. Doch anstatt dies als eine Gelegenheit zu sehen, zu lernen und zu wachsen, hat Ihr Team einen massiven Wutanfall.

Ich weiß also nicht, wie lange sich Ihre Teammitglieder bei Ihrem Chef über den leitenden Entwickler beschwert haben. Aber haben Sie mit ihnen ein gutes Gespräch am runden Tisch geführt? Erklären Sie Ihrem Chef die Probleme, die Sie mit dem Chefentwickler haben, und lassen Sie ihm seine Seite der Geschichte zukommen.

Kündigen sollte der letzte Ausweg sein.

Der Eigentümer muss einen Personalmanager einstellen

Andere Antworten haben dies angedeutet, aber der Elefant im Raum ist, dass der Eigentümer (verständlicherweise) Schwierigkeiten zu haben scheint, Personalfunktionen wie Einstellung, Schulung, Entlassung usw. erfolgreich durchzuführen. Fallbeispiel: Der Eigentümer stellt ein unterdurchschnittlich leistungsstarkes Team ein, erträgt sie jahrelang, stellt dann einen 25-jährigen Veteranen ein, um die Dinge in Ordnung zu bringen, und stellt dann einen Berater ein, wenn der 25-jährige Veteran die Dinge nicht in Ordnung bringen kann. Der Eigentümer scheint nicht zu wissen, wie er die Personalseite des Unternehmens leiten soll. Das ist in Ordnung, es gibt Leute, die damit ihren Lebensunterhalt verdienen, und deshalb haben die meisten Organisationen Personalmanager. Der Eigentümer muss eine Person einstellen. Dies wird dem Eigentümer die Freiheit geben, sich auf die strategische Seite des Unternehmens zu konzentrieren, es ist also eine Win-Win-Situation._

Vielleicht könnte OP bei der Befragung helfen (schließlich scheint der Eigentümer in dieser Hinsicht Hilfe zu brauchen)?

Eine “Falte”, die ich hier noch nicht gesehen habe. Es kommt ziemlich häufig vor, dass Leute mit viel Erfahrung in die Defensive gehen, weil sie bei aktuellen Entwicklungen nicht auf dem Laufenden sind. Mir ging es früher genauso, wenn Leute darüber sprachen, wie schrecklich VB6 in Bezug auf das wunderbare .net war, wenn diese Leute nur Dinge wiederholten, die sie über VB6 gehört hatten und nicht wirklich viel darüber wussten.

Wie Sie sagen, eine Menge Dinge, die der Leiter sagt, sind auf den Punkt gebracht. Aber das bedeutet nicht, dass sie alle zutreffen, wie Sie sagen. Vielleicht kann Herr 25 Jahre seinen Geist öffnen und seine Herangehensweise mit dem Besten des Status quo synthetisieren, aber nicht, wenn er Angst davor hat, weniger als perfekt zu sein, und in der Verleugnung, Angst zu haben. Soweit es mich betrifft, ist das das eigentliche Problem hier. Es mag noch andere Probleme mit den Junioren geben (z.B. Defensive wegen ihres Mangels an Fachkenntnissen), aber das scheint hier das eigentliche Problem zu sein.

Wenn sich alle zusammensetzen und ihre Ängste offen und ehrlich ansprechen, dann sollten sie beginnen, sich in eine positivere Richtung zu bewegen. Ich kann nicht sagen, dass es nach einer hohen Wahrscheinlichkeit klingt, aber es ist das, was getan werden muss.

1. Hat das gesamte Team gemeinsam mit diesem Entwickler gesprochen und versucht, die Vorteile von Dingen wie Versionskontrolle und IDEs zu erklären? Eine freimütige Diskussion en masse kann helfen

2. Ich stimme zu, dass es unprofessionell ist, andere Entwickler zu beleidigen, und dies sollte ihm eindringlich erklärt werden. Fragen Sie ihn, ob er glücklich ist, wenn andere den gleichen Ton anschlagen

3. Fragen Sie ihn, ob er häuslichem Stress ausgesetzt ist oder ob er ein Gesundheitsproblem wie Diabetes hat, das ihn reizbar macht

4. Fragen Sie ihn, ob er froh ist, alt zu werden, und ob er ein mürrischer alter Kauz ist, dessen Geist verkümmert, da er nichts Neues lernt

5. wenn alles andere fehlschlägt, sagen Sie, dass alle seine Fehler dokumentiert werden, um Ihre eigene Haut zu retten, und dass Gespräche mit ihm aufgezeichnet werden können