Der Gründer antwortete, dass sie überreagieren und dass er aufgrund seines Lebenslaufs und des Interviews absolutes Vertrauen in die Fähigkeiten des neuen Leads habe, weshalb er dieser Person überhaupt erst die Rolle eines Lead Developers zugewiesen habe .

Der Schulleiter hat gesprochen. Es ist weder eine Regierung noch 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 Option. Sie können sich zusammenschließen und damit drohen, aufzuhören, wenn nichts passiert.

Ich sage kann, nicht sollte. Es besteht eine außerordentlich gute Chance, dass dies nicht gut enden wird. Sie versuchen im Grunde, sich vor dem Chef zu positionieren, der seine Entscheidung getroffen hat, und die Verantwortlichen mögen es nicht, wenn sie herausgefordert werden.

Ich nehme an, das "Richtige", was Sie Ihnen sagen sollten, ist, Techniken zu finden, die ihn ermutigen, Ihre Denkweise zu erkennen. Aber das werde ich nicht tun. Ich bin ein 30-jähriger Senior-Entwickler und ich kann Ihnen sagen, dass ich mich in meinen grundlegenden Dingen weitgehend festgelegt habe. Nein, ich bin kein Maschinenstürmer wie dieser Typ und ja, ich nehme Vorschläge an. Ich nehme neue Technologien an und so weiter. Dieser Typ liegt in vielen Dingen eindeutig falsch. Was ich Ihnen jedoch sagen kann, ist, wenn ich mir etwas vorgenommen habe und davon überzeugt bin, dass ich die richtige Entscheidung treffe, dann stehe ich dazu. Ich vertrage Drohungen nicht gut und Nötigung oder Manipulation sind noch schlimmer.

Mein Punkt ist, dass er davon überzeugt ist, dass er "Programmierer Jesus" ist (was eine traurige, unglückliche Einstellung ist) und Sie ihn niemals ändern werden, nicht in diesem Stadium seiner Karriere. Er ist überzeugt, dass er Recht hat, und er glaubt, dass seine Erfahrung ihn bestätigt. Der Chef leider auch.

Ehrlich gesagt ist es den Stress für Sie und Ihr Team wahrscheinlich nicht wert. Ich würde jedem von Ihnen vorschlagen, sich nach einem neuen Job umzusehen und zu gehen, wenn Sie einen gefunden haben. Wenn eine Person geht, stellen Sie sicher, dass sie dem Chef sagt, warum. Irgendwann bekommt er vielleicht das Bild. Selbst dann ist es keine Garantie.

RUN Ernsthaft, ich weiß nicht, warum irgendjemand dort sein möchte. Fragen Sie sich, gibt es irgendetwas in dem, was Sie uns erzählt haben, das nicht den endgültigen Untergang für das Produkt bedeutet? Ich bin sicher, Sie kennen das. Ich bezweifle in dieser Hinsicht die grundlegende Intelligenz des Gründers. Entwickler sind normalerweise sehr lausige Projekt-/Programmmanager. Es ist ein separates Skill-Set und sie müssen sich gegenseitig ausgleichen. Es ist, als würde man sagen: „Wir brauchen keine separaten Tester, Entwicklertests funktionieren hervorragend.“ Beides sind Rezepte für eine Katastrophe. Viel Glück. Ich meine, dass.

Die Beschreibung der Situation durch das OP ist wahrscheinlich einseitig. Das ist okay.

Ich bin ein alternder Entwickler (~54 Jahre), der in ein Unternehmen gebracht wurde, um nicht zu regieren, sondern um etwas Erfahrung zu bieten. (Der IT-Chef sagte tatsächlich „graue Haare“, lol.) Das Entwicklerteam war alles in allem viel versierter als jedes andere Team, mit dem ich zuvor zusammengearbeitet hatte. Sie haben mir viel beigebracht, besonders über Demut! Aber wir fanden Orte, an denen ihre technologische Zauberei die Probleme nicht löste und in einigen Fällen diese Probleme verbarg, was sie letztendlich verschlimmerte. Hier konnte ich mich wirklich einbringen.

Ihre Führung klingt stark autokratisch. Es hört sich so an, als hätte ihm der Eigentümer ein Mandat erteilt. Der Eigentümer ist unzufrieden mit dem Entwicklerteam und hat diesen „hartgesottenen, sachlichen Macher“ hinzugezogen, um die Liefergeschwindigkeit zu verbessern.

