これで３回目だとしたら「あなたじゃなくて彼らが悪い」とは言えないわね あなたのタイトルによると、あなたは「必要不可欠な存在である」という理由で解雇されたと書かれていますが、そのことは別として、何が起こったのかということではありません。あなたは同僚が理解できないコードを書いたために解雇されたのですが、これはプログラマーにとって重要なパフォーマンスの問題です。複雑でタイトに書かれたコードを必要とするような状況は最近では非常に稀で、真の専門家によって書かれ、保守されているはずなのですが、あなたはそのような会社で働いていなかったことは明らかです。あなたが説明していることは、典型的には過度に複雑で、難解なプログラミングのトリックに満ちていて、理解したりデバッグしたりするのに時間がかかる「ファンシー」なコードのように聞こえます。これは古典的な訓練を受けた人にとってはよくある失敗であり、生産的な環境に入った途端、彼らは一般的に無礼な目覚めを迎えることになります。

それは冗談ではありません、私はこれが4回目に起こることに耐えられなかった、それは精神的に私に影響を与えています。

この行は、あなたがそれが変更する時間だと感じていることを示しているので、重要です。これは、あなたがこれをパターンとして認識していることを示しており、そのパターンを止めたいと思っていることを示しています。その願望は、おそらく解決策の中で最も重要な部分です。この種の状況を解決するには、多くの場合、あなた自身が考える方法を変える必要があります。それはあなたのためにそれを行うために誰かのために不可能ですので、変更するためにあなたの願望は、変更が実現する1つのことになります。私はC++のテンプレートメタプログラミングで癌を治すことができましたが、私が一緒に仕事をしている人の多くは、オブジェクト指向設計の基本をほとんど知らないのです。私はSFINAEを悪用したコードを書き、C++仕様の正確な文言に真っ向から反発していましたが、多くのプロジェクトがまだ時代遅れでバグだらけのバージョンのgccを使用していました。私のアプローチは、これらのツールがどれほど素晴らしいものであるか、そしてそれによって解決できるすべての問題を紹介することでした。私は人々に小さなプログラミングのヒントを説明するのが好きで、彼らはそれを楽しんでいました。

“そうですが、コンポーネントはインテリジェントに分離されているので、[Mikのコード]を理解するには良いレベルを持っていなければなりません。あなたの上司は何があっても物事を継続させる必要があります。あなたが素晴らしい仕事の機会を追いかけるために退職したとしても、あなたの上司はコードがメンテナンスされていることを確認しなければなりません。あなたの同僚が言っていたことは、もしあなたの後任が必要になった場合、非常に熟練したコーダーを見つける必要があるということです。これはリスクです。もし彼らが十分に優秀な開発者を見つけることができなかったり、彼らに十分な報酬を支払う余裕がなかったりしたらどうなるでしょうか？

あなたは「良いコード」と呼ばれるものを作ったかもしれませんが、「良いコード」の定義は文脈に大きく依存しています。何がGoogleで「良いコード」であるかは、彼らの最先端の考え方で、FAAで働いている人のための非常に悪いコードかもしれませんが、主に最先端に追いつくのではなく、信頼性に懸念している。あなたの上司が定義する「良いコード」には、あなたがいなくても、あらゆる状況でそれを維持する能力が含まれています。もしあなたの同僚があなたのコードを快適に維持することができないならば、あなたは突然会社にliabilityとなってしまい、もしあなたが他の場所に行くことを決めた場合、彼らが維持できない製品を生産しているからです。本能的に、これは良いことのように見えるかもしれませんが、それはあなたが考えていないかもしれないこのリスクベースの考え方のような難しさに満ちています。

