Je déteste faire éclater votre bulle, mais si c'est la troisième fois que cela se produit, cela exclut presque le “ce n'est pas vous, c'est eux”. Votre titre dit que vous avez été licencié pour être “indispensable”, mais à part le fait que c'est un oxymore, ce n'est pas non plus ce qui s'est passé. Vous avez été licencié pour avoir écrit du code que vos collègues ne peuvent pas comprendre, ce qui est un problème de performance essentiel pour un programmeur.

Un bon code est un code lisible, c'est-à-dire un code qui est facilement compréhensible, même pour les novices. Les situations dans lesquelles vous avez besoin d'un code complexe et étroitement écrit, qui devrait être rédigé et maintenu par de véritables experts, sont très rares de nos jours et vous ne travailliez manifestement pas pour ce type d'entreprises. Ce que vous décrivez ressemble plus à du code “fantaisiste” qui est généralement trop complexe, plein d'astuces de programmation ésotériques et qui prend des années à comprendre et à déboguer. C'est un échec courant pour les gens qui ont reçu une formation classique et ils sont généralement confrontés à un réveil brutal une fois qu'ils entrent dans un environnement productif.

Ce n'est pas une blague, je ne pourrais pas supporter que cela se produise une quatrième fois, cela m'affecte mentalement.

Cette ligne est importante, car elle montre que vous pensez qu'il est temps de changer. Elle montre que vous reconnaissez qu'il s'agit d'un schéma et que vous aimeriez que ce schéma s'arrête. Ce désir est probablement la partie la plus importante de la solution. Régler ce genre de situation implique souvent de changer votre façon de penser. Il est impossible pour quelqu'un de faire cela à votre place, donc votre désir de changer sera la seule chose qui fera que le changement se produira.

Pour un certain contexte, j'ai déjà été dans des situations similaires de “trop bon codage pour mon travail”, mais jamais au degré que vous décrivez. Je pourrais guérir le cancer grâce à la métaprogrammation de modèles en C++, mais beaucoup de ceux avec qui je travaille sont à peine versés dans les bases de la conception orientée objet. J'ai écrit un code qui abusait de SFINAE et qui allait à l'encontre de la formulation exacte des spécifications du C++, alors que de nombreux projets sur lesquels je travaillais utilisaient encore des versions obsolètes et boguées de gcc. Mon approche consistait simplement à leur montrer à quel point ces outils sont étonnants, et tous les problèmes qu'ils pouvaient résoudre. J'aimais expliquer aux gens des petits trucs de programmation, et ils ont beaucoup apprécié.

Est-ce que cela vous semble familier ?

“Oui, mais il faut avoir un bon niveau pour comprendre [le code de Mik] car les composants sont intelligemment découplés”

Considérez cette déclaration d'un point de vue basé sur le risque. Votre patron doit continuer à faire avancer les choses, quoi qu'il arrive. Si vous partez à la recherche d'une opportunité de travail géniale, votre patron doit quand même s'assurer que le code est maintenu. Ce que votre collègue vient de dire, c'est que, s'il doit vous remplacer, il doit trouver un codeur très compétent, car toute personne qui n'est pas aussi bonne ne sera pas en mesure de le maintenir. C'est un risque. Et s'ils ne peuvent pas trouver un développeur suffisamment bon, ou s'ils n'ont pas les moyens de les payer suffisamment ?

Vous avez peut-être produit ce que vous appelleriez un “bon code”, mais la définition d'un “bon code” dépend très beaucoup du contexte. Ce qu'est un “bon code” chez Google, avec ses modes de pensée avant-gardistes, peut être un très mauvais code pour quelqu'un travaillant à la FAA, qui se préoccupe principalement de la fiabilité plutôt que de rester à la pointe du progrès. La définition de “bon code” donnée par votre patron inclut la capacité à le maintenir dans toutes sortes de situations, y compris sans vous. Si vos collègues ne sont pas à l'aise pour maintenir votre code, alors vous êtes soudainement une responsabilité envers l'entreprise, car vous fabriquez un produit qu'ils ne peuvent pas maintenir si vous décidez d'aller ailleurs.

De ce point de vue, on peut dire que vous les forcez à accepter votre définition d'un “bon code”. Instinctivement, cela peut sembler être une bonne chose, mais c'est lourd de difficultés, comme cette façon de penser basée sur le risque à laquelle vous n'avez peut-être pas pensé.

Nous avons une phrase, “mettre la charrue avant les bœufs”. L'une des nombreuses significations qui lui sont associées est de mettre le contenu qui vous tient le plus à cœur (pouvoir utiliser vos techniques avancées) au-dessus des forces qui devraient le faire avancer (la compréhension de ces techniques par votre collègue). Vous avez écrit le code dans ce style avancé, puis vous avez encouragé les autres développeurs à “rattraper” ce style. Cela peut être efficace, mais si quelque chose vous arrive avant qu'ils ne “rattrapent”, l'entreprise est soudainement en danger parce que personne ne peut maintenir le code.