Schauen Sie sich zuerst Ihre Mitarbeiter an. Haben Sie Schwächlinge – Entwickler, die „die Matrix nicht sehen“? Wenn ja, finden Sie neue Stellen 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 lässt mich mit den Augen rollen, aber letztendlich ist es mir egal. Wenn Leute mit produzieren vi, dann ok. Ich liebe meine IDEs.

Er überarbeitet den Code nicht und kümmert sich nicht um den Stil (der in seinem eigenen Code inkonsistent ist).

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

Als Randnotiz wurde der Stil zuvor durch einen nächtlichen Build überprüft, der seit der Ankunft des neuen Leads zu scheitern begann.

Er lehnt die Idee eines nächtlichen Builds ebenso ab wie automatisierte Tests. Ihm zufolge „testet jeder professionelle Entwickler seinen Code sowieso von Hand, es gibt also keinen Grund, Zeit mit dem Schreiben automatisierter Tests zu verschwenden“. Auch der nächtliche Aufbau ist seiner Meinung nach Zeitverschwendung.

Dies löst auch eine rote Fahne aus, aber aus anderen Gründen, als Sie vielleicht erwarten. Bevor dieser Typ eingestellt wurde, wie oft wurde dem Eigentümer gesagt, dass er X (eine Demo geben, das System verwenden usw.) nicht machen könne, weil der nächtliche Build fehlgeschlagen sei? Was ist, wenn der Besitzer wahrnimmt, dass der nächtliche Aufbau das Problem ist? Was glaubst du, was er dem Lead sagen würde?

Aber ich habe Bedenken wegen der Haltung des Leads; automatisierte Tests sind erstaunlich. Nach wie vor versteht der Chef vielleicht nicht den Wert der Tests, aber er weiß sicherlich, dass Y% der Gehaltsschecks der Entwickler dafür bezahlt werden. Als ich in meiner jetzigen Firma ankam, hatte die "100% Test Coverage Mafia" das Entwicklerteam übernommen und die Kosten wahnsinnig in die Höhe getrieben. Einen faulen Apfel später schnurrte das Entwicklerteam wieder.

Er denkt, dass die Versionskontrolle meistens nutzlos ist ...

Dies ist eine rote Fahne der höchsten Ordnung. Er liegt so falsch wie möglich. Er geht verantwortungslos mit dem Geld des Besitzers um.

Er übertreibt die Bedeutung der Code-Optimierung.

Früher konnte die Code-Optimierung einen Unterschied machen. Jetzt sind Maschinen so schnell, dass es weniger wichtig ist. Stattdessen müssen wir uns jetzt um die Datenbankleistung und den Netzwerkdurchsatz kümmern. Aber seine „Code-Optimierungs“-Gewohnheit ist schwer zu brechen, glauben Sie mir. Ich muss mich nicht voroptimieren. Zumindest ist sein Verhalten in diesem Fall nicht destruktiv, abgesehen von der Zeit, die es braucht. (Haben Sie Zahlen für seine „halbe Zeit“ oder ist das eine Übertreibung? Wenn Sie Ihren Vorgesetzten kritisieren, ist keine Übertreibung erlaubt. Sie müssen pathologisch objektiv sein.)

Er schreibt sämtliches SQL von Hand und lehnt die Idee eines ORM ab.

Schuldig im Sinne der Anklage! Ich verstehe die Angst der Leute vor SQL nicht. Ich verstehe es nicht, SQL, das absolut einfach ist, unter Schichten von ORM zu begraben, die verschleiern. Kann dir hier nicht helfen :-D Aber bitte lade all dein SQL an einem Ort ab - verteile nicht alles in deinem Code.

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

Das ist nicht akzeptabel. Wir schreiben das Jahr 2016. Sie müssen sich weiterbilden.