我々は、"馬の前にカートを置く "というフレーズを持っています。これに関連する多くの意味の一つは、あなたが最も気になる内容（あなたの高度なテクニックを使えること）を、それを引っ張るべき力（あなたの同僚のテクニックの理解度）よりも優先させることです。あなたはこの高度なスタイルでコードを書き、他の開発者にこのスタイルに「追いつく」ように勧めました。これは効果的ですが、彼らが「追いつく」前にあなたに何かが起こった場合、誰もコードを維持することができないので、会社は突然危険にさらされています。

どのようにして将来的にこれを避けることができますか？

これを修正することは、あなたが通常快適であるとは異なる方法で問題にアプローチすることを含むので、これを行うことは非常に難しいことです。最初にこの高度なスタイルでコードを書いて、同僚にそのように考える方法を教えるのではなく、あなたはそれを反転させるべきです。同僚にそのスタイルのコードを好きになるように教えて、そのスタイルでコードを書き始めましょう。後ろ向きに見えるかもしれませんが、その方がずっと安定しています。上司の視点では、チームがより良いコーディングを学ぶことによるリスクはほとんどありません。彼らがより良いコードを書けるようになれば、あなたが開発したいと思っているスタイルのコードは、突然リスクが少なくなります。あなたのコードは、ここではあなたの唯一の製品ではありません。あなたの他の製品は、他の開発者にコードを教えるのを手伝っているのですが、その価値は「完璧なコード」を書くことの価値を簡単に超えることができます。簡単に見分けることができるのであれば、今頃は確実にわかっているはずです! あなたが使える強力なテクニックの一つは、自分でプッシュするのではなく、他の人に高度なコーディングスタイルをプッシュしてもらうことです。誰かに継承と組版の違いを教えるのは一つのことです。継承と合成の違いを教えるのと、既存のコードベースを変更して、いつ継承と合成を使うのかをより明確にすることを提案するのとでは、全く別のことです。後者の場合は、彼らがコンセプトを理解しているだけではなく、それを理解していることを知ることができます。

このような概念を教えるための一つの理想は、何も教えないことです。生徒に何かを発見させて、その発見が進む方向を教えるのです。もしかしたら、生徒の一人が継承について何かすてきなことを発見したかもしれませんし、その発見したことをもとにビジターデザインパターンの方向性を示すことができるかもしれません。ただ Visitor を与えるのではなく、彼ら自身が Visitor を見つけに行けるように方向性を示してあげてください。あなたの答えのためにもっと重要なことは、それはリスクなしで会社に価値を提供することができます。あなたが会社に価値を提供している場合は、会社を危険にさらすことなく、事実上解雇されることはありません。そして、あなたはまだ解雇を得ることができるいくつかのケースでは、経営陣は、（そのような経済の低迷、または会社の方向性のシフトなど）それの理由を提供します。あなたは非常によくそれを行う場合は、代わりに管理があなたの同僚を形作るのと同じように、あなたのパスを形成し始めることがわかりますし、あなたは彼らがそれを最も必要とするときにjust右のスキルjustを学んだことがあなたのための好奇心の傾向を見つけるでしょう。

必ず理由があります

以前の雇用主は私の同僚にこのようなことをしました。彼のスキルレベルは私たちのスキルをはるかに超えていました。だから、彼は解雇されました。

なぜ、このようなことになるのでしょうか？

1.彼は自分のコードを維持することができる唯一の人でした。彼は協調性がなかった 3. 彼は店の標準に従わなかった 4. 彼は必要以上のものを提供していましたが、これは良いことではありませんでした 5.シンプルな、ソリューションは複雑なものではなく、必要とされていました。あなたは、人柄の良い、コミュニケーション、程度に謙虚でなければならない、必要に応じて傲慢な、ショップの基準に保つ、あなたの同僚と仲良くする必要があるときに支援するために、親しみやすく、迅速でなければなりません。

