Nun, ich hasse es, Ihre Seifenblase zu zerplatzen, aber wenn dies das dritte Mal ist, dass dies passiert, schließt das fast aus, dass “es liegt nicht an Ihnen, sondern an ihnen”. Ihr Titel besagt, dass Sie gefeuert wurden, weil Sie “unentbehrlich” waren, aber abgesehen davon, dass das ein Oxymoron ist, ist es auch nicht das, was passiert ist. Sie wurden gefeuert, 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 , d.h. Code, der leicht verständlich ist, auch für Anfänger. Die Situationen, in denen Sie komplexen und straff 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 wie “ausgefallener” Code, der typischerweise übermäßig komplex ist, voller esoterischer Programmiertricks und es dauert ewig, ihn herauszufinden und zu debuggen. Das ist ein häufiger Fehler für klassisch ausgebildete Leute, die typischerweise ein böses Erwachen erleben werden, sobald sie in eine produktive Umgebung eintreten.

Das ist kein Witz, ich könnte es nicht ertragen, wenn dies ein viertes Mal passiert, es wirkt sich mental auf mich aus.

Diese Zeile ist wichtig, denn sie zeigt, dass Sie das Gefühl haben, dass es Zeit ist, sich zu ändern. Sie zeigt, dass Sie dies als ein 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 lösen, müssen Sie oft Ihre eigene Denkweise ändern. Es ist unmöglich für jemanden, das für Sie zu tun, also wird Ihr Wunsch, sich zu ändern, das Einzige sein, was die Veränderung bewirkt.

Vor einem gewissen Hintergrund war ich schon früher in ähnlichen “zu gut im Kodieren für meinen Job”-Situationen, wenn auch 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 missbraucht und gegen den exakten Wortlaut der C++-Spezifikationen verstieß, als viele Projekte, an denen ich arbeitete, noch veraltete und fehlerhafte Versionen von gcc verwendeten. Mein Ansatz war einfach, ihnen zu zeigen, wie erstaunlich diese Werkzeuge sind, und all die Probleme, die sie lösen können. Ich habe es geliebt, den Leuten kleine Programmiertipps zu erklären, und sie haben es größtenteils genossen.

Kommt Ihnen das bekannt vor?

“Ja, aber man sollte ein gutes Niveau haben, um [Miks Code] zu verstehen, 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 sich auf die Suche nach einem tollen Job machen, muss Ihr Chef trotzdem dafür sorgen, dass der Code beibehalten wird. Was Ihr Mitarbeiter gerade gesagt hat, war, dass er, wenn er Sie ersetzen muss, einen sehr guten Coder nötig hat, denn wer nicht so gut ist, wird nicht in der Lage sein, den Code zu warten. Das ist ein Risiko. Was ist, wenn sie keinen ausreichend guten Entwickler finden oder es sich nicht leisten können, sie ausreichend zu bezahlen?

Sie haben vielleicht etwas produziert, das Sie “guten Code” nennen würden, aber die Definition von “gutem Code” ist sehr stark vom Kontext abhängig. Was bei Google mit seiner hochmodernen Denkweise “guter Code” ist, kann für jemanden, der bei der FAA arbeitet und dem es in erster Linie um Zuverlässigkeit geht und nicht darum, auf dem neuesten Stand der Technik zu bleiben, sehr schlechter Code sein. Die Definition Ihres Chefs für “guten Code” schließt die Fähigkeit ein, ihn in allen möglichen Situationen aufrechtzuerhalten, auch ohne Sie. Wenn sich Ihre Mitarbeiter nicht wohl dabei fühlen, Ihren Code zu pflegen, dann sind Sie plötzlich eine Haftung für das Unternehmen, weil Sie Produkte herstellen, die sie nicht pflegen können, wenn Sie sich entscheiden, woanders hinzugehen.

Aus dieser Perspektive kann man argumentieren, dass Sie sie zwingen, Ihre Definition von “gutem Code” zu akzeptieren. Instinktiv mag dies als eine gute Sache erscheinen, aber es ist mit Schwierigkeiten behaftet, wie z.B. dieser risikobasierten Denkweise, an die Sie vielleicht nicht gedacht haben.

Wir haben eine Phrase, “das Pferd beim Schwanz aufzäumen”. Eine der vielen Bedeutungen, die damit verbunden sind, ist, den Inhalt, der Ihnen am wichtigsten ist (die Fähigkeit, Ihre fortgeschrittenen Techniken anzuwenden), über die Kräfte zu stellen, die ihn vorwärts ziehen sollten (das Verständnis Ihres Mitarbeiters für diese Techniken). Sie haben den Code in diesem fortgeschrittenen Stil geschrieben und dann die anderen Entwickler ermutigt, zu diesem Stil “aufzuschließen”. Das kann effektiv sein, aber wenn Ihnen etwas passiert, bevor sie “aufgeholt” haben, ist das Unternehmen plötzlich in Gefahr, weil niemand den Code warten kann.