Comment puis-je éviter cela à l'avenir ?

Corriger cela peut être une chose terriblement difficile à faire parce que cela implique d'aborder le problème d'une manière différente de celle qui vous convient habituellement. Au lieu de commencer par écrire du code dans ce style avancé, puis d'apprendre à vos collègues comment penser de cette façon, vous devriez le retourner. Apprenez à vos collègues à aimer ce style de codage, puis commencez à écrire le code dans ce style. Cela peut sembler à l'envers, mais c'est beaucoup plus stable. Du point de vue du patron, il y a peu ou pas de risque que l'équipe apprenne à mieux coder. Une fois qu'ils ont mieux codé, le style dans lequel vous voulez développer est soudainement moins risqué.

En attendant, vous devrez écrire du code qui, selon vos normes, est “moins bon”, mais c'est correct. Votre code n'est pas votre seul produit ici. Votre autre produit aide à enseigner aux autres développeurs, et sa valeur peut facilement dépasser celle de l'écriture d'un “code parfait”

Bien sûr, il peut être difficile de dire quand il est sûr d'écrire du code dans le style que vous voulez. Si c'était facile à dire, vous l'auriez certainement déjà compris ! Une technique puissante que vous pouvez utiliser est de laisser les autres pousser pour les styles de codage avancés, plutôt que de pousser vous-même. C'est une chose d'apprendre à quelqu'un la différence entre héritage et composition. C'est une toute autre chose de lui enseigner suffisamment bien pour qu'il préconise de modifier votre base de code existante afin d'être plus clair dans son utilisation. Ce dernier cas vous permet de savoir que non seulement ils comprennent le concept, mais l'embrasser vraiment.

Un idéal pour enseigner de tels concepts est de ne rien enseigner. Laissez les étudiants découvrir quelque chose, et ensuite vous leur indiquez la direction que peut prendre la découverte. Peut-être que l'un d'entre eux découvre quelque chose d'intéressant sur l'héritage et que vous pouvez l'orienter vers le modèle de conception Visitor en fonction de ce qu'il a découvert. Ne vous contentez pas de leur donner Visitor, mais donnez-leur une direction pour qu'ils puissent aller chercher Visitor eux-mêmes.

