Es ist kein Witz, ich könnte es nicht ertragen, dass das ein viertes Mal passiert, es beeinflusst mich mental.

Diese Zeile ist wichtig, weil sie zeigt, dass Sie das Gefühl haben, dass es an der Zeit ist, sich zu ändern. Es zeigt, dass Sie dies als Muster erkennen und möchten, dass das Muster aufhört. Dieser Wunsch ist wahrscheinlich der wichtigste Teil der Lösung. Um diese Art von Situationen zu beheben, muss man oft die Art und Weise ändern, wie man selbst denkt. Es ist unmöglich, dass jemand das für Sie tut, also wird Ihr Wunsch nach Veränderung das Einzige sein, was die Veränderung bewirkt.

Für einige Hintergrundinformationen war ich schon einmal in ähnlichen "zu gut im Programmieren für meinen Job" -Situationen, allerdings nie in dem von Ihnen beschriebenen Ausmaß. Ich könnte Krebs mit Template-Metaprogrammierung in C++ heilen, aber viele, mit denen ich arbeite, sind kaum mit den Grundlagen des objektorientierten Designs vertraut. Ich habe Code geschrieben, der SFINAE missbrauchte und direkt gegen den genauen Wortlaut der C++-Spezifikationen stieß, als viele Projekte, an denen ich arbeitete, noch veraltete und fehlerhafte Versionen von gcc verwendeten. Mein Ansatz bestand einfach darin, ihnen zu zeigen, wie erstaunlich diese Tools sind und welche Probleme sie lösen können. Ich habe es geliebt, Leuten kleine Programmiertipps zu erklären, und sie haben es sehr genossen.

Kommt Ihnen das bekannt vor?

„Ja, aber man sollte [Miks Code] gut verstehen können, weil die Komponenten intelligent entkoppelt sind.“

Betrachten Sie diese Aussage aus einer risikobasierten Perspektive. Ihr Chef muss die Dinge am Laufen halten, egal was passiert. Wenn Sie gehen, um ein tolles Jobangebot zu jagen, muss Ihr Chef trotzdem dafür sorgen, dass der Code gepflegt wird. Was Ihr Kollege gerade gesagt hat, war, dass er, wenn er Sie ersetzen muss , einen sehr erfahrenen Programmierer finden muss, weil jeder, der nicht so gut ist, nicht in der Lage sein wird, ihn zu warten. Dies ist ein Risiko. Was ist, wenn sie keinen Entwickler finden, der gut genug ist, oder es sich nicht leisten können, ihnen genug zu bezahlen?

Sie haben vielleicht etwas produziert, was Sie „guten Code“ nennen würden, aber die Definition von „gutem Code“ hängt sehr stark vom Kontext ab. Was bei Google mit seinen hochmodernen Denkweisen "guter Code" ist, kann für jemanden, der bei der FAA arbeitet, sehr schlechter Code sein, dem es hauptsächlich um Zuverlässigkeit geht, anstatt mit der Schneide Schritt zu halten. Die Definition Ihres Chefs von „gutem Code“ beinhaltet die Fähigkeit, ihn in allen möglichen Situationen aufrechtzuerhalten, auch ohne Sie. Wenn Ihre Mitarbeiter sich nicht wohl dabei fühlen, Ihren Code zu pflegen, sind Sie plötzlich eine Belastung für das Unternehmen, weil Sie Produkte produzieren, die sie nicht warten können, wenn Sie sich entscheiden, woanders hinzugehen.

Aus dieser Perspektive könnte man argumentieren, dass Sie sie zwingen, Ihre Definition von „gutem Code“ zu akzeptieren. Instinktiv mag dies eine gute Sache erscheinen, aber es ist mit Schwierigkeiten behaftet, wie zum Beispiel diese risikobasierte Denkweise, an die Sie vielleicht nicht gedacht haben.

Wir haben einen Ausdruck: „den Karren vor das Pferd spannen“. Eine der vielen Bedeutungen, die damit verbunden sind, ist, den Inhalt, der Ihnen am wichtigsten ist (in der Lage zu sein, Ihre fortgeschrittenen Techniken anzuwenden), über die Kräfte zu stellen, die ihn vorantreiben sollten (das Verständnis Ihres Kollegen für diese Techniken). Sie haben den Code in diesem fortgeschrittenen Stil geschrieben und dann die anderen Entwickler ermutigt, diesen Stil "einzuholen". Das kann effektiv sein, aber wenn Ihnen etwas passiert, bevor sie „aufholen“, ist das Unternehmen plötzlich in Gefahr, weil niemand den Code pflegen kann.

Wie kann ich das in Zukunft vermeiden?

Dies zu beheben, kann sehr schwierig sein, da Sie das Problem auf eine andere Weise angehen müssen, als Sie es normalerweise tun. Anstatt zuerst Code in diesem fortgeschrittenen Stil zu schreiben und dann Ihren Kollegen beizubringen, wie man so denkt, sollten Sie ihn umdrehen. Bringen Sie Ihren Kollegen bei, diesen Programmierstil zu mögen, und beginnen Sie dann, Code in diesem Stil zu schreiben. Es mag rückständig erscheinen, aber es ist viel stabiler. Aus Sicht des Chefs besteht wenig bis gar kein Risiko, dass das Team lernt, besser zu programmieren. Sobald sie besser codieren, ist der Stil, in dem Sie sich entwickeln möchten, plötzlich weniger riskant.

In der Zwischenzeit müssen Sie Code schreiben, der nach Ihren Maßstäben "weniger gut" ist, aber das ist in Ordnung. Ihr Code ist hier nicht Ihr einziges Produkt. Ihr anderes Produkt hilft dabei, die anderen Entwickler zu unterrichten, und der Wert davon kann leicht den Wert des Schreibens von "perfektem Code" übersteigen.