Wie kann ich das in Zukunft vermeiden?

Dies zu beheben, kann furchtbar schwer sein, weil es bedeutet, das Problem auf eine andere Weise anzugehen, als Sie sich normalerweise wohl fühlen. Anstatt zuerst Code in diesem fortgeschrittenen Stil zu schreiben und dann Ihren Mitarbeitern beizubringen, wie man so denkt, sollten Sie das Ganze umdrehen. Bringen Sie Ihren Mitarbeitern bei, diesen Codierstil zu mögen, und fangen Sie dann an, Code in diesem Stil zu schreiben. Es mag rückwärts erscheinen, aber es ist viel stabiler. Aus der Sicht des Chefs ist es wenig bis gar kein Risiko, wenn das Team lernt, besser zu programmieren. Sobald sie besser codieren, ist der Stil, in dem Sie entwickeln wollen, plötzlich weniger riskant.

In der Zwischenzeit werden Sie Code schreiben müssen, 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 schwer zu sagen sein, wann es sicher ist, Code in dem Stil zu schreiben, in dem Sie schreiben wollen. Wenn es leicht zu erkennen wäre, hätten Sie es sicher schon herausgefunden! Eine mächtige Technik, die Sie einsetzen können, besteht darin, andere auf die fortgeschrittenen Codierstile drängen zu lassen, anstatt selbst darauf zu drängen. Es ist eine Sache, jemandem den Unterschied zwischen Vererbung und Komposition beizubringen. Es ist eine ganz andere Sache, sie so gut zu unterrichten, dass sie dafür plädieren, Ihre bestehende Codebasis so zu ändern, dass sie klarer erkennen kann, wann sie verwendet wird. Letzteres lässt Sie wirklich wissen, dass sie nicht nur das Konzept verstehen,

Ein Ideal für die Vermittlung solcher Konzepte ist es, nichts zu lehren. Lassen Sie die Schülerinnen und Schüler etwas entdecken, und dann weisen Sie ihnen eine Richtung, in die die Entdeckung gehen kann. Vielleicht entdeckt einer von ihnen etwas Ordentliches über Vererbung, und Sie können sie auf der Grundlage dessen, was sie entdeckt haben, auf das Gestaltungsmuster der Besucher hinweisen. Geben Sie ihnen nicht nur den Visitor, sondern geben Sie ihnen einen Orientierungssinn, damit sie den Visitor selbst finden können.

Es ist eine viel schwierigere Herangehensweise, und Sie werden sicherlich einen goldenen Mittelweg zwischen dieser und Ihrer derzeitigen Herangehensweise finden wollen, aber es kann sehr lohnend sein. Wichtiger für Ihre Antwort ist jedoch, dass sie für das Unternehmen ohne Risiko einen Mehrwert bieten kann. Wenn Sie für ein Unternehmen Wert schaffen und das Unternehmen nicht in Gefahr bringen, werden Sie praktisch nie jemals entlassen. Und in den wenigen Fällen, in denen Sie immer noch entlassen werden können, wird das Management einen Grund dafür angeben (z.B. einen Konjunkturabschwung oder eine Richtungsänderung des Unternehmens). Wenn Sie es sehr gut machen, werden Sie feststellen, dass das Management stattdessen anfangen wird, Ihren Weg zu gestalten, so wie Sie auch Ihre Mitarbeiter gestalten, und Sie werden eine merkwürdige Tendenz feststellen, dass Sie just die richtigen Fähigkeiten just dann gelernt haben, wenn sie sie am meisten brauchen.

Es gibt immer Gründe.

Ein früherer Arbeitgeber tat dies mit einem Mitarbeiter von mir. Sein Qualifikationsniveau lag weit über unseren Fähigkeiten. Deshalb wurde er entlassen.

Warum macht das Sinn?

1. er war der einzige, der seinen Code beibehalten konnte 2. Er war nicht kooperativ
2. Er hielt sich nicht an die Werksnormen
3. Er lieferte zwar mehr als nötig, aber das war keine gute Sache
4. Statt komplexer Lösungen wurden einfache Lösungen benötigt.

Es wird so oft gesagt, dass es fast ein Klischee ist, aber man muss “gut passen” für das Team.

Die Codierung ist nur ein Teil der Gleichung. Man muss sympathisch, kommunikativ, bis zu einem gewissen Grad bescheiden, bei Bedarf arrogant sein, sich an geschäftliche Standards halten, mit seinen Mitarbeitern zurechtkommen, ansprechbar sein und schnell helfen, wenn es nötig ist.

All diese Soft Skills sind wichtig, und nicht zu haben, wird Ihnen Schwierigkeiten bereiten.