Er lehnt Frameworks und Bibliotheken von Drittanbietern ab, da es viel einfacher ist, Dinge 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 sich Tools von Drittanbietern zu eigen machten – bis sie etwas taten, das dem Entwickler nicht gefiel. Es war ein Vorwand, das Tool wegzuschmeißen und ein eigenes zu schreiben. Dies trägt nur zur Belastung des Entwicklerteams bei und verlangsamt es weiter. 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, und behauptete, 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 ist, dass das Leben vor 15 Jahren viel einfacher war, weil das Geschäft viel einfacher war. Von daher ist das Problem gekommen. Das Web wurde als Batch-System erfunden (Formular ausfüllen, absenden, Antwort erhalten, wiederholen) und jetzt versuchen wir, Web-Apps zu schreiben, die sich wie Desktop-Apps verhalten. Seine Beobachtung ist richtig, die Dinge sind jetzt hart. Aber er erkennt nicht warum. Die Toolkomplexität ist eine Antwort auf eine kompliziertere Geschäftsfrage. Daher trifft er schlechte Entscheidungen.

Wir verwenden AngularJS und es scheint anständig zu sein. Wie alle mächtigen Werkzeuge kann es zum Guten oder Bösen eingesetzt werden.

Er ist der Meinung, dass mobile Geräte (einschließlich Tablets) nur ein Hype sind, daher gibt es keinen Grund, wertvolle Zeit zu verschwenden, um die Kompatibilität der Website mit diesen Geräten sicherzustellen und ein ansprechendes Design zu erstellen. Das Produkt ist eine öffentliche Webanwendung, von der nicht erwartet wird, dass sie häufig von mobilen Geräten verwendet wird.

Er liegt wieder falsch. Sie sind kein Hype. Sie sind hier, um zu bleiben, weil sie nützlich sind. ABER das Geschäft braucht es nicht. Entwickeln Sie nichts, was Sie nicht brauchen. Es ist teuer.

Responsive Design könnte für diese App jedoch sehr interessant sein, ...

Ist es so interessant, dass Sie persönlich für die Entwicklung bezahlen würden? Wenn dies eine gute Idee ist, sollten Sie in der Lage sein, die Idee an den Eigentümer zu verkaufen. Ansonsten keinen Cent dafür ausgeben.

Er bittet das Team, das Internet (insbesondere StackOverflow) nicht mehr zu nutzen und sich auf ihr Gehirn, die Offline-Dokumentation (ich wusste nicht einmal, dass Microsoft immer noch MSDN-CDs verkauft!) und die Bücher zu verlassen.

Er hat Unrecht. Dafür eignet sich das Internet hervorragend. Wenn die Entwickler von Stackoverflow kopieren und einfügen, ohne zu verstehen, wie der Code funktioniert, liegen sie ebenfalls falsch. Ist im Entwicklungsplan Zeit für Weiterbildung und persönliche Weiterentwicklung? Es ist schwer, nicht roboterhaft zu kopieren und einzufügen, wenn Sie immer unter Druck stehen.

Obwohl ich nur begrenzte Informationen habe, gibt es hier viele Probleme. Es hört sich so an, als hätte der Besitzer den Code, für den er bezahlt, nicht so schnell erhalten, wie er erwartet. Es hört sich so an, als hätte er viele Ausreden über Dinge gehört, die ihm egal sind; Er konzentriert sich auf das Ergebnis. Wenn ich richtig liege, haben Sie eine selbst zugefügte Wunde und Sie haben sie mehr als einmal wieder geöffnet. Dieser Hinweis ist die Lösung des Eigentümers für das Problem, das die Entwicklermitarbeiter aufgeworfen haben, und angesichts seiner begrenzten Informationen ist es verständlich.

Ich wette auch, dass Sie einen nicht agilen Shop betreiben und eine schlechte Anforderungsdefinition haben, die sich ändert, wenn der Wind weht. Es gibt keine Isolationsschicht zwischen dem Entwicklerteam und dem Besitzer. Bis auf diesen Lead.

Nun, was können Sie tun?

1) Schulen Sie den Lead, dass die Verwendung von automatisiertem Testen und Code-Management der richtige Weg ist. Es kann einige Zeit dauern, um bei ihm Glaubwürdigkeit zu erlangen - der Besitzer hat ihm wahrscheinlich gesagt, dass das Personal defekt ist. Sehen Sie, ob Sie ihn daran hindern können, umfassende Anweisungen zu erteilen, wie z. Dies gibt Ihnen Zeit, Wert zu zeigen.

2) Verwenden Sie die Codeverwaltung weiterhin auf persönlicher Ebene. Dann kann man sich wenigstens von seinen eigenen Fehlern erholen. Sagen Sie ihm nicht, dass Sie das tun, aber lügen Sie ihn auch nicht an.