良いコードは下手なエンジニアにもわかりやすい 私がよく受けたアドバイスの一つに、「コードをメンテナンスしてくれる人が平凡なプログラマーで、あなたの居場所を知っている危険なサイコパスであるならば、そのようなプログラミングをしなさい」というものがあります。あまりにも巧妙なプログラミングは良くない、というのは、メンテナンスの時間が長いコードを知らない場合だからです。メンテナンスの現場では、火事がいたるところで起きていたり、何千人もの顧客がブロックされていたりすることがよくあります。ダサいコードと天才的なコードの間には、効率的でありながらも読みやすいという絶妙なバランスがあります。それは科学というより芸術です。だからこそ、多重継承のような賢い概念は、通常はお勧めできません。たとえそれが素晴らしいものであっても。あなたは最高の人だけを雇う小さなエッジの会社で働いている場合は、おそらくあなたは、いくつかのエキゾチックな、素晴らしいものを買う余裕があります。もしあなたがフランスの銀行で働いていて、コンサルタントに頼っているならば、（運が良い時もあれば悪い時もありますが）、各コンサルタントが数百万のLOCを維持するためのドメインを持っていて、平凡な人が一目で理解できるようなシンプルなものにしてください。ポインターを使わない、多重継承をしない、巧妙な仕掛けをしない、などなど。

あなたが優秀すぎるからといって 解雇されることはまずありません。それはただの言い訳だと思います。

それはそれが行動の問題であるか、または彼は訴訟の根拠を作成せずにあなたに言うことができない理由のために上司が単にあなたを好きではない可能性がはるかに高いです。それはまた、あなたが最も高価であり、彼らはFTEs（すなわち、すべての労働者が同じである）を信じていることが可能です。

あなたが本当にその良いならば、あなたは良い方法で自分自身が不可欠にすることができます：

• メンタージュニアプログラマー。
• 他の人がメンテナンスしやすい良いコードを書こう。
• 生産性を高める方法でベストプラクティスを提唱し、紙の上では良いように聞こえるが生産性を殺してしまう カーゴカルト ベストプラクティスとは対照的に。

必要不可欠な人材を解雇することは、実は健全な経営戦略である。あなたの会社が一人の人間に頼って仕事を続けていて、その人間の知識や能力を持っている人が社内にいない場合、その人間がバスに轢かれて死んでしまったり、新しいことに挑戦するために会社を辞めてしまったりしたらどうなるのでしょうか？今、あなたの会社は、誰もがすぐに不可欠な従業員を置き換えることができず、あなたはタイミングをコントロールできなかったので、terrible状況で立ち往生しています！

このような状況を防ぐために、会社は2つのオプションがあります。なくてはならない人の同僚の知識を広めたり、能力を高めたりすることを試みるか、あるいは、その人の選択したタイミングで解雇し、その準備ができたときに、その人がいなくなってしまったことから回復させることで、バンドエイドを一度に取り除くことができます。あなたの知識を同僚と共有し、あなたがいないときにあなたの仕事をしてくれる人がいることを確認してください。あなたの実践が、あなたの会社の平均的なレベルの労働者に適したものであることを確認してください。平均レベルが低すぎると感じる場合は、経営陣と協力してレベルを上げるようにしましょう。あなたが作成するものはすべて文書化されており、その文書があなたの同僚の誰もが仕事を継続するためにそれを使用できるような十分に高い水準のものであることを確認してください。

3つの状況の間で唯一の共通点があなたである場合は、あなたがやっている何かが問題であると考える必要があります。

あなたはあなたの元同僚と話をして、彼らにあなたを批判するように頼んだことがありますか？あなたのコードではなく、オフィスでのあなたの行動。同僚とのコミュニケーションの取り方、上司とのコミュニケーションの取り方、書類の作成の仕方、会議での振る舞い方などなど

上司の立場になってみましたか？本当に彼らが何をしなければならないか、彼らの責任は何か、何が彼らがオフィスのライトを消して家に帰るときに彼らを良い気分にさせるかについて考えてみましたか？誰かが素晴らしいコードを書いているのに、会社が失敗している例はたくさんあります。