Guter Code ist leicht zu verstehen, auch für schlechte Ingenieure. Ein Ratschlag, den ich oft erhalten habe, lautet: “Programmieren Sie so, als ob die Person, die Ihren Code pflegt, ein mittelmäßiger Programmierer und ein gefährlicher Psychopath ist, der weiß, wo Sie wohnen”

Und es stimmt. Zu cleveres Programmieren ist schlecht, denn die Wartung ist länger wenn man den Code nicht kennt. Bei der Wartung hat man oft überall Feuer, Tausende von Kunden werden blockiert, und eine cleverere und effizientere Lösung könnte den Wartungsmonteur sehr wohl länger festhalten als ein dummer skriptartiger Code voller Wiederholungen.

Natürlich ist total dummer Code auch schlecht. Es gibt eine feine Balance zwischen dumm und genial zu finden: effizient und trotzdem lesbar. Es ist mehr eine Kunst als eine Wissenschaft. Deshalb sind clevere Konzepte wie die Mehrfachvererbung wird normalerweise nicht empfohlen . Auch wenn sie rocken.

Man muss 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 zufälliger Qualität verlässt (manchmal haben sie Glück, manchmal nicht), und bei der jeder Berater eine Domäne von Millionen von LOC zu unterhalten hat, dann machen Sie es auf jeden Fall so einfach, dass ein Mittelständler es auf den ersten Blick versteht. Keine Hinweise, keine Mehrfachvererbung, keine cleveren Tricks, etc.

Es ist unwahrscheinlich, dass Sie gefeuert werden, weil Sie zu gut sind. Es ist viel wahrscheinlicher, dass es sich um ein Verhaltensproblem handelt oder dass der Chef Sie aus Gründen, die er Ihnen nicht nennen kann, einfach nicht mag, ohne Gründe für eine Klage zu schaffen. Es ist auch möglich, dass Sie der Teuerste sind und sie an VZÄ glauben (d.h. jeder Arbeiter ist gleich).

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

• Mentor der Juniorprogrammierer. Erzählen Sie ihnen 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 Leuten leicht zu pflegen ist.
• Setzen Sie sich für Best Practices ein, die die Produktivität steigern, im Gegensatz zu Frachtkult Best Practices, die auf dem Papier gut klingen, aber die Produktivität töten.

Unverzichtbare Mitarbeiter zu entlassen ist eigentlich eine vernünftige Managementstrategie. Wenn sich Ihr Unternehmen darauf verlässt, dass eine einzige Person ihre Arbeit fortsetzt, und niemand sonst im Unternehmen über ihr Wissen und/oder ihre Fähigkeiten verfügt, entsteht eine enorme Belastung: Was ist, wenn diese Person von einem Bus angefahren wird und stirbt (daher der Begriff “Bus-Faktor”) oder einfach beschließt, das Unternehmen für eine neue Herausforderung zu verlassen? Nun steckt Ihr Unternehmen in einer schrecklichen Situation fest, weil niemand den unentbehrlichen Mitarbeiter sofort ersetzen kann und Sie keine Kontrolle über den Zeitpunkt hatten!

Um diese Situation zu verhindern, hat das Unternehmen zwei Möglichkeiten. Entweder sie können versuchen, das Wissen zu verbreiten und/oder die Fähigkeiten der Mitarbeiter der unentbehrlichen Person zu erhöhen, oder sie können das Pflaster in einem Zug abziehen, indem sie die unentbehrliche Person zu einem Zeitpunkt ihrer Wahl entlassen und sich vom Verlust dieses Mitarbeiters erholen, wenn sie auf diesen Prozess vorbereitet sind.

Da es nicht immer praktisch ist, eine große Lücke im Wissen und vor allem in den Fähigkeiten zu schließen, kann es die logischere Wahl sein, sie zu entlassen.

Als Mitarbeiter sollten Sie immer versuchen, zu verhindern, dass Sie unentbehrlich werden. Teilen Sie Ihr Wissen mit Ihren Kollegen und sorgen Sie dafür, dass es Menschen gibt, die Ihre Arbeit erledigen können, wenn Sie nicht da sind. Vergewissern Sie sich, dass Ihre Praktiken für die Arbeitnehmer mit dem durchschnittlichen Qualifikationsniveau in Ihrem Unternehmen geeignet sind. Wenn Sie das Gefühl haben, dass das durchschnittliche Niveau zu niedrig ist, arbeiten Sie mit der Geschäftsleitung zusammen, um zu versuchen, dieses Niveau zu erhöhen. Stellen Sie sicher, dass alles, was Sie erstellen, gut dokumentiert ist und dass diese Dokumentation einen so hohen Standard hat, dass jeder Ihrer Kollegen sie zur Fortsetzung Ihrer Arbeit verwenden kann.