3) Fahren Sie mit automatisierten Tests (allenfalls Unit-Tests) auf persönlicher Ebene fort. Wie zuvor, erwähnen Sie es nicht, aber verstecken Sie es nicht.

4) Arbeiten Sie mit dem Lead 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 der Elektrode, um die Probleme anzugehen, nicht die Symptome.

5) Besprechen Sie mit dem Lead verschiedene Entwicklungsthemen, wie z. B. die Vorteile von Wasserfall und Agilität. Beides ist nicht perfekt. Stellen Sie ihm Fragen wie „Unter welchen Umständen würde sich automatisiertes Testen lohnen“? Wenn er eine zweifelhafte Antwort gibt, fragen Sie ihn, wie erfolgreiche Unternehmen wie Google es trotzdem geschafft haben, erfolgreich zu sein.

Sie können also sehen, dass es mir nur darum geht, den Lead zu engagieren und zu sehen, wo sich sein Kopf befindet. Vertrauen aufbauen. Einigen Sie sich auf Probleme versus Symptome. Das ist nicht immer einfach, besonders wenn Sie das Gefühl haben, er ist wie Godzilla und zerreißt Ihre Arbeit.

Es besteht die Möglichkeit, dass er keine Kompromisse eingehen kann. Er wird automatisiertes Testen vernichten. Code-Management ist etwas für sorglose Menschen. Mein Weg oder die Autobahn.

Wenn es jedoch an diesem Punkt angelangt ist, wird es für Sie Zeit zu gehen. In einem werkzeuglosen Geschäft zu arbeiten, und ich meine Software und Software-Engineering-Tools, baut Ihren Lebenslauf nicht auf. Sie werden anfangen zu verrotten, genauso wie das Blei verrottet ist. Fahren Sie in diesem Fall fort.

25 Jahre in der IT [...] ändern seine Einstellung

Wird nicht funktionieren, tut mir leid.

Ihr eigentliches Problem ist nicht der inkompetente Hauptentwickler. Dieses Problem ist im Vergleich zu dem von Ihnen beschriebenen eigentlichen Problem unbedeutend:

Ihr Gründer vertraut einem inkompetenten* Fremden mehr als seinen bestehenden 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 dies vor der Einstellung des Fremden geschehen wäre. Nun, das ist schwierig, denn jede gute Arbeit wird dem neuen Teamleiter zugeschrieben, und jede schlechte Arbeit wird Ihnen allen zugeschrieben – Sie können sie also nicht beheben, indem Sie härter arbeiten.

Mir fallen nur 2 Dinge ein, um die Situation bei diesem Job zu verbessern:

1. Finden Sie einen Vermittler. Gibt es mehrere Gründer oder so etwas wie Vorstandsmitglieder?
2. Vielleicht ist das Vertrauensproblem ein Sichtbarkeitsproblem. In diesem Fall hilft Ihnen alles, was zur Sichtbarkeit beiträgt. Gestalten Sie beispielsweise Sprint-Demos spannend und interessant genug, dass der Gründer tatsächlich daran teilnimmt und etwas über den Status und Fortschritt des Teams erfährt.

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

Diese Antwort mag ungünstig sein und von manchen als krass angesehen werden, aber ...

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

Haben die Mitarbeiter versucht, die Unzufriedenheit zu beheben?

Die zweite rote Fahne isttwo of the five developers never used SQL before

Es ist schwierig, ein effizientes System zu erstellen, wenn die Entwickler nicht mit Kerntechnologien vertraut sind und wirklich verstehen, was das ORM maskiert.

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******.das tatsächlich ausgesprochen wurde, aber ich werde es für bare Münze nehmen und Ihnen glauben.

Bedenken Sie jedoch die erste von mir erwähnte rote Flagge und das "Unglück", mit dem der Gründer seit Jahren zu kämpfen hat.

Dazu füge ich hinzu: Ihr wisst seit Jahren von der Unzufriedenheit des Gründers?!

Wie wurden Ihnen diese Informationen mitgeteilt?

Ich neige zu der Annahme, dass dieser Typ genau das tut, wofür er eingestellt wurde; bringt euch in Form.

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