あなたのプロフィールを見てみると、「あなたのコードは自分よりもきれいであるべき」と書かれています。また、「コンセプトの説明に多くの時間を費やした」「批判するのもエンジニアとしての仕事」というコメントからも 私が思うに、あなたはアドバイスをすることに熱心で、あなたのアドバイスは単にチームメイトに評価されていないだけなのではないかと思います。チームと仲良くできないと解雇されます。これはあなたの問題であって、（あなたが想像しているように）あなたのコードが良すぎるという問題ではありません。あなたのコードは本当に良いかもしれません - しかし、これは人格の衝突の問題である可能性がはるかに高いです。頭を下げて、stop telling people to how to code, follow direction, work well with others, write maintainable code.

私はまた、あなたのマネージャーからのこの発言に興味を持ってメモしています:

“でも、彼がふりをしているように本当に良いものなのか？”

これがあなたに伝えていることは、your manager does not trust you, your manager thinks you are inauthentic and think you are arrogant and/or think the higher regard for your own ability than you actually have. 人間関係は信頼に依存しています。ここで注意してほしいのは、あなたの問題は技術的な問題ではないということです。あなたの問題はコードの品質とはほとんど関係ありません。あなたが抱えているのは、あなたの同僚や上司との関わり方に問題があるということです。

人々はしばしば不可欠であることのために解雇されることはありません なぜ人々は解雇される）; それはばかげた主張です。あなたが参照している記事は明らかに “火 "は必ずしもそれらを行かせることを意味するものではないことを修飾し、むしろ（特定のプロジェクトなどに関与しないようにそれらを強制的に、それらを移動することによって、それらを不可欠ではないようにする（それらを移動することによって）＆002＆002 overqualifiedは時々あなたが雇われて取得することはありませんが - それはまた、あなたが解雇されることはほとんどありません。良い従業員を見つけるのは非常に難しいです。彼らはあまりにも良いので、ない合理的な会社は1つを取り除くつもりはありません（あなただけのバカのために働かない限り - その後、彼らはあなたに好意をやっている）。 残りの部分はロープを結んでいる間、あなたは原住民の束とラップトップを引き出して橋を構築している場合は悪い態度のために解雇)

• あなたはよりスマートまたはより多くの教育を受けているかもしれませんが、あなたはチームへの不利益になっていると問題はあなたです。あなたはそれをやっていた、あなたはおそらく非常に長い時間のための仕事を持っているだろう。

定期的に雇用プロセスに関与している人として、私は偉大であり、任意の日の潜在的な癌である誰かの上に良いと人柄の良いです誰かを取るでしょう。

すべてのプログラムは、それを実行させるコンパイラやインタプリタと、それを読んで理解した人間という2つの聴衆とのコミュニケーションです。コンパイラとのコミュニケーションが非常にうまくいっていても、関係する他の人間には容易に理解されないために悪いコードを書いているかもしれません。チームの誰もがそれらを説明することができるので、それらの部分のいくつかを欠落している新しい雇い主はすぐにそれらを吸収します。

そのセットの外の何かを使用して、雇用者にコストを運びます。例えば、あなたがフレームワーク X に精通しているグループの唯一のプログラマーであり、他の誰もが既存のコードに使用されている古いフレームワーク Y に精通しており、X とほぼ同じくらい良いとします。彼らが何について質問しなければならないかを見て、彼らにとってより明確になるように書き換える方法を考えてみてください。あなたのコードを理解するための失敗を、読者ではなくコードの欠陥として扱えば扱うほど、より良いフィードバックを得ることができます。

私の読みでは、あなたは入社初日からこの待遇のためにdestinedになっていたということです。あなたは、組織の誰にもできないスキル（TypeScript、Node）を持っているから雇われたと言いました。そして今、あなたはエレガントで専門的に作られた複雑なソリューションを一人で作り上げようと努力していますが、誰もあなたが何をしたのか理解していないので、経営陣からは負債として見られています。