Wenn das einzige, was die drei Situationen gemeinsam haben, Sie sind, dann müssen Sie bedenken, dass etwas, was Sie tun, ein Problem ist.

Haben Sie mit Ihren ehemaligen Mitarbeitern gesprochen und sie gebeten, Sie zu kritisieren? Nicht Ihren Kodex, 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 dokumentieren, wie Sie sich in Besprechungen verhalten usw.

Haben Sie sich in die Lage Ihres Vorgesetzten versetzt? Haben Sie wirklich darüber nachgedacht, was sie zu tun haben, was ihre Aufgaben sind, was ihnen ein gutes Gefühl gibt, wenn sie das Licht im Büro ausschalten und nach Hause gehen? Es gibt viele, viele Beispiele, wo jemand erstaunlichen Code aus der Perspektive anderer Software-Ingenieure schreibt, aber die Firma scheitert.

Ich habe mir Ihr Profil angesehen, da steht: “Ihr Kodex sollte sauberer sein als Sie selbst”. Auch aus Ihren Kommentaren, dass Sie “viel Zeit damit verbracht haben, Konzepte zu erklären”, und “Kritik zu üben ist Teil meiner Arbeit als Ingenieur”… Ich denke, Sie sind sehr beratungsfreudig, und Ihr Rat wird von Ihren Teamkollegen einfach nicht geschätzt.

Das mag an dem liegen, was Sie sagen, oder an der Art, wie Sie es sagen, wahrscheinlich an beidem.

Das Schreiben von produktivem und wartbarem Code wird nicht dazu führen, 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, dass es sich hier um ein Problem der Persönlichkeitsbeeinträchtigung handelt.

Mein Rat an Sie lautet: 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 codieren sollen, folgen Sie den Anweisungen, arbeiten Sie gut mit anderen zusammen, schreiben Sie wartbaren Code. Und dann werden Sie nicht gefeuert.

Mit Interesse nehme ich auch diese aufschlussreiche Bemerkung Ihres Vorgesetzten zur Kenntnis:

“Aber ist es wirklich gut, wie er vorgibt?”

Was Ihnen dies sagt, ist, dass Ihr Vorgesetzter Ihnen nicht vertraut, Ihr Vorgesetzter denkt, Sie seien nicht authentisch und hält Sie für arrogant und/oder schätzt Ihre eigenen Fähigkeiten höher ein, als Sie tatsächlich haben. Beziehungen hängen vom Vertrauen ab, um zu überleben. Beachten Sie hier, dass Ihr Problem nicht ein 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.

Людей не часто увольняют за то, что они незаменимы почему людей увольняют ); Это нелепое утверждение. Статья, на которую вы ссылаетесь, ясно определяет, что “огонь” не обязательно означает отпустить их, а скорее сделать незаменимыми (переместить их, заставить не быть вовлеченными в конкретный проект и т.д…)

Хотя слишком квалифицированные люди иногда не наймут вас на работу - это также редко приводит к увольнению. Хороших сотрудников очень трудно найти; ни одна разумная компания не избавится от них, потому что они слишком хороши (если только вы не работаете только на идиота - тогда они делают вам одолжение).

People DO увольняются, потому что они БУДУТ незаменимы и лучше своих сверстников, и поэтому отказываются вносить изменения, которые должны быть сделаны с человеком в зеркале, чтобы хорошо функционировать в команде. Если вы строите мост с кучей туземцев и вытаскиваете ноутбук, в то время как остальные завязывают веревку - вы можете быть умнее или более образованным, но вы стали вредным для команды, и проблема в ВАС.

Если вы действительно так велики, как вы делаете себя, чтобы быть, вы были бы достаточно умны, чтобы настроить свои собственные действия, чтобы сделать наиболее продуктивные TEAM возможно против догматического навязывания собственной повестки дня (что вы, вероятно, делаете). Если бы вы это делали, у вас, скорее всего, была бы работа на очень долгое время.

Как тот, кто регулярно участвует в процессе найма, я возьму кого-то хорошего и привлекательного, а не того, кто велик и может заболеть раком в любой день.

Jedes Programm ist eine Kommunikation mit zwei Zuhörern: einem Compiler oder Interpreter, der es zur Ausführung bringt, und einigen Menschen, die es gelesen und verstanden haben. Möglicherweise kommunizieren Sie sehr gut mit dem Compiler und schreiben immer noch schlechten Code, weil er von den anderen beteiligten Personen nicht ohne weiteres verstanden wird.

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

Die Verwendung von etwas außerhalb dieses Satzes ist für den Arbeitgeber mit Kosten verbunden. Nehmen wir zum Beispiel an, Sie sind der einzige Programmierer in der Gruppe, der mit dem Framework X vertraut ist, und alle anderen kennen ein älteres Framework Y, das für einigen vorhandenen Code verwendet wird und fast so gut ist wie X.

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