C'est une approche beaucoup plus difficile, et vous voudrez certainement trouver un juste milieu entre cela et votre approche actuelle, mais elle peut être très enrichissante. Plus important encore pour votre réponse, elle peut apporter de la valeur à l'entreprise sans risque. Si vous apportez de la valeur à une entreprise, sans la mettre en danger, vous ne serez pratiquement jamais licencié. Et dans les rares cas où vous pouvez encore être licencié, la direction vous en donnera la raison (comme un ralentissement de l'économie ou un changement d'orientation de l'entreprise). Si vous le faites très bien, vous constaterez que la direction commencera à façonner votre parcours, tout comme vous façonnez vos collègues, et vous constaterez une curieuse tendance à avoir appris juste la bonne compétence juste au moment où ils en ont le plus besoin.

Il y a toujours des raisons.

Un ancien employeur a fait cela avec un de mes collègues. Son niveau de compétence était bien au-delà de nos compétences. Il a donc été licencié.

Pourquoi cela a-t-il un sens ?

1. Il était le seul à pouvoir maintenir son code
2. Il n'était pas collaborateur
3. Il n'a pas suivi les normes du magasin
4. Il livrait plus que nécessaire, mais ce n'était pas une bonne chose
5. Il fallait des solutions simples au lieu de solutions complexes.

On dit si souvent que c'est presque un cliché, mais il faut être “bien adapté” à l'équipe.

Le codage n'est qu'une partie de l'équation. Vous devez être aimable, communicatif, humble dans une certaine mesure, arrogant lorsque c'est nécessaire, respecter les normes de l'atelier, vous entendre avec vos collègues, être accessible et prompt à aider lorsque c'est nécessaire.

Toutes ces compétences sont importantes, et ne pas les avoir vous causera des problèmes.

Un bon code est facile à comprendre, même pour les mauvais ingénieurs. Un conseil que je reçois souvent est “programmez comme si la personne qui va maintenir votre code était un programmeur médiocre, et un dangereux psychopathe qui sait où vous vivez”.

Et c'est vrai. Une programmation trop intelligente est mauvaise, parce que la maintenance est plus longue quand vous ne connaissez pas le code. En maintenance, vous avez souvent le feu partout, des milliers de clients bloqués, et une solution plus intelligente et plus efficace pourrait très bien maintenir le mainteneur bloqué plus longtemps qu'un code stupide de type script plein de répétitions.

Bien sûr, un code totalement stupide est mauvais aussi. Il y a un équilibre délicat à trouver entre la stupidité et le génie : efficace, et toujours lisible. C'est plus un art qu'une science. C'est pourquoi les concepts intelligents tels que l'héritage multiple sont généralement déconseillés . Même s'ils sont très importants.

Il faut tenir compte du contexte. Si vous travaillez dans une petite entreprise de pointe qui n'engage que les meilleurs, vous pouvez probablement vous permettre des choses exotiques et brillantes. Si vous travaillez pour une banque française qui ne fait appel qu'à des consultants de qualité, errrm, aléatoire (parfois ils ont de la chance, parfois non), et où chaque consultant a un domaine de millions de LOC à maintenir, alors par tous les moyens faites en sorte que ce soit assez simple pour qu'un médiocre puisse le comprendre au premier abord. Pas de pointage, pas d'héritage multiple, pas d'astuces, etc…

Il est peu probable que vous soyez renvoyé parce que vous êtes trop bon. Je suppose que ce n'est qu'une excuse.

Il est beaucoup plus probable que ce soit un problème de comportement, ou que le patron ne vous aime pas pour des raisons qu'il ne peut pas vous dire sans créer un motif de poursuite. Il est également possible que vous soyez le plus cher et qu'ils croient aux ETP (c'est-à-dire que chaque travailleur est le même).

Si vous êtes vraiment si bon, vous pouvez vous rendre indispensable d'une bonne manière :

• Mentorisez les jeunes programmeurs. Exposez les avantages et les inconvénients des différentes approches et laissez-les faire leurs erreurs au lieu de leur dire quelle approche adopter.
• Écrivez un bon code facile à maintenir par d'autres personnes.
• Préconisez les meilleures pratiques de manière à accroître la productivité, par opposition aux meilleures pratiques du cargo cult , qui semblent bonnes sur le papier mais qui tuent la productivité.

Le licenciement de personnes indispensables est en fait une stratégie de gestion saine. Lorsque votre entreprise repose sur une seule personne qui continue à faire son travail et que personne d'autre dans l'entreprise ne possède ses connaissances et/ou ses capacités, cela crée un énorme handicap : que se passe-t-il si cette personne est heurtée par un bus et meurt (d'où le terme de “facteur bus”) ou si elle choisit simplement de quitter l'entreprise pour relever un nouveau défi ? Votre entreprise est alors coincée dans une situation terrible car personne ne peut remplacer immédiatement l'employé indispensable et vous n'avez aucun contrôle sur le timing !

Pour éviter cette situation, l'entreprise a deux options. Soit elle peut tenter de diffuser les connaissances et/ou d'accroître la capacité des collègues de la personne indispensable, soit elle peut réussir à mettre fin au pansement en une seule fois en licenciant la personne indispensable au moment où elle le souhaite et se remettre de la perte de ce travailleur lorsqu'elle est prête pour ce processus.

Comme il n'est pas toujours pratique de combler un grand écart de connaissances et surtout de capacités, les licencier peut être le choix le plus logique.

En tant qu'employé, vous devez toujours tenter d'empêcher de devenir indispensable. Partagez vos connaissances avec vos collègues et assurez-vous qu'il y a des personnes qui peuvent faire votre travail quand vous n'êtes pas là. Assurez-vous que vos pratiques sont adaptées aux travailleurs ayant le niveau de compétence moyen de votre entreprise. Si vous estimez que ce niveau moyen est trop bas, travaillez avec la direction pour essayer de l'augmenter. Assurez-vous que tout ce que vous créez est bien documenté et que cette documentation est d'un niveau suffisamment élevé pour que n'importe lequel de vos collègues puisse l'utiliser pour poursuivre votre travail.

Si la seule chose en commun entre les trois situations est vous, alors vous devez considérer que quelque chose que vous faites est un problème.

Avez-vous parlé avec vos anciens collègues et leur avez-vous demandé de vous critiquer ? Pas votre code, mais votre comportement au bureau. La façon dont vous communiquez avec vos collègues, la façon dont vous communiquez avec votre patron, la façon dont vous faites de la documentation, la façon dont vous vous comportez dans les réunions, etc.

Vous êtes-vous mis à la place de votre superviseur ? Avez-vous vraiment réfléchi à ce qu'ils doivent faire, à leurs responsabilités, à ce qui les fait se sentir bien lorsqu'ils éteignent la lumière du bureau et rentrent chez eux ? Il existe de très nombreux exemples où quelqu'un écrit un code étonnant du point de vue d'autres ingénieurs en logiciel, mais où l'entreprise échoue.

J'ai regardé votre profil, il indique que “votre code doit être plus propre que vous”. Et d'après vos commentaires, vous avez “passé beaucoup de temps à expliquer des concepts”, et “critiquer fait partie de mon travail d'ingénieur”… Je pense que vous aimez donner des conseils et que vos conseils ne sont tout simplement pas appréciés par vos coéquipiers.

Cela peut être dû à ce que vous dites, ou à la façon dont vous le dites, probablement un peu des deux.

Écrire un code productif et maintenable ne vous fera pas renvoyer. Vous serez licencié si vous ne pouvez pas vous entendre avec l'équipe. C'est votre problème, et non (comme vous l'imaginez) votre code est trop bon. Votre code est peut-être très bon, mais il est BEAUCOUP plus probable qu'il s'agisse d'un problème de conflit de personnalité.

Mon conseil est de ne pas être la queue qui essaie de remuer le chien. Gardez la tête basse, arrêtez de dire aux gens comment coder, suivez les instructions, travaillez bien avec les autres, écrivez un code qui peut être maintenu. Et vous ne serez pas licencié.

Je note également avec intérêt ce commentaire éloquent de votre manager :

“Mais est-ce vraiment bien comme il le prétend ?”

Ce que cela vous dit, c'est que votre manager ne vous fait pas confiance, votre manager pense que vous êtes inauthentique et pense que vous êtes arrogant et/ou que vous avez une plus grande estime de vos propres capacités que vous n'en avez en réalité. Les relations dépendent de la confiance pour survivre. Notez ici que votre problème n'est pas un problème technique. Votre problème a très peu à voir avec la qualité de votre code. Ce que vous avez, c'est un problème de relation avec vos collègues et votre manager.

Les gens ne sont pas souvent licenciés pour être indispensables pourquoi les gens sont licenciés ) ; C'est une affirmation ridicule. L'article auquel vous faites référence qualifie clairement le fait que “virer” ne signifie pas nécessairement les laisser partir, mais plutôt les rendre non indispensables (en les déplaçant, en les forçant à ne pas participer à un projet particulier, etc.)

Bien que le fait d'être surqualifié ne vous permette parfois pas d'être embauché, il vous fait aussi rarement virer. Les bons employés sont très difficiles à trouver ; aucune entreprise raisonnable ne va s'en débarrasser parce qu'ils sont trop bons (à moins que vous ne travailliez que pour un crétin - alors ils vous font une faveur).

Les gens se font virer parce qu'ils PENSENT qu'ils sont indispensables et meilleurs que leurs pairs et refusent donc d'apporter les changements qui doivent être apportés à l'homme dans le miroir pour bien fonctionner en équipe. Si vous construisez un pont avec un groupe d'indigènes et que vous sortez un ordinateur portable pendant que les autres attachent la corde, vous êtes peut-être plus intelligent ou plus instruit, mais vous êtes devenu un détriment pour l'équipe et le problème, c'est VOUS. Si vous êtes vraiment aussi génial que vous le prétendez, vous seriez assez intelligent pour ajuster vos propres actions afin de rendre l'ÉQUIPE la plus productive possible, plutôt que de pousser dogmatiquement votre propre agenda (ce que vous faites probablement). Si vous faisiez cela, vous auriez probablement un emploi pendant très longtemps.

En tant que personne régulièrement impliquée dans le processus d'embauche, je préfère une personne qui est bonne et sympathique à une personne qui est géniale et qui risque d'avoir un cancer n'importe quand.

Chaque programme est une communication avec deux publics : un compilateur ou un interprète qui le fera exécuter, et quelques humains qui l'ont lu et compris. Vous pouvez communiquer extrêmement bien avec le compilateur, et écrire un mauvais code parce qu'il ne peut pas être facilement compris par les autres humains impliqués.

En général, une équipe de programmation dispose d'un ensemble de langages, de cadres, de techniques, etc. qui sont connus de tous les membres de l'équipe. Les nouveaux employés qui manquent certains de ces éléments les absorbent rapidement parce que n'importe qui dans l'équipe peut les expliquer.

L'utilisation de quelque chose en dehors de cet ensemble entraîne un coût pour l'employeur. Par exemple, supposons que vous soyez le seul programmeur du groupe à connaître le framework X, et que tous les autres connaissent un ancien framework Y qui est utilisé pour un certain code existant et qui est presque aussi bon que X.

Utiliser le framework X serait une erreur, à moins qu'il ne soit tellement meilleur que Y que la direction convienne que les gains techniques de son utilisation sont suffisants pour justifier l'effort de formation visant à familiariser tout le monde avec X.

Une technique que vous pourriez utiliser consiste à faire réviser votre code par certaines des personnes les moins expérimentées qui doivent être capables de le lire. Voyez ce qu'ils doivent demander et réfléchissez à la manière dont vous pourriez réécrire ces morceaux pour qu'ils soient plus clairs. Plus vous considérerez le fait de ne pas comprendre votre code comme un défaut du code, et non des lecteurs, plus vous obtiendrez de bons résultats.

D'après ce que j'ai lu, vous avez été destiné à ce traitement dès le premier jour de travail. Vous avez dit que vous avez été engagé parce que vous avez des compétences que personne d'autre dans l'organisation n'a (TypeScript, Node). Et maintenant que vous avez travaillé dur pour produire une solution complexe, élégante et élaborée par des experts tout seul, personne ne comprend ce que vous avez fait, et vous êtes donc considéré comme un handicap par la direction.

Si tout cela est vrai, il n'y a vraiment pas d'autre moyen que cela ait pu se produire.

A mon avis, le problème est structurel, et non personnel, et donc la faute incombe à la situation et au processus, et non à la personne :

• L'organisation a engagé une seule personne avec un ensemble de compétences complètement différent de celui de tout le monde, et à un niveau avancé de ces compétences, pour remplir une fonction critique. Cela garantit que, si vous êtes performant, vous serez le seul à comprendre le code qui est essentiel à la mission de l'organisation. (Il est tout à fait déraisonnable d'attendre d'une ressource de haut niveau qu'elle produise un code qui ait instantanément un sens pour des personnes qui ne connaissent pas le langage utilisé)
• L'organisation ne vous a pas soumis régulièrement au processus de révision du code. S'ils l'avaient fait, votre code aurait été rejeté jusqu'à ce que vous le mettiez en conformité avec leurs normes de lisibilité. Comme vous êtes le seul contributeur au code, avec votre propre style et en utilisant une pile technologique différente, il est pratiquement garanti qu'avec le temps, le code deviendra de moins en moins compréhensible pour les autres. La seule façon pour vous d'éviter cela serait de demander à d'autres de réviser le code en dehors du processus, constamment, en vous faisant éventuellement accuser de faire perdre du temps aux autres. L'absence de processus de révision du code vous conduirait donc à l'échec.

J'ai vécu des expériences similaires dans mon passé. J'ai été engagé une fois pour combler un manque de compétences. Personne d'autre dans l'entreprise n'avait une compétence dont il avait soudainement besoin. J'ai bien fait mon travail et après quelques mois, le conflit a commencé. J'étais le seul à pouvoir travailler avec certains éléments de la candidature. Je suis devenu un goulot d'étranglement à mesure que s'accumulait le travail que moi seul pouvais faire. Un jour, j'ai été mis sur la touche car l'entreprise a décidé de remplacer tout ce que j'avais produit par un code entièrement nouveau, fait à sa façon. Ma fierté a été blessée à l'époque, mais rétrospectivement, c'était la bonne décision pour l'entreprise. Au bout d'un certain temps, il était temps pour moi de passer à autre chose, et je l'ai fait.

Si cela vous semble familier, peut-être est-il temps pour vous de passer à autre chose. Peut-être même que la direction vous réaffectera à autre chose si elle continue à valoriser vos compétences. Ou si vous pouvez le supporter, peut-être pouvez-vous aider à réécrire tout ce que vous avez fait dans la pile technologique standard de l'entreprise. Si ce n'est pas possible, partez. Quoi qu'il en soit, votre code est probablement en route vers la poubelle. C'est probablement la bonne chose à faire pour eux, si personne d'autre ne le comprend. Et de toute façon, c'est la conséquence naturelle de leurs choix.

Assurez-vous que dans votre prochain emploi, les autres membres de votre équipe appliquent fondamentalement les mêmes compétences que vous, et surtout qu'ils ont un processus de révision du code. Lorsqu'ils vous demandent de modifier votre code d'une certaine manière, faites-le. Ne considérez pas que le code a été délivré tant qu'il n'a pas été révisé et que vos pairs ne diront pas à la direction (si on le leur demande) que oui, le code est bon. Il n'y a alors aucun problème. Il est tout à fait normal de poser des questions sur ce genre de choses dans le cadre d'un entretien technique ; je l'ai fait tant de fois. J'espère que l'autre développeur qui a étudié votre code vous donnera une bonne référence.

En note de bas de page, si vous êtes au moins partiellement responsable des circonstances dans lesquelles vous travaillez tout seul, sans l'adhésion des autres membres de l'équipe, alors vous méritez au moins une partie de la responsabilité du résultat aussi. (Avez-vous insisté pour utiliser TypeScript / Node alors que d'autres voulaient utiliser autre chose ? Avez-vous utilisé la bibliothèque ou la technique la plus récente et la plus cool, même si quelque chose de plus basique aurait fait l'affaire ? J'ai été coupable de cela une ou deux fois également). Si c'est le cas, assurez-vous de tirer une leçon de ce résultat. Sinon, prenez cette expérience à votre prochain poste la tête haute.

La plupart des réponses traitaient votre poste du point de vue de la lisibilité ou non de votre code ou de sa qualité. Mais cette situation peut se produire, et se produit, dans tous les milieux. J'ai accepté un emploi sur le Strip de Las Vegas en tant que croupier et floorman du 21. Mes techniques et ma vitesse étaient tellement en avance sur le reste de leur personnel que les personnes chargées de me surveiller ne pouvaient pas suivre. En d'autres termes, ils ne pouvaient pas suivre mes décisions. Comme de grosses sommes d'argent étaient transigées en quelques minutes, ils se sentaient souvent désorientés et me dénonçaient à leur supérieur en prétendant que j'avais fait une erreur. Mon ego et je pense que le vôtre n'ont pas vu les signes avant-coureurs et j'ai même révélé ma supériorité, en la déversant pour ainsi dire. J'ai été licencié et j'ai perdu un poste extrêmement bien rémunéré.

La leçon est simple, il faut se mettre au niveau des autres. S'ils ne reçoivent que 15 mains par heure et que vous en recevez 100, vous n'êtes pas digne d'éloges. Vous inspirez la jalousie et même la haine. Si votre fierté ne peut pas le faire, vous devez trouver un autre moyen de gagner votre vie, car tous les endroits sont essentiellement les mêmes. Les gens sont des gens, vous ne pouvez pas les changer. J'ai fini par m'installer dans d'autres secteurs d'activité où j'étais également médiocre et où je ne me suis donc pas distingué. J'espère que vous pourrez régler ce problème à votre avantage.

J'ai décidé de transformer mon commentaire en une réponse :

Documentez très bien votre code.

Une bonne documentation du code transforme les mauvaises expériences où un jeune développeur se cogne la tête contre un mur incompréhensible pendant des heures en expériences d'apprentissage potentielles.

Il est possible que vous ne soyez tout simplement pas aussi bon que vous le pensez, mais par souci de civilité, je supposerai que vous savez écrire la bonne quantité de code complexe afin de réduire d'un ordre de grandeur la complexité et les délais de l'ensemble de la base de code. Le fait que cela soit même possible prend beaucoup d'idiots par surprise. Ils trouvent que c'est une proposition incrédule, et la seule façon de les convaincre est de leur montrer.

Mais cela demande de la finesse, du courage et de la maîtrise de soi. Vous devez vous concentrer sur trois choses avant toutes les autres : prouver que vous n'êtes pas une menace, faire passer les idiots pour intelligents, et ne jamais laisser un seul idiot se rendre compte que vous savez qu'il est idiot. Si vous ne pouvez pas vous résoudre à faire ces trois choses, vous échouerez et ce sera votre faute. Le pragmatisme est indispensable et il n'y a pas de place pour l'orgueil.

Bien que je ne puisse pas recommander cette approche à tout le monde, ce qui a toujours fonctionné pour moi, c'est d'ignorer parfois ce que des idiots hostiles me disent de faire. Au lieu de cela, je trouve des moyens de faire ce que je veux, je produis le meilleur logiciel dont beaucoup ont vu le code en très peu de temps, et je le présente de telle manière que leurs patrons les récompensent par des éloges élogieux. Même s'ils n'ont joué aucun rôle dans la création de ce logiciel. Même s'ils s'y sont activement opposés.

Est-ce bien cela ? Ne devrais-je pas être pleinement récompensé pour mon travail ? Devrais-je vraiment danser autour des sentiments de chacun ? Pas pertinent. C'est la réalité. Si je ne m'y adapte pas, alors je suis l'idiot.

Il y a beaucoup de personnes intelligentes qui pensent que les développeurs hautement qualifiés sont irremplaçables et c'est pourquoi vous les voulez. Mais vous avez vu les autres réponses à votre question - la plupart des managers ne veulent pas s'occuper des problèmes d'une équipe aux niveaux de compétences très variables, et n'ont pas la possibilité d'opter pour des compétences purement élevées. Ils n'ont pas forcément tort non plus, les problèmes sont réels et les avantages d'un code de haute qualité qui dépasse les capacités de la plupart des personnes qu'ils sont capables d'embaucher sont considérablement réduits.

Si vous êtes aussi bon que vous le dites, vous êtes mal adapté à votre travail. Il semble que vous devriez vous efforcer de travailler dans un endroit où vous pouvez apprendre de vos collègues et où ceux-ci peuvent comprendre votre code.

Si vous avez perdu quelques emplois à cause de cela, vous allez avoir mauvaise réputation auprès des RH, des recruteurs et des responsables. Il est à espérer que vous pourrez vous intégrer dans un emploi en rencontrant des développeurs de niveau de compétence similaire qui peuvent attester que le problème est vraiment que votre niveau de compétence est trop élevé.

Enfin, je dois ajouter que vous devez faire de votre mieux pour évaluer honnêtement si votre niveau de compétence est vraiment si élevé. Il semble qu'il y ait des preuves que c'est le cas, mais la plupart des gens pensent qu'ils sont meilleurs qu'ils ne le sont. De plus, de nombreux développeurs passent par un stade où ils deviennent très bons dans une approche, mais ne rassemblent pas encore toujours tout en une solution globalement optimale, et manquent toujours de flexibilité. Par exemple, il est parfois préférable d'opter pour une solution inférieure dont vous savez que les personnes dont vous disposez peuvent assurer la maintenance, si vous savez qu'elles ne peuvent pas assurer la maintenance d'une solution plus sophistiquée et qu'elles ne sont pas susceptibles d'engager quelqu'un d'autre qui le peut.

Pour répondre spécifiquement à la question,

Comment puis-je éviter cela à l'avenir ?

• Trouvez un chapitre local de Toastmasters, participez activement et gagnez les récompenses. Quelque chose qui semble si évident comme un retour d'information, sera, espérons-le, apprécié et aiguisé en une de vos compétences les plus appréciées.

• Pratiquez-vous à être l'étudiant plutôt que l'expert. Avez-vous vu ce Jon Skeet parler des bases ? Pouvez-vous imaginer à quel point il est possible de mieux comprendre si chacun d'entre nous faisait de la documentation comme celle-ci, cela profiterait à tous, à tous les niveaux d'une équipe !

• Une équipe n'est pas un individu. Votre équipe va grandir et s'améliorer collectivement. Vous devez l'aider. Ce n'est pas une équipe si chaque membre est une cellule qui va dans des directions différentes (par exemple, vous plus haut, et le membre le plus récent qui stagne). Une réunion de deux heures est un bon début. J'ajouterais à cela la rotation des paires de N jours. C'est une fois sur deux que vous donnez à vos coéquipiers ET qu'ils donnent à vous. Dans votre cas, penchez-vous vers le rôle de navigateur, et laissez votre partenaire conduire. Entraînez-vous à ne pas écrire le code, aussi bizarre que cela puisse paraître.

• Bénévole à une rencontre locale et à des “Hack-a-thons”. Cela peut vous obliger à distiller votre code parce que le but est de collaborer, et non pas de construire un réseau d'énergie tolérant aux pannes, n'est-ce pas ?

• Dans chacun de ces exercices, essayez ce concept : le leadership par le service. Comment pouvez-vous faire une tâche ou accomplir quelque chose pour aider les besoins d'un autre membre de l'équipe ?

• Comme indiqué, contribuez à des projets open source pour avoir plus d'angles d'attaque sur votre code. Ils peuvent confirmer que vous êtes brillant, mais ils peuvent aussi renforcer les suggestions que vous entendez de votre patron actuel. Au mieux, un examen vous donnera une nouvelle idée.

• Trouvez un ingénieur qui est meilleur que vous. Ce n'est pas s'améliorer que d'être le gars le plus intelligent de la pièce. Il y a une citation (ma recherche sur Google est partagée entre Olgivy/Ford/Sorkin) paraphrasant “Vous ne pouvez pas en apprendre plus si vous vous entourez de mauvais talents”.

Je vais supposer que votre description de la situation est telle que vous la dites. Je ne peux pas dire que j'ai eu cette expérience exacte, mais certains aspects de la situation me sont familiers.

Vous dites que c'est une “grande” entreprise. Je ne sais pas comment c'est en France, mais souvent les grandes entreprises ne valorisent pas les compétences des développeurs internes, surtout si elles ne sont pas axées sur la technologie. J'attribue cela principalement au fait que les dirigeants de ces entreprises n'ont souvent pas de formation technique ou se sont éloignés du développement parce qu'ils n'ont jamais été très bons dans ce domaine.

Il y a aussi un aspect historique des vendeurs d'outils qui sont censés supprimer le besoin de développeurs talentueux. Même si votre équipe n'utilise pas l'une de ces horribles choses, il y a une chance que la direction de l'entreprise ait été endoctrinée dans une notion anti-intellectuelle des équipes de développement. En fait, un directeur m'a dit en face que j'étais assez intelligent pour construire une solution donnée, mais que personne d'autre ne serait capable de la maintenir et qu'il fallait donc acheter quelque chose (shelfware.) Je crois donc que cela peut arriver.

Vous devrez peut-être chercher un autre type de société. Une entreprise qui valorise les développeurs hautement qualifiés. Mais vous risquez de ne pas être le meilleur développeur. Si vous étiez un aspirant chef cuisinier, vous seriez probablement malheureux de travailler chez McDonald’s. Ils n'ont pas besoin de chefs. Ils ont besoin de gens qui suivent une recette. Vous pouvez être un chef cuisinier et cette entreprise (et d'autres comme elle) est McDonald’s. La question que vous devez vous poser est de savoir pourquoi vous n'avez pas encore fait cela.

Comment puis-je éviter cela à l'avenir ?

Ne travaillez avec personne à moins que vous ne soyez raisonnablement assuré que leur norme de codage correspond à la vôtre. Ce qui signifie que vous devez refuser tout emploi si aucune des personnes suivantes ne pose sa candidature :

• Ils vous posent des questions de programmation pendant leur entretien
• Ils ont des exercices de programmation par les pairs
• Ils demandent un échantillon de code et sont d'accord avec celui-ci
• Vous pouvez voir une partie du code qu'ils ont produit

Comment puis-je éviter cela dans le présent ?

Cela a été couvert par d'autres réponses.

Si vous êtes juste si meilleur que cela, rejoignez leur niveau et apprenez-leur lentement à devenir de meilleurs programmeurs. La première fois que j'ai eu à gérer un stagiaire, j'ai presque effacé tout le code qu'il a produit. J'étais littéralement furieux quand j'ai vu ce qui a été commis (heureusement je n'avais pas de témoin :P )_.

Vous devez encourager la programmation par les pairs, les révisions de code. Asseyez-vous avec un autre programmeur et essayez de coder ensemble pendant 2 ou 3 heures. Laissez tomber les concepts qui peuvent être trop difficiles à expliquer (nouvelles fonctionnalités avancées de Java 8 par exemple), et expliquez ceux qui sont plus faciles (héritage).

Parfois, lorsque vous parlez avec d'autres personnes, vous devez “faire la sourde oreille” pour ne pas offenser les gens. Surtout si vous êtes bien au-dessus des autres avec qui vous travaillez, ils sont probablement offensés lorsque vous parlez de conseils et de faits qu'ils devraient probablement connaître, mais qu'ils n'ont pas fait.

Je dirais de bien commenter votre travail, afin que les personnes qui le vérifient puissent le comprendre. Vous pourriez même avoir besoin de “justifier” pourquoi vous choisissez cette méthode de codage plutôt qu'une autre à l'intérieur de vos commentaires. Vous êtes peut-être le meilleur codeur, mais si vous faites partie d'une équipe, vous devez travailler en équipe.

Si travailler en équipe signifie travailler avec une main derrière le dos (c'est-à-dire suivre sa préférence de codage), alors faites-le. Au moins, ils peuvent le lire, le comprendre, et l'équipe elle-même est mieux lotie (même si cela signifie que vous criez à l'intérieur).

Presque partout où vous allez, où vous faites partie d'une équipe, il y aura des directives sur la façon dont ils veulent que les choses soient codées - et vous devez suivre ces directives.

Nous ne pouvons pas dépendre de lui à long terme

C'est le problème majeur. Ils ne veulent pas être dépendants de vous, mais vous avez été embauché parce qu'ils dépendent en fait de vous.

Vous pouvez soit calmer la direction avec :

• Vous ne pensez pas à aller ailleurs de toute façon, donc ils peuvent compter sur vous à long terme.

Je pense que je suis confronté à des problèmes qui me permettent de garder mes compétences utilisées, donc je pense que je trouve enfin un lieu de travail dont je peux profiter pendant longtemps

• Vous êtes prêt à donner une formation aux autres membres de l'équipe pour apporter une valeur supplémentaire à l'équipe. J'ai remarqué que le code des autres n'est pas vraiment à la pointe des techniques de développement de logiciels, ce n'est pas un problème, je peux arrêter d'utiliser ces techniques, mais il serait bénéfique que chacun commence à les utiliser progressivement pour améliorer les performances de l'équipe. Je peux vous aider.

• On vous a demandé d'implémenter les fonctionnalités XY, sachant que les fonctionnalités livrées dans les délais nécessitaient vos compétences, les choses auraient pu être faites de différentes manières mais en beaucoup plus de temps et avec le risque de bogues supplémentaires.

Puis-je avoir un peu plus de temps pour terminer les prochaines fonctionnalités ? J'ai vraiment travaillé dur pour que les choses soient faites correctement, j'y suis parvenu mais je crains que tout le monde ne puisse pas comprendre cela, je veux plutôt prendre un peu de temps pour rendre les choses compréhensibles aux autres.

Soyez honnête, si une déclaration ne s'applique pas (je ne sais pas maintenant sur ce que vous avez fait), ne mentez pas, jamais.

S'ils vont vous virer, alors ils ne dépendent pas vraiment de vous pour de vrai. De toute façon, au moins deux personnes de l'équipe comprennent votre travail : Vous et votre collègue. Et il y a de fortes chances que d'autres personnes soient capables de le comprendre à l'avenir. En principe, vous n'êtes pas un goulot d'étranglement dans votre équipe, mais ils craignent que vous puissiez le devenir plus tard. Ils devraient de toute façon investir un peu de temps dans la formation.

Lire * The Wagon, the Blackbird, and the Saab . J'ai eu des problèmes similaires dans le passé ; j'ai appris des choses sur la façon de faire face, mais nous avons tous les deux utilisé un balai à franges et un seau pour essayer de nettoyer la sortie d'un tuyau d'incendie. Je ne veux pas dire par là que vous méritez un diagnostic de santé mentale dans le cadre du DSM-V, mais je suggère que vous pourriez être bien avisé de trouver un bon conseiller et de travailler sur les comportements non menaçants et les compétences sociales. Vous pourriez également lire * Théorie des esprits étrangers .