私の見解では、問題は個人的なものではなく、構造的なものであり、したがって、責任は状況とプロセスではなく、人にある：

• 組織は、重要な機能を実行するために、他の誰よりも、それらのスキルの高度なレベルで、完全に異なるスキルセットを持つ一人の人を雇った。これにより、If you perform wellは、組織のミッションにとって重要なコードを理解しているのはあなただけであることが保証されています。(上級レベルのリソースが、使用されている言語を知らない人々に瞬時に意味のあるコードを生成することを期待するのは完全に不合理です。)
• 組織は定期的にコードレビュープロセスにあなたを参加させませんでした。もしそうであれば、あなたのコードを可読性の基準に適合させるまで、あなたのコードは却下されていたでしょう。あなたはコードの唯一の貢献者であり、独自のスタイルを持ち、異なる技術スタックを使用しているため、時間の経過とともにコードが他の人に理解されにくくなることは事実上保証されています。これを防ぐための唯一の方法は、他の人の時間を無駄にしていると非難される可能性があるので、プロセスの外でコードのレビューを常に他の人に頼むことです。コードレビュープロセスの欠如は、このように失敗のためにあなたをセットアップします。私は一度スキルギャップを埋めるために雇われました。社内には、急に必要になったスキルを持った人がいませんでした。私は自分の仕事をきちんとこなしていたのですが、数ヶ月後に紛争が始まりました。アプリケーションの特定のコンポーネントを扱うことができるのは私だけでした。私にしかできない仕事が積み重なり、私がボトルネックになっていました。ある日、会社が私が制作したすべてのコードを、自分たちのやり方で完全に新しいコードに置き換えることを決定したため、私は外されることになりました。その時はプライドが傷つきましたが、振り返ってみると会社としては正しい判断だったと思います。

もしこれに似たようなことを感じたならば、あなたが前に進むべき時が来たのかもしれません。多分、管理職は、彼らはあなたのスキルを評価し続けている場合は、他の何かにあなたを再配置します。あるいは、あなたがそれを我慢することができれば、あなたが企業の標準技術スタックで行ってきたすべてのことを書き直すのを手伝うことができるかもしれません。それが不可能な場合は、辞めればいい。どちらにしても、あなたのコードはおそらくゴミ箱への道を歩んでいるでしょう。誰もそれを理解していないのであれば、それは彼らがするべき正しいことなのかもしれません。そして、それは彼らの選択の当然の結果です。

次の仕事では、あなたのチームの他の人があなたと基本的に同じスキルを適用していることを確認してください。彼らがあなたのコードを特定の方法で変更するように頼んできたら、それを実行してください。納品されたコードがコードレビューに合格するまでは、そのコードを考慮しないでください。そうすれば何の問題もありません。技術面接でこのようなことを質問しても全く問題ありません。願わくば、あなたのコードを研究した他の開発者が良い参考にしてくれることを願っています。

脚注として、もしあなたが他のチームメンバーからの賛同を得られずに一人で作業していた状況に少なくとも部分的に責任があるならば、あなたも結果の責任の一部を負うに値するでしょう。(他の人が他の何かを使いたいと言っているときに、あなたはTypeScriptやNodeを使うことを推し進めましたか？もっと基本的なものでも問題ないのに、最新でクールなライブラリやテクニックを使っていましたか？私も一度や二度、このようなことがありました。) もしそうなら、この結果から教訓を得るようにしてください。しかし、そうでない場合は、この経験を頭を高くして次のポジションに持っていきましょう。