Eine Technik, die Sie verwenden könnten, ist, Ihren Code von einigen der am wenigsten erfahrenen Personen überprüfen zu lassen, die in der Lage sein müssen, ihn zu lesen. Finden Sie heraus, worüber sie sich erkundigen müssen, und überlegen Sie, wie Sie diese Teile neu schreiben könnten, um ihnen klarer zu werden. Je mehr Sie das Nicht-Verstehen Ihres Codes als Fehler im Code und nicht in den Lesern betrachten, desto besser wird das Feedback sein, das Sie erhalten.

Ich habe darüber gelesen, dass Sie vom ersten Tag an für diese Behandlung bestimmt waren. Sie sagten, Sie wurden eingestellt, weil Sie Fähigkeiten besitzen, die sonst niemand im Unternehmen besitzt (TypeScript, Node). Und nun, da Sie sich die Mühe gemacht haben, eine elegante, fachmännisch ausgearbeitete, komplexe Lösung alleine zu erarbeiten, versteht niemand, was Sie getan haben, und deshalb werden Sie vom Management als eine Belastung angesehen.

Wenn all dies wahr ist, gibt es wirklich keine andere Möglichkeit, wie dies hätte ausfallen können.

Meiner Ansicht nach ist das Problem strukturell, nicht persönlich, und daher liegt die Schuld bei der Situation und dem Prozess, nicht bei der Person:

• Die Organisation stellte eine einzige Person mit völlig anderen Fähigkeiten als alle anderen und auf einem fortgeschrittenen Niveau dieser Fähigkeiten ein, um eine kritische Funktion auszuüben. Dies garantiert, dass wenn Sie gut arbeiten, Sie der einzige sind, der den Code versteht, der für die Mission der Organisation entscheidend ist. (Es ist völlig unvernünftig, von einer Ressource auf höherer Ebene zu erwarten, dass sie Code produziert, der für Leute, die die verwendete Sprache nicht beherrschen, sofort Sinn macht)
• Die Organisation hat Sie nicht regelmäßig dem Code-Review-Prozess unterzogen. Hätte sie es getan, 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 unter Verwendung eines anderen Tech-Stacks, ist 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, wäre, andere zu bitten, den Code außerhalb des Prozesses ständig zu überprüfen, wobei Sie möglicherweise den Vorwurf erheben könnten, die Zeit anderer zu verschwenden. Ein fehlender Code-Review-Prozess würde Sie also zum Scheitern verurteilen.

Ich habe in meinem Hintergrund ähnliche Erfahrungen gemacht. Ich wurde einmal eingestellt, um eine Kompetenzlücke zu füllen. Niemand sonst im Unternehmen verfügte über eine Fähigkeit, die sie plötzlich brauchten. Ich habe meine Arbeit gut gemacht, und nach einigen Monaten kam es zu Konflikten. Ich war der einzige, der mit bestimmten Komponenten der Anwendung arbeiten konnte. Ich wurde zu einem Engpass, als sich die Arbeit stapelte, die nur ich erledigen konnte. Eines Tages wurde ich ins Abseits gedrängt, als die Firma beschloss, alles, was ich produziert hatte, durch völlig neuen Code zu ersetzen, und das auf ihre Weise. Mein Stolz war damals verletzt, aber im Nachhinein betrachtet war es die richtige Entscheidung für das Unternehmen. Nach einer Weile dort war es Zeit für mich, weiterzumachen, und das habe ich getan.

Wenn Ihnen das bekannt vorkommt, ist es vielleicht an der Zeit für Sie, weiterzumachen. Vielleicht wird das Management Sie sogar an eine andere Stelle versetzen, wenn es Ihre Fähigkeiten weiterhin zu schätzen weiß. Oder wenn Sie es verkraften, können Sie vielleicht dabei helfen, alles, was Sie getan haben, in den Standardtechnologie-Stack des Unternehmens neu zu schreiben. Wenn das nicht möglich ist, gehen Sie einfach. So oder so, Ihr Code ist wahrscheinlich auf dem Weg in den Mülleimer. Das ist wahrscheinlich das Richtige für sie, wenn es sonst niemand versteht. Und sowieso ist es die natürliche Konsequenz ihrer Entscheidungen.

Stellen Sie sicher, dass andere in Ihrem Team bei Ihrem nächsten Job im Grunde die gleichen Fähigkeiten wie Sie anwenden, und vor allem, dass sie einen Code-Review-Prozess haben. Wenn sie Sie bitten, Ihren Code auf bestimmte Weise zu ändern, tun Sie es. Betrachten Sie den gelieferten Code erst dann als gut, wenn er die Codeprüfung bestanden hat und Ihre Kollegen dem Management (falls sie darum gebeten werden) sagen: Ja, der Code ist gut. Dann gibt es kein Problem. Es ist völlig in Ordnung, Fragen zu solchen Dingen in einem technischen Interview zu stellen; ich habe das schon viele Male getan. Hoffentlich gibt Ihnen dieser andere Entwickler, der Ihren Code studiert hat, eine gute Referenz.