Natürlich kann es schwierig sein zu sagen, wann es sicher ist, Code in dem Stil zu schreiben, in dem Sie schreiben möchten. Wenn es einfach zu sagen wäre, hätten Sie es sicherlich schon herausgefunden! Eine leistungsstarke Technik, die Sie verwenden können, besteht darin, andere auf die fortgeschrittenen Codierungsstile drängen zu lassen, anstatt selbst darauf zu drängen. Es ist eine Sache, jemandem den Unterschied zwischen Vererbung und Zusammensetzung beizubringen. Es ist eine ganz andere Sache, sie so gut zu unterrichten, dass sie befürworten, Ihre vorhandene Codebasis zu ändern, um klarer zu sein, wann sie sie verwendet. Der letztere Fall lässt Sie wirklich wissen, dass sie das Konzept nicht nur verstehen, sondern es wirklich annehmen.

Ein Ideal, um solche Konzepte zu lehren, ist, nichts zu lehren. Lassen Sie die Schüler etwas entdecken, und zeigen Sie ihnen dann eine Richtung, in die diese Entdeckung gehen kann. Vielleicht entdeckt einer von ihnen etwas Nettes über Vererbung und Sie können ihn basierend auf dem, was er entdeckt hat, auf das Visitor-Entwurfsmuster verweisen. Geben Sie ihnen nicht nur Visitor, sondern geben Sie ihnen einen Orientierungssinn, damit sie hinausgehen und Visitor selbst finden können.

Es ist ein viel schwierigerer Ansatz, und Sie werden sicherlich einen guten Mittelweg zwischen diesem und Ihrem aktuellen Ansatz finden wollen, aber es kann sehr lohnend sein. Noch wichtiger für Ihre Antwort ist, dass es dem Unternehmen ohne Risiko einen Mehrwert bieten kann. Wenn Sie einem Unternehmen einen Mehrwert bieten und das Unternehmen nicht gefährden, werden Sie praktisch nie entlassen. Und in den wenigen Fällen, in denen Sie noch entlassen werden können, wird das Management einen Grund dafür angeben (z. B. ein Konjunkturabschwung oder eine Änderung der Ausrichtung des Unternehmens). Wenn Sie es sehr gut machen, werden Sie feststellen, dass das Management stattdessen damit beginnt, Ihren Weg zu formen, so wie Sie Ihre Kollegen formen, und Sie werden eine merkwürdige Tendenz feststellen, dass Sie genau dann genau die richtige Fähigkeit gelernt haben, wenn sie sie am dringendsten brauchen .

Nun, ich hasse es, Ihre Blase zum Platzen zu bringen, aber wenn dies das dritte Mal ist, dass dies passiert, schließt das fast aus, dass "es nicht Sie, es sind sie". Ihr Titel besagt, dass Sie gefeuert wurden, weil Sie „unentbehrlich“ waren, aber abgesehen davon, dass es ein Oxymoron ist, ist es auch nicht das, was passiert ist. Sie wurden entlassen, weil Sie Code geschrieben haben, den Ihre Kollegen nicht verstehen können, was für einen Programmierer ein kritisches Leistungsproblem darstellt.

Guter Code ist lesbarer Code , also Code, der auch für Anfänger leicht verständlich ist . Die Situationen, in denen Sie komplexen und eng geschriebenen Code benötigen, der von echten Experten geschrieben und gepflegt werden sollte, sind heutzutage sehr selten, und Sie haben offensichtlich nicht für diese Art von Unternehmen gearbeitet. Was Sie beschreiben, klingt eher nach "ausgefallenem" Code, der normalerweise übermäßig komplex ist, voller esoterischer Programmiertricks und es dauert ewig, ihn herauszufinden und zu debuggen. Es ist ein häufiges Versagen von Menschen, die klassisch ausgebildet wurden, und ihnen steht normalerweise ein böses Erwachen bevor, sobald sie eine produktive Umgebung betreten.

Es gibt immer Gründe.

Ein früherer Arbeitgeber hat dies mit einem Kollegen von mir gemacht. Sein Können lag weit über unserem Können. Also wurde er entlassen.

Warum ist das sinnvoll?

1. Er war der Einzige, der seinen Code pflegen konnte
2. Er war nicht kooperativ
3. Er hielt sich nicht an die Geschäftsstandards
4. Er lieferte zwar mehr als nötig, aber das war keine gute Sache
5. Statt komplexer Lösungen waren einfache Lösungen gefragt.

Es wird so oft gesagt, dass es fast ein Klischee ist, aber man muss „gut passen“ ins Team.

Die Codierung ist nur ein Teil der Gleichung. Sie müssen sympathisch, kommunikativ, bis zu einem gewissen Grad bescheiden, bei Bedarf arrogant sein, sich an die Geschäftsstandards halten, mit Ihren Kollegen auskommen, aufgeschlossen sein und bei Bedarf schnell helfen können.

Alle diese Soft Skills sind wichtig, und wenn Sie sie nicht haben, werden Sie Probleme bekommen.

Guter Code ist leicht verständlich, selbst für arme Ingenieure. Ein Rat, den ich oft erhielt, lautet: „Programmieren Sie, als ob die Person, die Ihren Code pflegt, ein mittelmäßiger Programmierer und ein gefährlicher Psychopath ist, der weiß, wo Sie leben“.

Und es ist wahr. Eine zu schlaue Programmierung ist schlecht, weil die Wartung länger dauert, wenn man den Code nicht kennt . Bei der Wartung haben Sie oft überall Feuer, Tausende von Kunden blockiert, und eine cleverere und effizientere Lösung kann den Betreuer sehr wohl länger festhalten als ein dummer skriptähnlicher Code voller Wiederholungen.

Natürlich ist auch total dummer Code schlecht. Zwischen Dummheit und Genie gilt es, eine feine Balance zu finden: effizient und dennoch lesbar. Es ist mehr eine Kunst als eine Wissenschaft. Deshalb ist von schlauen Konzepten wie Mehrfachvererbung meist abzuraten . Auch wenn sie rocken.

Sie müssen den Kontext berücksichtigen. Wenn Sie in einer kleinen Edge-Firma arbeiten, die nur die Besten einstellt, können Sie sich wahrscheinlich einige exotische, brillante Dinge leisten. Wenn Sie für eine französische Bank arbeiten, die sich nur auf Berater von, ähm, zufälliger Qualität verlässt (manchmal haben sie Glück, manchmal nicht) und wo jeder Berater eine Domain von Millionen von LOC zu pflegen hat, dann machen Sie es auf jeden Fall einfach genug für einen Mittelmäßigen auf den ersten Blick zu verstehen. Keine Zeiger, keine Mehrfachvererbung, keine schlauen Tricks, etc...