Der Gründer war einige Jahre unzufrieden mit den technischen Fähigkeiten der Mitarbeiter und stellte kürzlich einen Senior-Entwickler für die Doppelrolle als technischer Leiter und Projektleiter ein. Er war der einzige, der ein Vorstellungsgespräch führte, und der einzige, der sich entschied, diese Person einzustellen.

Klingt, als würde der Gründer euch Jungs nicht trauen.

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

• Laut ihnen ist der Typ ein Idiot und hat keinen Respekt gegenüber den anderen Mitgliedern des Teams. Ein aktuelles Zitat von ihm im Gespräch mit einem Junior-Programmierer vor dem Team ist sehr anschaulich: „Ich habe fünfundzwanzig Jahre in dieser Branche gearbeitet, und Sie? Was hast du getan? Du bist seit drei Jahren ein Code Monkey. Also halt die Klappe, du Idiot! Niemand interessiert sich für deine Meinung, verdammt.“

Klingt, als würdest du nur eine Seite der Geschichte verstehen. Ich kann mir ein paar Situationen vorstellen, in denen ich vielleicht selbst einen jungen Besserwisser schlagen muss, und das habe ich getan. Ich spiele hier nur den Advokaten des Teufels, aber es klingt, als wäre er provoziert worden. Was war die Provokation?

• Früher wurden Entscheidungen von allen Teammitgliedern getroffen. Wenn die Mitglieder nicht zustimmen würden, würden sie alles zusammen diskutieren und zu einer Einigung kommen oder zumindest die Argumentation denen erklären, die nicht zustimmen würden.

Offenbar brachten frühere Praktiken nicht die Ergebnisse, die der Gründer wollte.

Jetzt werden alle wichtigen Entscheidungen ausschließlich vom leitenden Entwickler getroffen. Diese Entscheidungen können nicht hinterfragt oder diskutiert werden, selbst wenn alle fünf Teammitglieder der Meinung sind, dass eine Entscheidung keinen Sinn macht.

Auch hier klingt es nach einem Misstrauensvotum des Gründers. Er hat diese Art von Person aus einem bestimmten Grund hereingebracht. Klingt so, als ob der Grund darin bestand, den Rest des Personals in Form zu bringen.

1. Er hasst IDEs, automatische Vervollständigung und Funktionen, die Programmierern helfen sollen, Code schneller zu schreiben, und behauptet, dass das Team Notepad++ verwenden sollte, um produktiv zu sein. Während es unter verschiedenen 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 schnelles Codieren überlegen. Die Idee ist, dass Sie Ihren Code schreiben und ihn dann zur schnellen Korrektur in der IDE ablegen, anstatt ständige Unterbrechungen zu verursachen.

2. Er überarbeitet den Code nicht und kümmert sich nicht um den Stil (der in seinem eigenen Code inkonsistent ist), der Grund dafür ist, dass „er sich nur um Dinge kümmert, die wirklich wichtig sind“. Als Randnotiz wurde der Stil 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 man es durch den nächtlichen Build laufen lässt. Aber noch einmal, wenn man zwischen den Zeilen liest, sieht es so aus, als würde der Gründer Ihnen nicht vertrauen.

3. Er lehnt die Idee eines nächtlichen Builds ebenso ab wie automatisierte Tests. Ihm zufolge „testet jeder professionelle Entwickler seinen Code sowieso von Hand, es gibt also keinen Grund, Zeit mit dem Schreiben automatisierter Tests zu verschwenden“. Auch der nächtliche Aufbau ist seiner Meinung nach Zeitverschwendung.

Er hat Recht, automatisierte Tests erklären nicht das schiere Genie eines Dummkopfs, der etwas nie beabsichtigtes tut. Ich persönlich habe mehrere Programme beschädigt, die automatisierte Tests durchlaufen haben.

4. Er denkt, dass die Versionskontrolle größtenteils nutzlos ist, und scheint falsch zu verstehen, wie man eine verwendet. Das führt zu Situationen, in denen er ein Feature drei bis fünf Tage lang alleine entwickelt, und wenn er schließlich seine Änderungen festschreibt, „nimmt er meine“ für alle Konflikte. Wenn sich andere Teammitglieder darüber beschweren, dass ihr Code gelöscht wurde, fordert er sie auf, ihn neu zu schreiben. Bei mehreren Gelegenheiten taten andere Mitglieder dasselbe und löschten den Code des Hauptentwicklers. Er sah überrascht aus (es scheint, dass er nicht weiß, wie man svn log oder diffs benutzt) und nahm seine Änderungen erneut vor, beschwerte sich, dass „sie auf mysteriöse Weise verloren gingen“ und beschuldigte SVN, Fehler gemacht zu haben.