Als Fußnote: Wenn Sie zumindest teilweise für die Umstände verantwortlich sind, unter denen Sie ganz allein arbeiten, ohne die Zustimmung der anderen Teammitglieder, dann verdienen Sie auch zumindest einen Teil der Verantwortung für das Ergebnis. (Haben Sie auf die Verwendung von TypeScript / Node gedrängt, als andere etwas anderes verwenden wollten? Haben Sie die neueste, coolste Bibliothek oder Technik verwendet, obwohl etwas Grundlegenderes genau das Richtige gewesen wäre? Ich war auch schon ein- oder zweimal schuldig dafür). Wenn ja, dann sollten Sie aus diesem Ergebnis eine Lehre ziehen. Aber wenn nicht, nehmen Sie diese Erfahrung mit erhobenem Kopf mit auf Ihre nächste Position.

In den meisten Antworten wurde Ihr Beitrag unter dem Gesichtspunkt behandelt, ob Ihr Code lesbar ist oder nicht oder so gut, wie Sie sagen. Aber diese Situation kann in allen Lebensbereichen auftreten und kommt auch vor. Ich habe einen Job auf dem Las Vegas Strip als 21-jähriger Händler und Floorman angenommen. Meine Techniken und meine Schnelligkeit waren dem Rest des Personals so weit voraus, dass die mir zugeteilten Beobachter nicht mithalten konnten. Mit anderen Worten, sie konnten meinen Entscheidungen nicht folgen. Da innerhalb von Minuten große Geldsummen abgewickelt wurden, fühlten sie sich oft verwirrt und meldeten mich bei ihrem Vorgesetzten mit der Behauptung, ich hätte einen Fehler gemacht. Mein Ego und vermutlich auch das Ihre sahen die Warnzeichen nicht, und in der Tat offenbarte ich meine Überlegenheit und goss sie sozusagen über mich aus. Ich wurde gekündigt und verlor eine extrem gut bezahlte Stelle.

Die Lektion ist einfach, man muss sich auf das Niveau der anderen herablassen. Wenn sie nur 15 Hände pro Stunde herausbekommen und Sie 100 herausbekommen, ist das kein anregendes Lob. Sie wecken Eifersucht und sogar Hass. Wenn Ihr Stolz das 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. Irgendwann habe ich mich auch in anderen Arbeitsbereichen niedergelassen, in denen ich mittelmäßig war und daher nicht auffiel. Ich hoffe, Sie können das zu Ihrem Vorteil regeln.

Habe mich entschlossen, meinen Kommentar in eine Antwort umzuwandeln:

Dokumentieren Sie Ihren Code sehr gut.

Richtige Code-Dokumentation macht aus schlechten Erfahrungen, bei denen ein Junior-Entwickler seinen Kopf stundenlang gegen eine unverständliche Wand schlägt, potentielle Lernerfahrungen.

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 Zeitaufwand der gesamten Codebasis um eine Größenordnung zu reduzieren. Die Tatsache, dass dies überhaupt möglich ist, überrascht viele Idioten. Sie halten es für einen unglaubwürdigen Vorschlag, und der einzige Weg, sie zu überzeugen, ist, es ihnen zu zeigen.

Aber das erfordert Finesse, Mut und Selbstbeherrschung. Man muss sich vor allen anderen auf drei Dinge konzentrieren: Man muss beweisen, dass man keine Bedrohung ist, man muss die Idioten klug aussehen lassen, und man darf niemals zulassen, dass ein einziger Idiot merkt, 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 es gibt keinen Platz für Stolz.

Obwohl ich diesen Ansatz nicht für jeden empfehlen kann, hat es für mich immer funktioniert, manchmal zu ignorieren, was mir feindliche Idioten sagen. Stattdessen finde ich Wege zu dem, was ich tun will, produziere in sehr kurzer Zeit die beste Software, für die viele von ihnen jemals den Code gesehen haben, und ich präsentiere sie so, dass ihre Chefs sie mit glühendem Lob belohnen. Auch wenn sie bei der Erstellung keine Rolle gespielt haben. Auch wenn sie sich aktiv dagegen gewehrt haben.

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

Es gibt viele kluge Leute , die denken, dass hochqualifizierte Entwickler unersetzlich sind, und deshalb wollen Sie sie haben. 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 auseinandersetzen und haben nicht die Möglichkeit, rein auf High Skills zu setzen. Sie haben auch nicht unbedingt Unrecht, die Probleme sind real, und die Vorteile eines qualitativ hochwertigen Codes, der über die Fähigkeiten der meisten Leute, die sie einstellen können, hinausgeht, werden stark geschmälert.