Es ist unwahrscheinlich, dass Sie gefeuert werden, weil Sie zu gut sind. Ich denke, das ist nur eine Ausrede.

Es ist viel wahrscheinlicher, dass es sich um ein Verhaltensproblem handelt oder der Chef Sie einfach nicht mag, aus Gründen, die er Ihnen nicht sagen kann, ohne einen Grund für eine Klage zu schaffen. Es ist auch möglich, dass Sie am teuersten sind und sie an FTEs glauben (dh jeder Arbeitnehmer ist gleich).

Wenn Sie wirklich so gut sind, können Sie sich auf gute Weise unentbehrlich machen:

• Mentor der Junior-Programmierer. Nennen Sie die Vor- und Nachteile verschiedener Ansätze und lassen Sie sie ihre Fehler machen, anstatt ihnen zu sagen, welchen Ansatz sie wählen sollen.
• Schreiben Sie guten Code, der von anderen leicht zu warten ist.
• Setzen Sie sich für Best Practices ein, die die Produktivität steigern, im Gegensatz zu Best Practices des Cargo-Kults , die auf dem Papier gut klingen, aber die Produktivität beeinträchtigen.

Unentbehrliche Leute zu feuern ist eigentlich eine vernünftige Managementstrategie. Wenn sich Ihr Unternehmen darauf verlässt, dass eine einzelne Person weiterhin ihre Arbeit erledigt und niemand sonst im Unternehmen über ihr Wissen und/oder ihre Fähigkeiten verfügt, entsteht eine enorme Haftung: Was ist, wenn diese Person von einem Bus angefahren wird und stirbt (daher der Begriff „Bus Faktor') oder entscheidet sich einfach dafür, das Unternehmen für eine neue Herausforderung zu verlassen? Jetzt steckt Ihr Unternehmen in einer schlimmen Situation, weil niemand den unverzichtbaren Mitarbeiter sofort ersetzen kann und Sie keine Kontrolle über das Timing hatten!

Um dieser Situation vorzubeugen, hat das Unternehmen zwei Möglichkeiten. Entweder können sie versuchen, das Wissen zu verbreiten und/oder die Fähigkeiten der Mitarbeiter der unentbehrlichen Person zu verbessern, oder sie können das Pflaster auf einen Schlag abziehen, indem sie die unentbehrliche Person zu einem Zeitpunkt ihrer Wahl feuern und sich von dem Verlust erholen des besagten Arbeiters, wenn sie auf diesen Prozess vorbereitet sind.

Da es nicht immer praktikabel ist, eine große Wissens- und insbesondere eine Fähigkeitslücke zu schließen, kann eine Entlassung die logischere Wahl sein.

Als Arbeitnehmer sollten Sie immer versuchen, nicht unentbehrlich zu werden. Teilen Sie Ihr Wissen mit Ihren Kollegen und stellen Sie sicher, dass es Menschen gibt, die Ihre Arbeit erledigen können, wenn Sie nicht da sind. Stellen Sie sicher, dass Ihre Praktiken für die Arbeitnehmer mit dem durchschnittlichen Qualifikationsniveau in Ihrem Unternehmen geeignet sind. Wenn Sie der Meinung sind, dass das durchschnittliche Niveau zu niedrig ist, arbeiten Sie mit dem Management zusammen, um zu versuchen, dieses Niveau zu erhöhen. Stellen Sie sicher, dass alles, was Sie erstellen, gut dokumentiert ist und dass diese Dokumentation von einem hohen Standard ist, damit jeder Ihrer Kollegen sie verwenden kann, um Ihre Arbeit fortzusetzen.

Wenn die einzige Gemeinsamkeit zwischen den drei Situationen Sie sind, dann müssen Sie bedenken, dass etwas, das Sie tun, ein Problem darstellt.

Haben Sie mit Ihren ehemaligen Kollegen gesprochen und sie gebeten, Sie zu kritisieren? Nicht Ihr Code, sondern Ihr Verhalten im Büro. Die Art und Weise, wie Sie mit Ihren Kollegen kommunizieren, die Art und Weise, wie Sie mit Ihrem Chef kommunizieren, die Art und Weise, wie Sie Dokumentationen erstellen, wie Sie sich in Besprechungen verhalten usw.

Versetzen Sie sich in die Lage Ihres Vorgesetzten? Wirklich darüber nachgedacht, was sie tun müssen, was ihre Aufgaben sind, was ihnen ein gutes Gefühl gibt, wenn sie das Bürolicht ausschalten und nach Hause gehen? Es gibt viele, viele Beispiele, wo jemand erstaunlichen Code aus der Perspektive anderer Softwareentwickler schreibt , aber das Unternehmen scheitert.

Ich habe mir Ihr Profil angesehen, da steht "Ihr Code sollte sauberer sein als Sie selbst". Auch aus Ihren Kommentaren, dass Sie "viel Zeit damit verbracht haben, Konzepte zu erklären" und "Kritik gehört zu meinem Job als Ingenieur" ... Ich denke, Sie geben gerne Ratschläge und Ihre Ratschläge werden von Ihnen einfach nicht geschätzt Teamkollegen.

Dies kann an dem liegen, was Sie sagen, oder an der Art und Weise, wie Sie es sagen, wahrscheinlich an beidem.

Das Schreiben von produktivem und wartbarem Code führt nicht dazu, dass Sie gefeuert werden. Sie werden gefeuert, wenn Sie mit dem Team nicht zurechtkommen. Das ist Ihr Problem, nicht (wie Sie es sich vorstellen) Ihr Code ist zu gut. Ihr Code könnte wirklich gut sein - aber VIEL wahrscheinlicher ist dies ein Persönlichkeitskonflikt.

Mein Rat an Sie ist, seien Sie nicht der Schwanz, der versucht, mit dem Hund zu wedeln. Halten Sie den Kopf unten, hören Sie auf, den Leuten zu sagen, wie sie programmieren sollen, folgen Sie den Anweisungen, arbeiten Sie gut mit anderen zusammen, schreiben Sie wartbaren Code. Und dann wirst du nicht gefeuert.

Ich nehme auch mit Interesse diesen aufschlussreichen Kommentar Ihres Vorgesetzten zur Kenntnis:

"Aber ist es wirklich gut, wie er vorgibt?"

Das sagt Ihnen, dass Ihr Vorgesetzter Ihnen nicht vertraut , Ihr Vorgesetzter Sie für unauthentisch und arrogant hält und/oder Ihre eigenen Fähigkeiten höher einschätzt, als Sie tatsächlich haben. Beziehungen sind auf Vertrauen angewiesen, um zu überleben. Beachten Sie, dass Ihr Problem kein technisches Problem ist. Ihr Problem hat sehr wenig mit der Qualität Ihres Codes zu tun. Was Sie haben, ist ein Problem mit der Art und Weise, wie Sie mit Ihren Kollegen und Ihrem Vorgesetzten umgehen.

Menschen werden nicht oft gefeuert, weil sie unentbehrlich sind ( warum Menschen gefeuert werden ); Das ist eine lächerliche Behauptung. Der Artikel, auf den Sie verweisen, qualifiziert eindeutig, dass "Feuer" nicht unbedingt bedeutet, sie gehen zu lassen, sondern sie nicht unverzichtbar zu machen (indem Sie sie verschieben, sie zwingen, nicht an einem bestimmten Projekt beteiligt zu sein usw.).

Überqualifiziert wird Sie zwar manchmal nicht einstellen, aber auch selten entlassen. Gute Mitarbeiter sind sehr schwer zu finden; Keine vernünftige Firma wird einen loswerden, weil sie zu gut sind (es sei denn, Sie arbeiten nur für einen Idioten – dann tun sie Ihnen einen Gefallen).

Menschen werden gefeuert, weil sie DENKEN, dass sie unverzichtbar und besser als ihre Kollegen sind, und sich daher weigern, die Änderungen vorzunehmen, die am Mann im Spiegel vorgenommen werden müssen, um in einem Team gut zu funktionieren. ( gefeuert wegen schlechter Einstellung )

Wenn Sie mit einem Haufen Eingeborener eine Brücke bauen und einen Laptop zücken, während der Rest Seile bindet, sind Sie vielleicht klüger oder gebildeter, aber Sie sind zu einem Nachteil für das Team geworden, und das Problem sind SIE.

Wenn Sie wirklich so großartig sind, wie Sie sich darstellen, wären Sie schlau genug, Ihre eigenen Handlungen anzupassen, um ein möglichst produktives TEAM zu bilden, anstatt dogmatisch Ihre eigene Agenda voranzutreiben (was Sie wahrscheinlich tun). Wenn Sie das tun würden, hätten Sie wahrscheinlich sehr lange einen Job.

Als jemand, der regelmäßig am Einstellungsprozess beteiligt ist, ziehe ich jeden Tag jemanden, der gut und sympathisch ist, einem großartigen und potenziellen Krebs vor.

Jedes Programm ist eine Kommunikation mit zwei Zielgruppen: einem Compiler oder Interpreter, der es ausführen wird, und einigen Menschen, die es gelesen und verstanden haben. Möglicherweise kommunizieren Sie sehr gut mit dem Compiler und schreiben dennoch schlechten Code, weil er von den anderen beteiligten Personen nicht ohne weiteres verstanden werden kann.

Typischerweise verfügt ein Programmierteam über eine Reihe von Sprachen, Frameworks, Techniken usw., die jedem im Team bekannt sind. Neue Mitarbeiter, denen einige dieser Teile fehlen, absorbieren sie schnell, weil jeder im Team sie erklären kann.

Die Verwendung von etwas außerhalb dieses Sets ist mit Kosten für den Arbeitgeber verbunden. Angenommen, Sie sind der einzige Programmierer in der Gruppe, der mit Framework X vertraut ist, und alle anderen sind mit einem älteren Framework Y vertraut, das für einen vorhandenen Code verwendet wird und fast so gut wie X ist.

Die Verwendung von Framework X wäre ein Fehler, es sei denn, es ist so viel besser als Y, dass das Management zustimmt, dass die technischen Vorteile aus der Verwendung ausreichen, um den Schulungsaufwand zu rechtfertigen, um alle mit X vertraut zu machen.

Eine Technik, die Sie verwenden könnten, besteht darin, Ihren Code von einigen der am wenigsten erfahrenen Personen überprüfen zu lassen, die ihn lesen können müssen. Sehen Sie, worüber sie zu fragen haben, und überlegen Sie, wie Sie diese Teile umschreiben könnten, um ihnen klarer zu sein. Je mehr Sie das Nichtverstehen Ihres Codes als Fehler im Code und nicht als Fehler der Leser behandeln, desto besser wird das Feedback, das Sie erhalten.

Beschlossen, meinen Kommentar zu einer Antwort zu aktualisieren:

Dokumentieren Sie Ihren Code sehr gut.

Eine ordnungsgemäße Codedokumentation verwandelt schlechte Erfahrungen, bei denen ein Junior-Entwickler stundenlang mit dem Kopf gegen eine unverständliche Wand schlägt, in potenzielle Lernerfahrungen.

Die meisten Antworten behandelten Ihren Beitrag unter dem Gesichtspunkt, ob Ihr Code lesbar war oder nicht oder so gut, wie Sie sagen, dass er ist. Aber diese Situation kann und kommt in allen Lebensbereichen vor. Ich nahm einen Job auf dem Las Vegas Strip als 21 Dealer und Floorman an. Meine Techniken und meine Geschwindigkeit waren dem Rest ihres Personals so weit voraus, dass die Leute, die mich überwachen sollten, nicht mithalten konnten. Mit anderen Worten, sie konnten meinen Entscheidungen nicht folgen. Da große Geldbeträge innerhalb von Minuten abgewickelt wurden, fühlten sie sich oft verwirrt und meldeten mich ihrem Vorgesetzten und behaupteten, ich hätte einen Fehler gemacht. Ich würde meine Handlungen dieser Person gegenüber immer rechtfertigen, aber das Misstrauen mir gegenüber vertiefte sich.

Mein Ego und ich vermute, Ihres hat die Warnzeichen nicht gesehen und tatsächlich habe ich in meiner Überlegenheit geschwelgt, sie sozusagen ausgegossen. Mir wurde gekündigt und ich verlor eine extrem gut bezahlte Position.

Die Lektion ist einfach, Sie müssen auf das Niveau der anderen herunterdummyen. Wenn sie nur 15 Hände pro Stunde bekommen und Sie 100 bekommen, dann inspirieren Sie kein Lob. Sie wecken Eifersucht und sogar Hass. Wenn Ihr Stolz dies nicht kann, müssen Sie einen anderen Weg finden, Ihren Lebensunterhalt zu verdienen, denn alle Orte sind im Wesentlichen gleich. Menschen sind Menschen, man kann sie nicht ändern. Ich habe mich schließlich in anderen Arbeitsbereichen niedergelassen, in denen ich ebenfalls mittelmäßig war und daher nicht auffiel. Ich hoffe, Sie können das zu Ihrem Vorteil klären.

Ich habe gelesen, dass Sie vom ersten Tag Ihrer Arbeit an für diese Behandlung bestimmt waren. Sie sagten, Sie wurden eingestellt, weil Sie Fähigkeiten haben, die sonst niemand in der Organisation hat (TypeScript, Node). Und jetzt, wo Sie sich abgemüht haben, ganz allein eine elegante, fachmännisch gefertigte, komplexe Lösung zu produzieren , versteht niemand, was Sie getan haben, und deshalb werden Sie vom Management als Belastung angesehen.

Wenn das alles stimmt, hätte es wirklich nicht anders kommen können.

Aus meiner Sicht ist das Problem strukturell, nicht persönlich, und daher liegt die Schuld in der Situation und im Prozess, nicht in der Person:

• Die Organisation stellte eine einzelne Person mit völlig anderen Fähigkeiten als alle anderen und auf einem fortgeschrittenen Niveau dieser Fähigkeiten ein, um eine entscheidende Funktion zu erfüllen. Dies garantiert, dass Sie bei guter Leistung der einzige sind, der Code versteht, der für die Mission der Organisation entscheidend ist. (Es ist völlig unvernünftig, von einer hochrangigen Ressource zu erwarten, dass sie Code produziert, der für Personen, die die verwendete Sprache nicht kennen, sofort Sinn ergibt.)
• Die Organisation hat Sie nicht regelmäßig dem Codeüberprüfungsprozess unterzogen. Wenn dies der Fall gewesen wäre, wäre Ihr Code abgelehnt worden, bis Sie ihn in Übereinstimmung mit ihren Lesbarkeitsstandards gebracht hätten. Da Sie der einzige Mitwirkende am Code sind, mit Ihrem eigenen Stil und einem anderen Tech-Stack, ist es praktisch garantiert, dass der Code mit der Zeit für andere immer weniger verständlich wird. Die einzige Möglichkeit für Sie, dies zu verhindern, besteht darin, andere ständig außerhalb des Prozesses um eine Codeüberprüfung zu bitten und möglicherweise den Vorwurf zu erheben, die Zeit anderer zu verschwenden. Ein fehlender Code-Review-Prozess bereitet Sie somit auf ein Scheitern vor.

Ich habe ähnliche Erfahrungen in meinem Hintergrund. Ich wurde einmal eingestellt, um eine Qualifikationslücke zu schließen. Niemand sonst im Unternehmen hatte eine Fähigkeit, die er plötzlich brauchte. Ich habe meine Arbeit gut gemacht und nach ein paar Monaten begannen Konflikte. Ich war der einzige, der mit bestimmten Komponenten der Anwendung arbeiten konnte. Ich wurde zu einem Engpass, als sich Arbeit anhäufte, die nur ich erledigen konnte. Eines Tages wurde ich ins Abseits gedrängt, als das Unternehmen beschloss, alles, was ich produziert hatte, durch komplett neuen Code zu ersetzen. Mein Stolz war damals verletzt, aber im Nachhinein war es die richtige Entscheidung für das Unternehmen. Nach einer Weile war es für mich an der Zeit, weiterzumachen, und das tat ich.

Wenn Ihnen das bekannt vorkommt, ist es vielleicht an der Zeit, dass Sie weitermachen. Vielleicht wird Ihnen das Management sogar etwas anderes zuweisen, wenn es Ihre Fähigkeiten weiterhin schätzt. Oder wenn Sie es ertragen können, können Sie vielleicht helfen, alles, was Sie getan haben, in den Standard-Technologie-Stack des Unternehmens umzuschreiben. Wenn das nicht möglich ist, gehen Sie einfach. In jedem Fall ist Ihr Code wahrscheinlich auf dem Weg in den Mülleimer. Das ist wahrscheinlich das Richtige für sie, wenn es sonst niemand versteht. Und überhaupt ist es die natürliche Folge ihrer Entscheidungen.

Stellen Sie sicher, dass andere in Ihrem Team bei Ihrem nächsten Job im Wesentlichen die gleichen Fähigkeiten anwenden wie Sie, und insbesondere, dass sie einen Code-Review-Prozess haben. Wenn sie Sie bitten, Ihren Code auf bestimmte Weise zu ändern, tun Sie es. Betrachten Sie den Code nicht als geliefert, bis er die Codeüberprüfung bestanden hat und Ihre Kollegen dem Management mitteilen (falls Sie danach gefragt werden), ja, der Code ist gut. Dann gibt es kein Problem. Es ist völlig in Ordnung, in einem technischen Interview Fragen zu solchen Dingen zu stellen. Ich habe es so oft getan. Hoffentlich gibt Ihnen dieser andere Entwickler, der Ihren Code studiert hat, eine gute Referenz.

Als Fußnote: Wenn Sie zumindest teilweise für Ihre Umstände verantwortlich sind, ganz alleine zu arbeiten, ohne Unterstützung durch andere Teammitglieder, dann verdienen Sie auch zumindest einen Teil der Verantwortung für das Ergebnis. (Haben Sie darauf gedrängt, TypeScript / Node zu verwenden, wenn andere etwas anderes verwenden wollten? Haben Sie die neueste, coolste Bibliothek oder Technik verwendet, obwohl etwas Grundlegenderes gut getan hätte? Ich habe mich auch ein- oder zweimal dafür schuldig gemacht. ) Wenn ja, ziehen Sie unbedingt eine Lehre aus diesem Ergebnis. Aber wenn nicht, nehmen Sie diese Erfahrung mit hoch erhobenem Haupt in Ihre nächste Position mit.

Es ist möglich, dass Sie einfach nicht so gut sind, wie Sie denken, aber der Höflichkeit halber gehe ich davon aus, dass Sie wissen, wie man die richtige Menge an komplexem Code schreibt, um die Komplexität und den Zeitbedarf der gesamten Codebasis um ein zu reduzieren Größenordnung. Dass dies überhaupt möglich ist, überrascht viele Idioten. Sie finden es ein ungläubiges Angebot, und der einzige Weg, sie zu überzeugen, besteht darin, es ihnen zu zeigen.

Aber das erfordert Fingerspitzengefühl, Mut und Selbstbeherrschung. Sie müssen sich vor allen anderen auf drei Dinge konzentrieren: beweisen, dass Sie keine Bedrohung darstellen, die Idioten schlau aussehen lassen und niemals einen einzigen Idioten erkennen lassen, dass Sie wissen, dass er ein Idiot ist. Wenn Sie sich nicht dazu bringen können, diese drei Dinge zu tun, werden Sie scheitern, und es wird Ihre Schuld sein. Pragmatismus ist ein Muss, und für Stolz ist kein Platz.

Obwohl ich diesen Ansatz nicht jedem empfehlen kann, hat es bei mir immer funktioniert, manchmal zu ignorieren, was feindselige Idioten mir sagen. Stattdessen finde ich Wege zu dem, was ich tun möchte, produziere in kürzester Zeit die beste Software, deren Code viele von ihnen je gesehen haben, und ich präsentiere sie so, dass ihre Chefs sie mit glühendem Lob belohnen. Auch wenn sie bei der Entstehung keine Rolle gespielt haben. Auch wenn sie sich aktiv dagegen wehren.

Ist es richtig? Sollte ich nicht die volle Anerkennung für meine Arbeit bekommen? Sollte ich wirklich um die Gefühle aller herumtanzen müssen? Irrelevant. Das ist die Realität. Wenn ich mich nicht daran anpasse, dann bin ich der Idiot.

Es gibt viele kluge Leute , die denken, dass hochqualifizierte Entwickler unersetzlich sind und dass Sie sie deshalb wollen . Aber Sie haben die anderen Antworten auf Ihre Frage gesehen – die meisten Manager wollen sich nicht mit den Problemen eines Teams mit sehr unterschiedlichen Qualifikationsniveaus befassen und haben nicht die Möglichkeit, rein hochqualifiziert zu werden. Sie liegen auch nicht unbedingt falsch, die Probleme sind real, und die Vorteile von hochwertigem Code, der die Fähigkeiten der meisten Leute, die sie einstellen können, übersteigen, werden stark verringert.

Wenn Sie auch nur annähernd so gut sind, wie Sie sagen, dann passen Sie nicht zu Ihrem Job. Es hört sich so an, als sollten Sie sich bemühen, an einem Ort zu arbeiten, an dem Sie von Ihren Kollegen lernen können und Ihre Kollegen Ihren Code verstehen können.

Wenn Sie dadurch ein paar Jobs verloren haben, werden Sie bei HR, Personalvermittlern und Managern ziemlich schlecht aussehen. Hoffentlich können Sie sich in einen Job vernetzen, indem Sie Entwickler mit ähnlichen Fähigkeiten treffen, die bestätigen können, dass das Problem wirklich darin besteht, dass Ihre Fähigkeiten zu hoch sind.

Abschließend muss ich hinzufügen, dass Sie Ihr Bestes tun sollten, um ehrlich zu beurteilen, ob Ihr Können wirklich so hoch ist. Es klingt, als gäbe es Beweise dafür, aber die meisten Menschen glauben, dass sie besser sind, als sie sind. Auch durchlaufen viele Entwickler eine Phase, in der sie in einem Ansatz sehr gut werden, aber noch nicht immer alles zu einer global optimalen Lösung zusammenfügen und es ihnen immer noch an Flexibilität mangelt. Manchmal ist es beispielsweise am besten, sich für eine minderwertige Lösung zu entscheiden, von der Sie wissen, dass Ihre Mitarbeiter sie warten können, wenn Sie wissen, dass sie keine anspruchsvollere Lösung warten können, und wahrscheinlich niemanden einstellen werden, der dies kann.

Um konkret auf die Frage einzugehen,

Wie kann ich das in Zukunft vermeiden?

• Finden Sie ein lokales Toastmasters-Kapitel, nehmen Sie aktiv teil und verdienen Sie sich die Errungenschaften. Etwas, das als Feedback so offensichtlich erscheint, wird hoffentlich geschätzt und zu einer Ihrer wertvollsten Fähigkeiten geschärft.

• Üben Sie sich darin, der Student statt der Experte zu sein. Haben Sie diesen Vortrag von Jon Skeet über die Grundlagen gesehen ? Können Sie sich vorstellen, wie viel mehr Verständnis erreicht werden kann, wenn wir alle eine solche Dokumentation erstellen würden, es würde allen auf allen Ebenen eines Teams zugute kommen!

• Ein Team ist nicht ein Individuum. Ihr Team wird gemeinsam wachsen und sich verbessern. Du musst helfen. Es ist kein Team, wenn jedes Mitglied eine Zelle ist, die in verschiedene Richtungen geht (z. B. Sie höher und das neueste Mitglied stagniert). 2-Stunden-Meetings sind ein guter Anfang. Ich würde noch die N-Tage-Paarungsrotation hinzufügen. Dies ist die 1:1-Zeit, die Sie Ihren Teamkollegen schenken UND sie Ihnen schenken . Lehnen Sie sich in Ihrem Fall in Richtung der Navigatorrolle und lassen Sie Ihren Partner fahren. Üben Sie, den Code nicht zu schreiben, so seltsam das auch klingen mag.

• Arbeite ehrenamtlich bei einem lokalen Meetup und bei Hack-A-Thons. Es kann Sie zwingen, Ihren Code zu destillieren, weil der Zweck darin besteht, zusammenzuarbeiten und kein fehlertolerantes Energieversorgungsnetz aufzubauen, richtig?

• Probieren Sie in jeder dieser Übungen dieses Konzept aus: Führen durch Dienen. Wie können Sie eine Aufgabe erledigen oder etwas erreichen, um den Bedürfnissen eines anderen Teammitglieds zu helfen?

• Wie bereits erwähnt, tragen Sie zu Open-Source-Projekten bei, um mehr Einblicke in Ihren Code zu erhalten. Sie können bestätigen, dass Sie brillant sind, aber sie können auch die Vorschläge verstärken, die Sie von Ihrem derzeitigen Chef hören. Im besten Fall gibt Ihnen eine Überprüfung eine neue Idee.

• Finden Sie einen Ingenieur, der besser ist als Sie. Es geht nicht darum, sich selbst zu verbessern, um der klügste Typ im Raum zu sein. Es gibt ein Zitat (mein Googeln ist zwischen Olgivy / Ford / Sorkin aufgeteilt), das umschrieben lautet: "Sie können nicht mehr lernen, wenn Sie sich mit schlechtem Talent umgeben".

TL;DR : Finden Sie einen geeigneteren Arbeitsplatz und seien Sie ehrlich in Bezug auf die Fähigkeiten, die Sie noch lernen müssen.

Sie klingen für mich nach dem „Software-Handwerksstil“ des Entwicklers – interessiert an Best Practices und immer auf der Suche und Befolgung guter Wege, Dinge im Code zu erledigen. Vielleicht wären Sie in einem Umfeld glücklicher, in dem sich andere Entwickler mehr für solche Dinge interessieren - und solche Arbeitsplätze gibt es viele.

Einige der Dinge, die Sie gesagt haben, erwecken jedoch den Eindruck, dass Sie manchmal denken, dass es einen einzigen „besten Weg“ gibt, Dinge im Code zu tun, die immer befolgt werden sollten. Vielleicht liege ich da falsch – aber wenn ich richtig liege, müssen Sie möglicherweise etwas lernen, wenn es darum geht, die Vor- und Nachteile alternativer Entscheidungen zu untersuchen und den Weg zu finden, der die beste Balance für das Unternehmen darstellt. Tatsächlich werde ich sagen, dass Sie sich dort definitiv verbessern müssen - denn das tun wir alle !

Ich gehe davon aus, dass Ihre Beschreibung der Situation so ist, wie Sie sagen. Ich kann nicht sagen, dass ich genau diese Erfahrung gemacht habe, aber es gibt Aspekte davon, die mir vertraut sind.

Sie sagen, dies sei ein „großes“ Unternehmen. Ich weiß nicht, wie es in Frankreich ist, aber oft legen größere Unternehmen keinen Wert auf interne Entwicklerfähigkeiten, insbesondere wenn es sich nicht um technologieorientierte Unternehmen handelt. Ich führe das vor allem darauf zurück, dass Manager in solchen Unternehmen oft keinen technischen Hintergrund haben oder aus der Entwicklung weggezogen sind, weil sie nie so gut darin waren.

Es gibt auch einen historischen Aspekt von Anbietern, die Tools verkaufen, die den Bedarf an talentierten Entwicklern beseitigen sollen. Selbst wenn Ihr Team eines dieser schrecklichen Dinge nicht verwendet, besteht die Möglichkeit, dass das Management des Unternehmens mit einer anti-intellektuellen Vorstellung von Entwicklungsteams indoktriniert wurde. Ich hatte tatsächlich einen Manager, der mir ins Gesicht sagte, dass ich schlau genug sei, eine bestimmte Lösung zu bauen, aber dann würde niemand sonst in der Lage sein, sie zu warten, also mussten wir etwas kaufen (Regalware). Ich glaube also, dass dies passieren kann .

Möglicherweise müssen Sie sich nach einer anderen Art von Unternehmen umsehen. Einer, der hochqualifizierte Entwickler schätzt. Möglicherweise müssen Sie sich jedoch damit auseinandersetzen, dass Sie dort nicht der beste Entwickler sind. Wenn Sie ein aufstrebender Koch wären, wären Sie wahrscheinlich unglücklich bei McDonald's zu arbeiten. Sie brauchen keine Köche. Sie brauchen Menschen, die einem Rezept folgen. Sie können Chefkoch sein und diese Firma (und andere ähnliche) ist McDonald's. Die Frage, die Sie sich stellen müssen, ist, warum Sie dies noch nicht getan haben.

Manchmal, wenn Sie mit anderen sprechen, müssen Sie es "verdummen", damit Sie die Leute nicht beleidigen. Besonders wenn Sie den anderen, mit denen Sie zusammenarbeiten, weit überlegen sind, sind sie wahrscheinlich beleidigt, wenn Sie über Tipps und Fakten sprechen, die sie wahrscheinlich kennen sollten, aber nicht kennen.

Ich würde sagen, kommentieren Sie Ihre Arbeit wirklich gut, damit die Leute, die sie überprüfen, sie verstehen können. Möglicherweise müssen Sie sogar in Ihren Kommentaren „begründen“, warum Sie diese Codierungsmethode einer anderen vorziehen. Sie sind vielleicht der beste Programmierer, aber wenn Sie Teil eines Teams sind, müssen Sie als Team arbeiten.

Wenn die Arbeit im Team bedeutet, mit einer Hand hinter dem Rücken zu arbeiten (damit meine ich, ihrer Programmierpräferenz zu folgen), dann tun Sie es. Zumindest können sie es dann lesen, verstehen und das Team selbst ist besser dran (auch wenn das bedeutet, dass Sie innerlich schreien).

Fast überall, wo Sie Teil eines Teams sind, gibt es Richtlinien darüber, wie Dinge codiert werden sollen – und Sie müssen diese Richtlinien befolgen.

Wie kann ich das in Zukunft vermeiden?

Arbeiten Sie mit niemandem zusammen, von dem Sie nicht hinreichend sicher sind, dass dessen Codierungsstandard mit Ihrem übereinstimmt. Das bedeutet, dass Sie jeden Job ablehnen, wenn keiner der folgenden Punkte zutrifft:

• Sie stellen Ihnen während ihres Interviewprozesses Programmierfragen
• Sie haben Peer-Programming-Übungen
• Sie fragen nach einem Codebeispiel und sind damit einverstanden
• Sie können einen Teil des Codes sehen, den sie erstellt haben

Wie kann ich das in der Gegenwart vermeiden?

Dies wurde durch andere Antworten abgedeckt.

Wenn Sie nur so viel besser sind, erreichen Sie ihr Niveau und bringen Sie ihnen langsam bei, bessere Programmierer zu werden. Als ich das erste Mal einen Praktikanten leiten musste, habe ich fast den gesamten Code, den er produziert hat, ausgelöscht. Ich war buchstäblich wütend, als ich sah, was begangen wurde (zum Glück hatte ich keine Zeugen :P ) .

Sie müssen Peer-Programmierung und Code-Reviews fördern. Setzen Sie sich mit einem anderen Programmierer zusammen und versuchen Sie, 2 oder 3 Stunden lang gemeinsam zu programmieren. Lassen Sie Konzepte fallen, die möglicherweise zu schwer zu erklären sind (z. B. neue erweiterte Java 8-Funktionen), und erklären Sie diejenigen, die einfacher sind (Vererbung).

Sie klingen, als wären Sie ein guter Programmierer, um sich an viele Situationen anpassen zu können. Sehen Sie sich an, wie andere codieren, und verhalten Sie sich entsprechend. Fragen Sie gelegentlich, ob Sie verschiedene Möglichkeiten ausprobieren können, und stellen Sie sicher, dass es nicht zu weit über das hinausgeht, was alle anderen verstehen können.

Normalerweise würde ich diesen Rat nicht geben, aber dieses Problem scheint Sie zu verfolgen, wohin Sie auch gehen, also hören Sie auf, dagegen anzukämpfen, bis Sie einen Job finden, bei dem dies kein Problem ist. Sie können in Betracht ziehen, sich an einem Projekt zu beteiligen, bei dem es eine kleine Anzahl anderer Entwickler gibt, die Sie mitbringen könnten, damit es nicht so aussieht, als ob nur Sie so "abnormal" programmieren.

Es ist eine Schande, dass andere Ihre Arbeit nicht schätzen oder daraus lernen wollen, wenn das der Fall ist. Hör auf, mit dem Kopf gegen die Wand zu schlagen. Wer weiß, es wird ein Projekt/eine Aufgabe auftauchen, bei der Sie die einzige Hoffnung sind, es zum Laufen zu bringen. Niemand wird sich darum kümmern, wie kompliziert Ihr Code auf lange Sicht ist, wenn Sie ihn einfach zum Laufen bringen, wenn es sonst niemand kann.

Wir können uns nicht langfristig auf ihn verlassen

Das ist das Hauptproblem. Sie wollen nicht von Ihnen abhängig sein, aber Sie wurden eingestellt, weil sie tatsächlich von Ihnen abhängig sind.

Sie können das Management entweder beruhigen mit:

• Sie denken sowieso nicht daran, woanders hinzugehen, damit sie sich langfristig auf Sie verlassen können.

Ich denke, ich werde mit Problemen herausgefordert, die meine Fähigkeiten nutzen, also denke ich, dass ich endlich einen Arbeitsplatz finde, an dem ich lange Freude haben kann

• Sie sind bereit, andere Teammitglieder zu schulen, um dem Team einen Mehrwert zu bieten.

Mir ist aufgefallen, dass der Code anderer nicht wirklich auf dem neuesten Stand der Softwareentwicklungstechniken ist, das ist kein Problem, ich kann diese Techniken ganz einstellen, aber es wäre von Vorteil, wenn alle anfangen würden, diese Techniken allmählich zu verwenden, um die Leistung des Teams zu verbessern. Ich kann dabei helfen.

• Sie wurden gebeten, die Funktionen XY zu implementieren, da die innerhalb der Zeit gelieferten Funktionen Ihre Fähigkeiten erforderten, hätten die Dinge auf andere Weise erledigt werden können, aber in viel mehr Zeit und mit dem Risiko zusätzlicher Fehler.

Darf ich etwas mehr Zeit haben, um die nächsten Features fertigzustellen? Ich habe wirklich hart gearbeitet, um die Dinge richtig zu erledigen, ich habe es geschafft, aber ich fürchte, nicht jeder kann das verstehen, stattdessen möchte ich mir etwas Zeit nehmen, um die Dinge für andere verständlich zu machen.

Seien Sie ehrlich, wenn eine Aussage nicht zutrifft (ich weiß jetzt nicht, woran Sie gearbeitet haben), lügen Sie niemals.

Wenn sie dich feuern, dann sind sie nicht wirklich von dir abhängig. Auf jeden Fall verstehen mindestens 2 Personen im Team Ihre Arbeit: Sie und Ihr Kollege. Und die Chancen stehen gut, dass es in Zukunft mehr Menschen verstehen werden. Grundsätzlich bist du kein Engpass in deinem Team, sie befürchten jedoch, dass du es später werden könntest. Sie sollten sowieso etwas Zeit in die Ausbildung investieren.

Lesen Sie „ Der Wagen, die Amsel und der Saab“ . Es sollte bei dir ankommen.

Ich hatte in der Vergangenheit ähnliche Probleme; Ich habe einiges über Coping gelernt, aber wir haben beide mit Mopp und Eimer versucht, den Ausfluss eines Feuerwehrschlauchs zu reinigen.

Ich schlage hier nicht vor, dass Sie eine DSM-V-Diagnose für psychische Gesundheit verdienen, aber ich schlage vor, dass Sie gut beraten sein könnten, einen guten Berater zu finden und an nicht bedrohlichem Verhalten und sozialen Fähigkeiten zu arbeiten. Sie könnten auch Theory of Alien Minds lesen .