ほとんどの回答は、あなたのコードが読めるか読めないか、あるいはあなたが言うほど優れているかどうかという観点からあなたの投稿を扱っています。しかし、このような状況は、あらゆる人生の歩みの中で起こる可能性がありますし、起こりません。私はラスベガスのストリップで21ディーラーとフローマンとして仕事をしました。私の技術とスピードは、私を監視するために割り当てられた人々が追いつくことができないように、彼らの残りの人員よりもはるかに先を行っていました。言い換えれば、彼らは私の判断に従うことができなかったのです。大金が数分以内に取引されていたため、彼らはしばしば混乱し、私がミスをしたと上司に報告することがありました。私はいつもその人に自分の行動を正当化していましたが、私に対する不信感が深まっていきました。私は解雇され、非常に良い支払いポジションを失った。

レッスンは簡単です、あなたは他の人のレベルにダミーダウンする必要があります。彼らは1時間に15だけ手を得ると、100を得る場合は、賞賛を鼓舞していません。あなたは嫉妬とさえ憎しみを鼓舞している。あなたのプライドがこれを行うことができない場合は、すべての場所が本質的に同じであるため、生計を立てるための他の方法を見つける必要があります。人は人であり、あなたは彼らを変えることはできません。私は最終的には、私はあまりにも平凡だったので、このように目立たなかった仕事の他の行に定住しました。あなたがあなたの利点にこれを整理することができることを願っています。

答えに私のコメントをアップグレードすることにしました：

**あなたのコードを非常によく文書化してください。

あなたが自分で思っているほど優秀ではない可能性もありますが、礼節を重んじるために、あなたはコードベース全体の複雑さと所要時間を桁違いに減らすために、適切な量の複雑なコードを書く方法を知っていると仮定します。これが可能であるという事実は、多くの馬鹿を驚かせます。彼らはそれを信じられない命題だと感じ、彼らを納得させる唯一の方法は、彼らに示すことです。あなたは他のすべてのものよりも先に3つのことに集中する必要があります：あなたが脅威ではないことを証明すること、愚か者をスマートに見せること、そして一人の愚か者にあなたが愚か者であることを認識させないことです。この3つのことができなければ、失敗して自分のせいになる。実利主義は必須であり、プライドのための余地はありません。

このアプローチをすべての人に勧めることはできませんが、私にとっていつもうまくいっているのは、敵対的なバカが私に何をしろと言うかを時々無視することです。その代わりに、自分のやりたいことを見つけて、彼らの多くがこれまでに見たことのないような最高のソフトウェアを短時間で制作し、上司に褒められるような形で発表しています。たとえ彼らがそれを作ることに何の役割も果たさなかったとしても 彼らが積極的に反対していた時でさえも。自分の仕事は自分の手柄にすべきではないのでしょうか？みんなの気持ちに踊らされていいの？関係ありません。これが現実です。それに適応しなければ、自分がバカなのです。

高度なスキルを持った開発者は何物にも代えがたい存在であり、それがあなたが開発者を必要とする理由だと考えている 多くの賢い人 がいます。しかし、あなたの質問に対する他の回答を見たことがあるでしょう - ほとんどの管理者は、スキルレベルが非常に異なるチームの問題に対処したくないし、純粋に高いスキルを持つという選択肢はありません。彼らも必ずしも間違っているわけではありませんが、問題は現実にありますし、彼らが雇うことができるほとんどの人の能力を超えた高品質のコードの利点は大幅に減少しています。あなたは、あなたの同僚から学ぶことができ、あなたの同僚があなたのコードを理解することができる場所で働くために努力すべきであるように聞こえます。

このためにいくつかのジョブを失っている場合は、あなたは、人事、採用担当者、および管理者にかなり悪いように見えるだろう。うまくいけば、同じようなスキルレベルの開発者に会って、問題はあなたのスキルレベルが高すぎることだと保証することができます。

最後に、あなたのスキルレベルが本当に高いかどうかを正直に評価するために最善を尽くさなければならないことを付け加えなければなりません。そうであるという証拠があるように聞こえますが、ほとんどの人は自分が自分よりも優れていると信じています。また、多くの開発者は、一つのアプローチは非常に得意になっても、グローバルに最適な解決策を常に考えているわけではなく、柔軟性に欠けています。例えば、開発者がより洗練されたものを維持できないことがわかっていて、維持できる人を他に雇う可能性が低い場合は、自分が持っている人が維持できるとわかっている劣ったソリューションを使うのがベストな場合もあります。