Wenn Sie auch nur annähernd so gut sind, wie Sie sagen, dass Sie es sind, dann sind Sie mit Ihrem Job unvereinbar. Es klingt, als sollten Sie sich anstrengen, 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 einige Stellen verloren haben, werden Sie für die Personalabteilung, die Personalvermittler und die Manager ziemlich schlecht dastehen. Hoffentlich können Sie sich zu einer Stelle vernetzen, indem Sie Entwickler mit ähnlichem Qualifikationsniveau treffen, die bezeugen können, dass das Problem wirklich darin besteht, dass Ihr Qualifikationsniveau zu hoch ist.

Abschließend muss ich hinzufügen, dass Sie Ihr Bestes tun sollten, um ehrlich zu bewerten, ob Ihr Qualifikationsniveau wirklich so hoch ist. Es klingt, als gäbe es dafür Beweise, aber die meisten Menschen glauben, dass sie besser sind als sie sind. Auch viele Entwickler durchlaufen 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 fehlt ihnen immer noch an Flexibilität. Manchmal ist es zum Beispiel am besten, sich für eine minderwertige Lösung zu entscheiden, von der Sie wissen, dass die Leute, die Sie haben, sie pflegen können, wenn Sie wissen, dass sie keine anspruchsvollere Lösung pflegen können und wahrscheinlich niemanden einstellen werden, der es kann.

Um speziell auf die Frage einzugehen:

Wie kann ich das in Zukunft vermeiden?

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

• Üben Sie sich darin, der Student und nicht 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 so eine Dokumentation machen würden, es würde allen zugute kommen, auf allen Ebenen eines Teams!

• Ein Team ist nicht ein Einzelner. Ihr Team wird gemeinsam wachsen und sich verbessern. Sie müssen 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-Sitzungen sind ein guter Anfang. Ich würde noch die N-Tage-Paarungsrotation hinzufügen. Das ist ein 1:1-Verhältnis, das Sie Ihren Teamkollegen geschenkt haben UND sie Ihnen geschenkt haben. In Ihrem Fall lehnen Sie sich an die Rolle des Navigators an, und lassen Sie Ihren Partner fahren. Üben Sie sich darin, den Code nicht zu schreiben, so seltsam das klingt.

• Helfen Sie freiwillig bei einem lokalen Meetup und Hack-a-thons. Das kann Sie dazu zwingen, Ihren Code zu destillieren, denn der Zweck ist die Zusammenarbeit und nicht der Aufbau eines fehlertoleranten Energieversorgungsnetzes, nicht wahr?

• Versuchen Sie in jeder dieser Übungen dieses Konzept: Führung 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 Einblick in Ihren Code zu bekommen. 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 wird Ihnen eine Überprüfung eine neue Idee geben.

• Finden Sie einen Ingenieur, der besser ist als Sie. Es bedeutet nicht, sich selbst zu verbessern, um der klügste Mann im Raum zu sein. Es gibt ein Zitat (mein Googeln ist gespalten zwischen Olgivy/Ford/Sorkin), das so umschreibt: “Man kann nicht mehr lernen, wenn man sich mit schlechtem Talent umgibt”.

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

Sie sagen, es handelt sich um 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 schreibe dies vor allem der Tatsache zu, dass die Manager in solchen Unternehmen oft nicht aus dem technischen Bereich kommen oder von der Entwicklung abgezogen wurden, weil sie nie so gut darin waren.

Es gibt auch einen historischen Aspekt des Verkaufs von Tools durch Anbieter, die den Bedarf an talentierten Entwicklern beseitigen sollen. Selbst wenn Ihr Team nicht eines dieser schrecklichen Dinge benutzt, besteht die Möglichkeit, dass das Management des Unternehmens in einer anti-intellektuellen Vorstellung von Entwicklungsteams indoktriniert wurde. Ich habe mir tatsächlich von einem Manager ins Gesicht sagen lassen, dass ich klug genug war, eine bestimmte Lösung zu bauen, aber dann wäre kein anderer in der Lage, sie zu warten, so dass wir etwas kaufen mussten (Regalware.) Also glaube ich, dass dies passieren kann.

Sie müssen sich vielleicht nach einer anderen Art von Unternehmen umsehen. Eines, das hoch qualifizierte Entwickler schätzt. Möglicherweise müssen Sie sich aber damit abfinden, dass Sie dort nicht der beste Entwickler sind. Wenn Sie ein aufstrebender Koch wären, würden Sie wahrscheinlich unglücklich sein, bei McDonald’s zu arbeiten. Die brauchen keine Köche. Sie brauchen Leute, die ein Rezept befolgen. Vielleicht sind Sie Chefkoch-Material und diese Firma (und andere wie sie) ist McDonald’s. Die Frage, die Sie sich stellen müssen, ist, warum Sie dies noch nicht getan haben.