Hier sind alle schuld. Sichert niemand? Wenn er Probleme mit der Versionskontrolle hat, liegt es in der Verantwortung des Teams, als Team zu arbeiten und ihm nicht nur das Leben schwer zu machen.

5. Er übertreibt die Bedeutung der Code-Optimierung. Sein Ansatz ist richtig, dh er betreibt einen Profiler, ermittelt einen Engpass und behebt ihn; Das Problem besteht darin, dass es keine nicht funktionalen Leistungsanforderungen gibt und keine Elemente darauf hindeuten, dass die Benutzer die Anwendung möglicherweise als langsam betrachten (und auf minderwertigen Entwicklungs-VMs gehostet, fühlt sich die App sehr reaktionsschnell an). Er hingegen verbringt praktisch die Hälfte der Zeit damit, den Code zu optimieren.

Die Bedeutung der Codeoptimierung kann gar nicht genug betont werden. Der Zweck der Code-Optimierung besteht nicht darin, sicherzustellen, dass er heute richtig läuft, sondern darin, ihn so zu optimieren, dass Sie drei Jahre später kein Problem beheben, das durch Code-Optimierung hätte verhindert werden können.

Wenn Sie sich nur darum kümmern, dass die Benutzer heute zufrieden sind, werden sie morgen an Ihre Tür klopfen.

6. Er schreibt sämtliches SQL von Hand und lehnt die Idee eines ORM ab. Dabei ist zu beachten, dass das aktuelle Produkt auf Microsofts ORM Entity Framework basiert und zwei der fünf Entwickler noch nie mit SQL gearbeitet haben.

Zwei der fünf Entwickler sollen 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 fange an zu verstehen, warum er jemanden frustriert einen „Code-Affen“ genannt hat. ORMs sind schön und gut, aber Sie müssen die SQL verstehen, wenn Sie jemals über die Grenzen eines ORM hinausgehen wollen.

7. 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 Sie nicht genug verstehen, um es selbst zu beheben, verstehen Sie den Code nicht. Argumentieren ließe sich so oder so. Wenn jedoch niemand im Team programmieren kann, ohne die Frameworks zu verwenden, dann haben Sie ein sehr schwaches Team.

8. Er ist der Meinung, dass mobile Geräte (einschließlich Tablets) nur ein Hype sind, daher gibt es keinen Grund, wertvolle Zeit zu verschwenden, um die Kompatibilität der Website mit diesen Geräten sicherzustellen und ein ansprechendes Design zu erstellen. Das Produkt ist eine öffentliche Webanwendung, von der nicht erwartet wird, dass sie häufig von mobilen Geräten verwendet wird. Responsive Design könnte für diese App jedoch sehr interessant sein, da es selbst auf Desktops sowohl auf 19-Zoll-Monitoren als auch auf großen hochauflösenden Monitoren angezeigt wird.

Nach allem, was Sie gesagt haben, hört es sich so an, als wäre er zum Putzen gebracht worden. Wenn mobile Geräte keine Hauptrolle für die Anwendung(en) spielen, ist es Zeitverschwendung, zu viel Zeit zu verbringen. Während es auf einem Desktop ein „nice to have“ sein mag, ist ein „nice to have“ keine Notwendigkeit für den Rollout.

9. Er bittet das Team, das Internet (insbesondere StackOverflow) nicht mehr zu nutzen und sich auf ihr Gehirn, die Offline-Dokumentation (ich wusste nicht einmal, dass Microsoft immer noch MSDN-CDs verkauft!) und die Bücher zu verlassen.

Gut für Ihn. Sieht so aus, als wollte er wissen, wer seine eigenen Hausaufgaben machen kann und wer betrogen hat.