具体的に質問に答えるためには、

どのようにして将来的にこれを避けることができますか？

• トーストマスターズの地元の支部を見つけ、積極的に参加し、成果を獲得しましょう。フィードバックのようにとても明白に思える何かは、うまくいけばあなたの最も評価されたスキルの一つに評価され、研ぎ澄まされるようになります。

• エキスパートの代わりに学生であることを練習します。Jon Skeetの基本的な話](https://youtu.be/jGUoF-uByGg)を見たことがありますか？私たち全員がこのような文書を作成した場合、どれだけ多くの理解が達成されるか想像できますか？

• チームは1つの個人ではありません。あなたのチームは集団的に成長し、向上していきます。あなたが助けなければなりません。各メンバーが異なる方向（例えば、あなたが高く、最新のメンバーが停滞）に行くセルである場合、それはチームではありません。2時間の会議は良いスタートです。私はその上に、N-dayのペアリングローテーションを追加します。これは、あなたがあなたのチームメイトに与えると**彼らはあなたに与えるの1:1の時間です。あなたの場合、ナビゲーターの役割に傾いて、パートナーに運転を任せてください。奇妙に聞こえるかもしれませんが、コードを書かない練習をしてみましょう。目的はコラボレーションすることであり、フォールトトレラントなエネルギーユーティリティグリッドを構築することではないので、それはあなたのコードを蒸留するためにあなたを強制することができますよね？

• これらの演習のそれぞれで、この概念を試してみてください：奉仕によるリーダーシップ。どのようにして他のチームメンバーのニーズを助けるためにタスクを行ったり、何かを達成することができますか？

• 指摘されているように、オープンソースプロジェクトに貢献して、自分のコードについてより多くの角度を得ることができるようにしましょう。彼らはあなたが優秀であることを確認するだけでなく、あなたが現在の上司から聞いている提案を補強するかもしれません。せいぜい、いくつかのレビューはあなたに新しいアイデアを与えるでしょう。

• あなたよりも優れたエンジニアを見つけてください。部屋の中で一番賢い男になるために自分自身を改善しているわけではありません。引用があります（私のグーグルはOlgivy/Ford/Sorkinの間で分割されています）言い換えは、「あなたは悪い才能で自分自身を囲む場合は、より多くを学ぶことはできません」のように行きます。

私はあなたの説明があなたの言う通りの状況であると仮定するつもりです。私はこの正確な経験を持っているとは言えませんが、私には馴染みのある側面があります。

あなたはこれが「大きな」会社だと言いますね。フランスではどうなのかわかりませんが、大企業では社内の開発者のスキルを重視しないことが多く、特にテクノロジーに特化した企業ではない場合が多いです。これは、そのような会社のマネージャーが技術的なバックグラウンドを持っていなかったり、開発に向いていなかったために開発から遠ざかっていたという事実に起因していると私は考えています。あなたのチームがこれらの恐ろしいものを使っていなくても、会社の経営者が開発チームに対する反インテリ的な考え方を教え込まれている可能性があります。私は実際に、あるマネージャーに面と向かって、私は与えられたソリューションを構築するのに十分に賢いが、その後、誰もそれを維持することができないので、何か（シェルフウェア）を購入する必要があると言われたことがあります。高いスキルを持った開発者を大切にしている会社。でも、そこでは最高の開発者ではないこととの葛藤があるかもしれません。もしあなたがシェフを目指していたら、マクドナルドで働くのは不幸になるかもしれません。彼らに必要なのはシェフではありません。彼らはレシピに従う人々を必要としています。あなたはシェフの材料になるかもしれませんし、この会社（と他の人もそうですが）はマクドナルドです。あなたが自分自身に尋ねる必要がある質問は、なぜあなたがすでにこれを行っていないのかということです。

どのようにして将来的にこれを避けることができますか？

あなたが合理的にコーディング標準があなたのものと一致していることを確認しない限り、誰とも仕事をしないでください。これは、次の適用のnone場合は、任意の仕事を拒否することを意味します：

• 彼らはインタビュープロセスの間にプログラミングの質問をする
• 彼らはピアプログラミング演習を持っている
• 彼らはコードのサンプルを求め、それでOKである
• あなたは彼らが生成したコードのいくつかを見ることができます

どのように私は現在ではこれを避けることができますか？

これは他の回答でカバーされています。最初にインターンを管理しなければならなかったとき、私は彼が制作したコードをほぼ全滅させてしまいました。私はコミットされているものを見たとき、私は文字通り激怒していました（幸いにも私は目撃者がいませんでした:P）。他のプログラマーと一緒に座って、2～3時間一緒にコードを書いてみましょう。説明するのが難しすぎるかもしれない概念（例えば、新しい高度なJava 8の機能）を落として、より簡単なもの（継承）を説明してください。

他の人と話をするときには、人を怒らせないように “ダブらせ "なければならないことがあります。特に、あなたが他の人よりも上の立場にいる場合、あなたが知っているはずなのに知らなかったことを話すと、相手は気分を害するでしょう。コメントの中で、なぜそのコーディング方法を選んだのかを「正当化」する必要があるかもしれません。あなたは最高のコーダーかもしれませんが、もしあなたがチームの中にいるのであれば、チームとして仕事をしなければなりません。少なくともその後、彼らはそれを読むことができ、それを理解し、チーム自体がより良いオフになります（それはあなたが内部で叫んでいることを意味する場合でも）。

あなたがチームの一部である場所に行くほぼどこでも、彼らがどのように物事をコーディングしたいかのガイドラインを持っているでしょう-そしてあなたはこれらのガイドラインに従う必要があります。

長期的に彼に頼ることができない

それが大きな問題です。彼らはあなたに依存することを望んでいませんが、彼らは実際にあなたに依存しているので、あなたは雇われました。

あなたはどちらかで管理を宥めることができます：

• あなたはとにかく他の場所に行くことを考えていないので、彼らは長期的にあなたを頼りにすることができます。

私は私のスキルが使用され続けている問題に挑戦していると思うので、私は最終的に長い時間のために楽しむことができる職場を見つけると思います

• あなたはチームにさらなる価値を提供するために、他のチームメンバーにトレーニングを提供することを望んでいます。

他の人のコードが最先端のソフトウェア開発技術を使っていないことに気づいたのですが、それは問題ではありません。私はそれを手伝うことができます。

• あなたはXY機能を実装するように要求されましたが、その機能を時間内に出荷するにはあなたのスキルが必要でした。私は本当に物事を適切に終わらせるために一生懸命働いていましたが、誰もがそれを理解できるわけではないことを恐れています。

正直に言って、もしいくつかの文が当てはまらない場合(あなたが働いていたことについては今はしていません)、嘘をつかないでください。とにかく、チーム内の少なくとも2人はあなたの仕事を理解しています。あなたとあなたの同僚。そして、将来的にはもっと多くの人が理解してくれる可能性があります。基本的にあなたはチームのボトルネックではなく、後になってあなたがボトルネックになることを恐れているのです。彼らはとにかくトレーニングに時間を投資するべきです。

読む * ワゴン、ブラックバード、そしてサーブ **。それはあなたと共鳴する必要があります。

私は過去に似たような問題のようなものを持っていた;私は対処する方法についていくつかのことを学んだが、我々は両方の消防ホースの出力をクリーンアップしようとするためにモップとバケツを使用してきました。あなたはまた、* エイリアンの心の理論 **を読むかもしれません。