Wie kann ich das in Zukunft vermeiden?

Arbeiten Sie mit niemandem zusammen, wenn Sie nicht hinreichend sicher sind, dass deren Kodierungsstandard mit Ihrem übereinstimmt. Das heißt, lehnen Sie jeden Job ab, wenn keiner der folgenden Punkte zutrifft:

• Sie stellen Ihnen während des Bewerbungsgesprächs Fragen zur Programmierung
• Sie haben Peer-Programmierübungen
• Sie bitten um ein Codebeispiel und sind damit einverstanden
• Sie können einen Teil des von ihnen produzierten Codes sehen

Wie kann ich das in der Gegenwart vermeiden?

Dies wurde durch andere Antworten abgedeckt. Als ich das erste Mal einen Praktikanten betreuen musste, habe ich fast den gesamten von ihm produzierten Code vernichtet. Ich war buchstäblich wütend, als ich sah, was begangen wurde (glücklicherweise hatte ich keinen 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 vielleicht zu schwer zu erklären sind (z.B. neue erweiterte Funktionen von Java 8), und erklären Sie diejenigen, die einfacher zu erklären sind (Vererbung).

Manchmal, wenn man mit anderen spricht, muss man es “stumm” stellen, damit man die Leute nicht beleidigt. Besonders, wenn Sie den anderen, mit denen Sie zusammenarbeiten, weit überlegen sind, sind diese wahrscheinlich beleidigt, wenn Sie über Tipps und Fakten sprechen, die sie wahrscheinlich wissen sollten, aber nicht wissen.

Ich würde sagen, kommentieren Sie Ihre Arbeit wirklich gut, damit die Leute, die sie überprüfen, sie verstehen können. Vielleicht müssen Sie in Ihren Kommentaren sogar “begründen”, warum Sie diese Kodierungsmethode einer anderen vorziehen. Vielleicht sind Sie der beste Codierer, aber wenn Sie in einem Team arbeiten, müssen Sie als Team arbeiten.

Wenn Teamarbeit bedeutet, mit einer Hand hinter dem Rücken zu arbeiten (damit meine ich, dass man ihrer Codierungspräferenz folgt), 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 hingehen, wo Sie Teil eines Teams sind, wird es Richtlinien geben, wie sie die Dinge kodieren wollen - und Sie müssen diese Richtlinien befolgen.

Wir können uns langfristig nicht 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, also können sie langfristig auf Sie zählen.

Ich glaube, ich werde mit Problemen konfrontiert, bei denen meine Fähigkeiten weiter genutzt werden, also denke ich, dass ich endlich einen Arbeitsplatz finde, an dem ich lange Zeit Freude habe

• Sie sind bereit, andere Teammitglieder zu schulen, um dem Team weiteren Nutzen zu bringen.

Ich habe bemerkt, dass der Code der anderen nicht wirklich auf dem neuesten Stand der neuesten Software-Entwicklungstechniken ist, das ist kein Problem, ich kann aufhören, diese Techniken ganz zu verwenden, aber es wäre vorteilhaft, wenn jeder anfangen würde, diese Techniken nach und nach zu verwenden, um die Leistung des Teams zu verbessern. Ich kann dabei helfen.

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

Kann ich etwas mehr Zeit haben, um die nächsten Funktionen fertigzustellen? Ich habe wirklich hart gearbeitet, um die Dinge richtig zu erledigen, das habe ich erreicht, aber ich fürchte, das kann nicht jeder 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 nicht, niemals.

Wenn sie Sie feuern werden, dann sind sie nicht wirklich von Ihnen abhängig. Jedenfalls verstehen mindestens 2 Personen im Team Ihre Arbeit: Sie und Ihr Kollege. Und die Chancen stehen gut, dass in Zukunft noch mehr Leute in der Lage sein werden, sie zu verstehen. Im Grunde genommen sind Sie kein Engpass in Ihrem Team, sie befürchten aber, dass Sie es später werden können. Sie sollten ohnehin etwas Zeit in die Ausbildung investieren.

Lesen Sie * [ Der Wagen, die Amsel und der Saab **.

Ich hatte in der Vergangenheit ähnliche Probleme; ich habe ein paar Dinge über die Bewältigung gelernt, aber wir haben beide mit Wischmopp und Eimer versucht, den Ausgang eines Feuerwehrschlauchs zu säubern.

Ich behaupte hier nicht, dass Sie eine DSM-V-Diagnose zur psychischen 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. Vielleicht lesen Sie auch * Theory of alien minds **.