Die Teammitglieder beschwerten sich beim Gründer des Unternehmens über ihren neuen Hinweis auf diese drei Probleme. Der Gründer antwortete, dass sie überreagieren und dass er aufgrund seines Lebenslaufs und des Interviews absolutes Vertrauen in die Fähigkeiten des neuen Leads habe, weshalb er dieser Person überhaupt erst die Rolle eines Lead Developers zugewiesen habe .

Was sollte das Team tun, um:

• Entweder die Führung aus dem Team oder dem Unternehmen werfen,

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

Wie wäre es, mit ihm zu arbeiten und nicht jede seiner Bewegungen zu sabotieren?

Ganz ehrlich, es hört sich so an, als wäre er zum Putzen gebracht worden, angesichts dessen, was Sie gepostet haben, klingt es mehr als gerechtfertigt.

Der Eigentümer ist mit Ihrer Leistung NICHT zufrieden. Es ziemt sich für Sie, den Rat dieses Kerls anzunehmen, was er wert ist. Wir Relikte haben ein bisschen Erfahrung und wir wissen, was die Bücher dich niemals lehren werden. Doch anstatt dies als Gelegenheit zum Lernen und Wachsen zu sehen, hat Ihr Team einen massiven Zischkrampf.

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

Aufhören sollte der letzte Ausweg sein.

Der Eigentümer muss einen Personalmanager einstellen

Andere Antworten haben darauf hingewiesen, aber der Elefant im Raum ist, dass der Eigentümer (verständlicherweise) Schwierigkeiten zu haben scheint, Personalfunktionen wie Einstellung, Schulung, Entlassung usw. erfolgreich auszuführen. Typisches Beispiel: Der Eigentümer beschäftigt ein unterdurchschnittliches Team, erträgt sie jahrelang, stellt dann einen 25-jährigen Veteranen ein, um die Dinge zu reparieren, und stellt dann einen Berater ein, wenn der 25-jährige Veteran die Dinge nicht reparieren kann. Der Besitzer scheint nicht zu wissen, wie er die Personalseite des Geschäfts führen soll. Das ist in Ordnung, es gibt Leute, die das beruflich machen, und deshalb haben die meisten Organisationen Personalmanager. Der Besitzer muss einen Stat einstellen. Dies gibt dem Eigentümer die Möglichkeit, sich auf die strategische Seite des Geschäfts zu konzentrieren, also ist es eine Win-Win-Situation.

Vielleicht könnte OP bei der Befragung helfen (immerhin scheint der Besitzer diesbezüglich Hilfe zu brauchen)?

Eine "Falte", die ich hier noch nicht gesehen habe. Es ist ziemlich üblich, dass Leute mit viel Erfahrung defensiv werden, weil sie mit aktuellen Entwicklungen nicht auf dem Laufenden sind. Mir ging es genauso, wenn Leute darüber sprachen, wie schrecklich VB6 im Vergleich zum wunderbaren .Net sei, wenn diese Leute nur Dinge wiederholten, die sie über VB6 gehört hatten und nicht wirklich viel darüber wussten.

Wie Sie sagen, treffen viele Dinge, die der Anführer sagt, auf den Punkt. Aber das bedeutet nicht, dass sie alle sind, wie Sie sagen. Vielleicht kann Herr 25 Jahre offen sein und seinen Ansatz mit dem Besten des Status quo synthetisieren, aber nicht, wenn er Angst davor hat, weniger als perfekt zu sein, und seine Angst leugnet. Soweit es mich betrifft, ist das hier das eigentliche Problem. Es mag andere Probleme mit den Junioren geben (z. B. Abwehr wegen mangelnder Fachkenntnisse), aber das scheint hier das zugrunde liegende Problem zu sein.

Wenn alle zusammenkommen und ihre Ängste offen und ehrlich ansprechen, sollten sie anfangen, 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 zusammen mit diesem Entwickler gesprochen und versucht, die Vorteile von Dingen wie Versionskontrolle und IDEs zu erklären? Eine offene Massendiskussion kann helfen

2. Ich stimme zu, dass es unprofessionell ist, andere Entwickler zu beleidigen, und dies sollte ihm mit Nachdruck erklärt werden. Fragen Sie ihn, ob er sich darüber freut, wenn andere den gleichen Ton annehmen

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

4. Fragen Sie ihn, ob er froh ist, uralt und ein mürrischer alter Idiot zu werden, dessen Verstand verkümmert, während 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 Gespräche mit ihm können aufgezeichnet werden