上級開発者からのアドバイスが悪い場合、どのように伝えますか？[閉まっている]

最近、私はジュニア開発者として最初の仕事を始め、この小さな会社で私を指導する上級開発者がいます。しかし、彼が私がちょうど同意できないことについて私にアドバイスをすることが何度かあります（専門家によって書かれたトピックに関するいくつかの良い本で学んだことに反し、いくつかのQ＆Aサイトで尋ねた質問も同意します忙しいスケジュールを考えると、おそらく長い議論の時間はないでしょう。

これまでのところ、私は彼の話を聞いて問題を回避しようとしており、現在の優れた実践として学んだことに基づいて対抗点を上げています。彼は再び元のポイントを上げます（ほとんどの場合、彼はベストプラクティスと言いますが、より保守性がありますが、それ以上先には進みませんでした）。それと自宅で研究していますが、変更を加えないでください（私はまだ確信していません）。しかし最近、彼は再び私に近づき、私のコードを見て、なぜ彼の提案に変えないのかと尋ねました。これは2〜3週間で3回目です。

ジュニア開発者として、私は彼を尊敬すべきだと知っていますが、同時に彼のアドバイスのいくつかに同意することはできません。それでも、私はプロジェクトを悪化させると思われる変更を加えるよう圧力を受けています。もちろん、経験の浅い開発者として、私は間違っている可能性があり、彼のやり方はより良いかもしれません。それはそれらの例外事例の1つかもしれません。

私の質問は次のとおりです。上級開発者のアドバイスが良いか、悪いか、それとも良いかもしれませんが、今日の文脈では時代遅れであるかどうかを判断するにはどうすればよいですか？そして、それが悪い/時代遅れの場合、私は彼が「プレッシャー」にもかかわらず彼を先輩として尊敬しているという事実を維持しながら彼の方法でそれを実装しないためにどのような戦術を使用できますか？

第一に、シニア開発者として、私がプロジェクトで率いる後輩が彼らの懸念を率直かつ直接的に私にもたらすことを期待しています。彼らが同意しない場合、それは完全に大丈夫です。場合によっては、私は彼らの懸念に対して行動を起こします。ほとんどの場合、彼らの懸念は、開発者自身に対する無礼ではなく、次のような他の理由のために、理由の簡単な説明を脇に 置いて捨てられます：

1. ジュニアは、決定が下されたときの決定を理解するための情報をすべて手元に持っているわけではありません。場合によっては、開発者が少しの説明をするだけで、懸念を乗り越え、理想的でない状況に対処することができます。
2. ジュニアには悪い情報があります。実際、あなたが後輩であることを忘れないでください。これは、ソフトウェア用語でティーンエイジャーであることと同等です。素晴らしいアイデアはたくさんあると思いますが、すべてを知っているわけではない可能性があります。私は、最も抵抗力のあるジュニア開発者は、コード、会社、世界にとって何が最善であるかをしっかりと信じている開発者だと思います。これらの開発者は、謙虚さを身に付けることでより良いサービスを提供します。
3. 特定の方法で何かをするという決定は、シニアの頭の上で行われました。シニアは最終的に他の誰かのためにまだ働いています。実際には、何かを行うためのより良い方法、何かを書くためのより効率的な方法、または仕事をするためのより良いソフトウェア/ハードウェアがあるかもしれません。しかし、ビジネスは依然として決定を後押しします。ビジネスマネージャー、ディレクター、VPなどは、多くの場合、開発プロセスに影響を与える決定を行います。これらはシニアのコントロールを超えており、後輩がそれについて不満を言うとき、彼らがしているのはシニアのストレスに加わることだけです。
4. ちょうど平らな先輩には、それを考慮に入れる時間がありません。期限があり、途中でパターン、プラクティス、および動作を変更すると、その期限までに費用がかかる場合があります。彼はチョッピングブロックに首を突っ込んでいるので、「完璧に書かれた」よりも、製品を機能的で時間通りに出すことが重要な場合がよくあります。

これらは私が頭の外から考えることができるものです。アイデア、実践、概念があなたよりも上位の誰かによって却下または破棄される理由はたくさんあります。それらの多くは不快ですが、それらはすべて、私たちはすべて人間であり、私たちはすべて意見を持っているという事実に要約されます。彼の意見は、たまたまあなたよりも数値的に優れています。

これらの概念を念頭に置いて、上級開発者に懸念を持ち続けてください。空白を埋めることができる別の上級開発者を見つけてください。多くの上級開発者は、人々よりもソフトウェアの方が優れているため、彼らがいる場所です。インターンのときに誰がキスするのか知っていたので、彼らがいる場所もあります。誰かを指導することの意味を実際に理解している人を見つけて、正直な意見を聞いてください。彼らはあなたに反対し、あなたが持っていない空白を埋めるかもしれません。彼らはあなたに同意し、あなたの原因を結集したり、あなたの状況を改善するのを助けるかもしれません。

いかなる種類の暴動を起こしてはいけません。たとえ自分のやり方が正しいと心で信じていても、従うように指示されているので、従うべきです（明らかに違法でない限り）。これらの指示に従わない場合は、このような行動パターンを発見して、あらゆる種類のソフトウェアを生産する非常に多くの企業で非常に一般的であるため、その理由を試してみてください。

最善の選択肢は、倫理的かつ専門的に仕事を続けることです。模範的な方法で完了するように求められているソフトウェアを入手し、そのソフトウェアから昇格することで状況を回避します。プロモーションが来ない場合、他の部門や企業での機会を追求するための多くの参照と経験があります。

上級開発者を尊重します。彼は、あなたよりもプロジェクトの成功を目指しています。彼には責任があるので、彼には権限も与えられます。彼が何かを変えると言ったら、それをしなさい。

そうは言っても、あなたが既に持っているような問題に遭遇したとき、あなたの懸念を示すことをheしないでください。

最後に、彼と一緒に座って、ここに投稿したのと同じ質問を彼に説明します。何か大きなものを見逃しているのかもしれませんが、彼はあなたの提案にもっと開かれているかもしれません。

この場合、あなたがする必要があるのは、上級開発者との会話です。おそらく、彼はあなたがコードや技術/ビジネス要件について知らないことを知っているでしょう。もしそうなら、あなたはそれを学ぶべきです。

プライベートで行います。それはやりがいのある権威と見なされるかもしれず、そのようなことは一対一で行われるのが最善です。彼の年功序列を認め、尊重することにより、妥協し、協力する意欲を示しますが、あなたの質問に答えてもらうことに固執します。戦闘的なフレームではなく、協調的なフレームから状況にアプローチします。メンターを頼むことを検討するかもしれません。

結局のところ、自分のアイデア（公平を期すと、比較的新しく、テストされていない）と彼のアイデアのバランスを取る必要があります。おそらくあなたは本当に正しいかもしれませんが、より多くの情報に基づいた決定を下せるように、より経験豊富な人々から学ぶために最善を尽くすべきです。優れたシニア開発者は、ジュニア開発者とのコラボレーション、メンター、学習の機会を歓迎します。また、彼らが間違っていることを知っているため、建設的な方法でアイデアに挑戦することを歓迎します。

あなたがよく言う方法は、常識的なアプローチによるものです。上級開発者はプロジェクトについてはよく知っているかもしれませんが、物事を行う正しい方法についてはあまり知らないかもしれないことに注意してください。あなたは彼があなたに言うことを測定する必要があります-彼が言っていることが彼のより良い人が主張するものに直面した場合、彼はあなたに悪いアドバイスを与えています（すなわち、彼よりも年上の人;必ずしもあなたの会社ではありません...ソフトウェア開発を行うための正しい方法についての本を投稿したり書いたりする著名な「有名人」開発者、または少なくとも業界で認められているベストプラクティス）。

上級開発者（または任意の開発者）からの「悪いアドバイス」の例を次に示します。疎結合とは何か、そしてなぜそれが良いことなのかを完全に知らない場合は、すべてのコードを書くように言われます。 -ASPXファイルの背後では、上級開発者が無知であり、彼のアドバイスを聞くべきではないことは明らかです。

一方、システム内の特定のモジュールがどのように機能するかを彼が教えている場合は、適切な開発原則に反して吐き出さないと彼が言っていることを何度も聞くのが最善です。

私の経験則は次のとおりです。会社の上級開発者は、単に最も長い任期を持つ開発者であるかもしれません。彼には本当のスキルがないかもしれません。彼はあなたの分野で最も尊敬されている開発者の何人かに反することを言っていますか？（彼よりもはるかに多くの経験を持ち、より有能で尊敬されている人）もしそうなら、極端な状況がない限り、彼のアドバイスが悪い可能性があります。

極端に偏った視点のための完全なダウンボット/意見の相違を期待する。

上級開発者の有利な点を理解するのは難しいかもしれませんし、はい、彼は間違った方向に物事を導いているかもしれませんが、大規模なプロジェクトに関しては、一貫性がより重要です。

50人の開発者がすべて独自のコーディングスタイル、標準、方法論、およびデザインパターンに従っているのは、まったくの混乱です。物事が間違って行われている場合、多くの異なる種類の間違ったものや正しく行われたいくつかの事柄よりも、常に一貫して間違っている方が良いです。

メンテナンスを実行したり、機能を追加したり、「間違った」ものを修正したりするときに、既存の設計の問題が事前にわかっていれば、はるかに簡単です。

敬意を払って意見を異にすることは良いことですが、最終的には列に並ぶことをお勧めします。不正を行うチームのメンバーは、チームプレーヤーとは見なされません。

シニアが業界のベストプラクティスを無視している理由を説明できない場合は、時間を無駄にしないでください。あなたはあまりにも脅迫しているので、あなたは前進することはありません、とにかく、あなたは悪いコードの山を維持することに時間を費やしたいですか？

ほとんどの開発者は、大学を卒業すると読むのをやめます。あなたはそうではないので、あなたはすでにトップ10％にいます。最近では多くの機会があります。町に雇用市場がない場合は、より良い町を探してください。

うわー、それはあなたがあなたのスキルを輝かせて自慢する素晴らしい機会です。私のキャリアの早い段階で、私はスーパーバイザーである誰かに決定を下すことができませんでした。だから私はその機会を利用して、次のレベルの仕事をする方法を学びました。昇進させられました。同じことをする必要があります。

上級開発者として、このタイプの受動的で攻撃的なnitの選択は私を夢中にさせ、直面した後、あなたは私にあなたに悪いレビューを与えるようにドライブするでしょう。完璧なソリューションは、チームが一緒に暮らすことができるものです。

スタイルに関しては、これはスタイルガイドと、作成元によって決定されるベストプラクティスによって決まります。あなたが情熱を持っているなら、それについて議論しますが、決定がそれと一緒に行われ、あなたがいるチームの境界で仕事をします。

あなたはそれほど良くない状況にいますが、HLGEMが指摘したように、これらの立場を変装の祝福に変えることができます。あなたの質問は多面的ですので、部分的にアプローチします。

私は疑っています、彼は知りません。同時に、彼はme慢であることを私に見せようとしているので、私は彼に質問をすることをあまりしません。

これは非常に真実です。開発またはメンタリングの観点からは、何十年も業界にいて有能なソフトウェアリードではない開発者が急増しています（違いがあります）。経験は新鮮な挑戦に取り組み、新しいアイデアを試し、新しいスキルを学ぶことから生まれますが、大半のプログラマーはコーポレートオフィスの一員として生活し、忠実なVisual BasicおよびJavaツールを使用してPayrollアプリケーションに取り組んでおり、世界のレースを見ることはありません寒い灰色のオフィスで。

これには何の問題もありません。多くの開発者にとってこれまで望んでいたすべてであり、状況に完全に満足しています。しかし、開発者を率いるのはもちろん、次世代のプログラマーを育成するのに理想的な状況ではありません。

ブラバドとar慢は、不備を補おうとする防御メカニズムになる可能性があります。どのように処理しますか？正面に立ち向かわないでください -リードが無能で、上司が状況を修正したくない場合は、それと一緒に暮らす必要があります。それはロールオーバーして死ぬことを意味するものではありませんが、誰かを良いリードに強制することはできません。

ただし、彼は私のコードをレビューするだけで、彼のコメントのほとんどはコーディングガイドラインに関連しています

これは、彼が良いプログラマーではないかもしれないという点であなたが正しいと思うことです。それは彼が現時点であなたよりも優れたプログラマーではないと言っているわけではありません（少なくとも、彼は業界に長い間いることでより多くの経験と露出を得るでしょう）が、それは、効果的なリード。ガイドラインはすべて順調で優れていますが、コードの機能、有効性、効率に次ぐものです。

そのような状況ではどうすればよいですか？

私はマネージャーにこの状況を伝え、私は彼に私のリードを変更するよう要求しましたが、彼は毎回「はい」と言いますが、彼は深刻な行動を取りません。

これらの特定のポイントをすべてマネージャーに列挙し、それをバックアップする特定の例を挙げましたか？あなたが単に彼に行って「新しいリードが必要だ」と言ったら、彼はあなたを真剣に受け止め、技術的な問題ではなく「対人関係の問題」として認識しません。この状況での多くのボスの反応は、「うまくいく」ことを期待して無視することです。

ここにいくつかの提案があります。

1. あなたの状況に恥をかかないでください -火による試用は、楽しいことではありませんが、後のキャリアのために重要な研究スキルを教えてくれます。
2. より深く関与するためにリードを押し始めます。これを慎重かつ丁寧に行ってください。彼が屈するまでプッシュし続けてください（これは実際に多くの状況で機能します）。
3. リードが関与しない場合は、あなたを助けることができる他の人がいるかどうかを確認します。搾乳時間のみに関心のあるスウェットショップで働いているのでなければ、会社は、ロープを見せたりコードをレビューしたりする経験が豊富な別の開発者を気にしません。
4. 新しい仕事に目を光らせてください。あなたが「絶対に去る」必要があるとは言いませんが、プログラマとしてのあなたの開発をより真剣に考える場所にいることはあなたのキャリアを傷つけません。

あなたは、特定の問題を解決行うには良い方法を持っている場合は、ちょうどそれを行います。

あなたのコード/ソリューションをあなたの最良の議論にしてください。そうでなければ、あなたが言われたことに固執します。

適例

私がジュニアだったとき、特定のコードセクションが最良ではない状況がありました。ちょうどそれについて議論するのではなく、私は単にそれが改善されたTHEN先輩に結果を示しました。コードは常に王なので、彼はそれを受け入れました。

もちろん、経験の浅い開発者として、私は間違っているかもしれませんし、彼のやり方はより良いかもしれませんので、私の質問は、上級開発者のアドバイスが良いか悪い/時代遅れのものかどうかをより良く判断するためにどのような方法がありますか？

経験豊富な開発者になることができます。それまでは、後輩としての自分の直感が正しかったかどうかを判断するのに十分な能力がなく、それまでは重要ではありません。

それまでの間、Joel Ethertonの答えを読んでください。

「自分のやり方で実装しない」ようにしないことを強くお勧めします。

これまでのところ、あなたは正しいことをしたようです。あなたは謙虚で、対位法を持ち出しました。あなたの質問から、あなたが単に彼の方法に反対したのか、それとも別の方法に反対して提示したのかはわかりませんでした。結論として、他の人のアプローチを撃ち落とそうとするときは、常に明確で考え抜かれた代替案を提示してください。彼がそれを見るかもしれないように、あなたはうまくいくかもしれない良い考えを持っています、そして彼はうまくいく考えを持っています。

いずれの立場においても、常に次善の策を講じざるを得ません。本当に気に入らない場合は、あなたがやったようにやって、それを持ち出すことができます。その後、上司の道または高速道路。明るい面では、ジュニアとしての貧弱な意思決定のリスクの多くから絶縁されています。

あなたの戦いを選んでください。1時間の作業について話している場合は、作業が終わるまでコードを変更する必要があります。次回大規模なプロジェクトを取得する場合は、開始する前にアイデアを提示する機会を事前に求めてください。少し時間をかけて、素晴らしいデモやプロトタイプを作成してください。

驚いたことに、私がやったことは、質問をやめることです。別のオプションが与えられたとき、私は脱線し、自分のやり方でそれを行いますが、それに独自のセンスを加えます。学習体験として使用して、能力を構築し、古い学校を維持する必要性を緩和します。

最終的に、すべての上級開発者が物事の新しい方法に注意を払うわけではありません。彼らは時々、20年前に始めた言語には素晴らしい古い方法を持っていますが、今日の世界ではハック、または「悪臭を放つ」と考えられています。

これは恐ろしい方法のように聞こえるかもしれませんが、そうです。しかし、先輩のやり方から多くのことを学びました。しかし、これは本当に私の意見です。最終的には、仕事に満足し、気晴らしや緊張を低く保つ必要があります。そして、物事に異議を唱えないことで、ストレスが大幅に減少することがわかります。

年配があるため、年配の人を信頼しないでください。できるだけ頻繁に権限に挑戦してください。管轄当局は、どんな質問にも納得して答えられるべきです。それがそもそも彼を権威にしているのではないでしょうか？

誰かが彼の人生のすべてに対して迷信的な信念を持っているからといって、彼が正しいというわけではありません。覚えておいてください、中世では、人々は地球は平らであり、それらの独善的なロバの一部は疑う者を殺すことを正当化したとさえ感じていました。疑い深い人は正しかったことが判明した。悪いレビューはこれで終わりです。

悪いレビューを恐れないでください。色を判断する盲人を信頼しますか？

上記の良い回答は、「ベストプラクティス」や「より保守しやすい」などの応答が何かを学ぶ機会であると付け加えます。「違いを理解できるように、なぜその方法が最適なのか例を挙げていただけますか？」または「他の方法よりもこの方法のほうがどのような状況で保守性が高いので、そのように前もって計画することを学ぶことができますか？」

先輩が正しければ、例をあげることは簡単です。もし彼がオウムなら...彼にスコーキンを止めるためにクラッカーを与えて、あなたが最高だと思うことをしてください。別の方法で注文されるまで。

高齢者の役割がメンターである場合、尋ねられたときに理由を説明します。

HLGEMとJarrodが前に言ったように、これは本当に変装した祝福です。彼らの答えは両方とも素晴らしいです、そして私はいくつかのポイントを加えたいです。

リードはドメインにないため、リードはミドルウェアについてあまり知らないため、アプリケーションの一部について重要な決定を下すことができます。また、アプリケーションがどのように進むべきか、製品ユーザーが何を望んでいるか、マネージャーが製品チームから提示された状況にどのように対処したいかについて、マネージャーと話し合います。アプリケーションでそのような知識を得る人の数を教えてください。

大規模なチームにいるときは、チームメイトやリードから確実に助けられますが、その種のことは一般的にリードを通り抜ける可能性があるため、マネージャーの考え方や製品チームの考え方に関する知識はありませんチームの一部の上級開発者。私は一人のプロジェクトは持ち運びがちょっと難しいと思いますが、コインの反対側がとても素晴らしいのなら、なぜチャンスを逃すのでしょうか。学ぶことができることを学び、できる限り楽しみ、それが困難になったら、ジャロッドが言ったようにマネージャーを説得するか、状況に応じて新しい仕事/プロジェクトを見つけてください。

あなたはそのような人とあなたのキャリア全体に対処するつもりです。また、コーディングの問題に対する最善のアプローチについて意見が分かれる人も多くいます。私が長年私のために働いたと思う最高のことは、彼らが問題を押し続けているなら、彼らと率直になって、あなたがさまざまな可能な解決策の中で彼らの解決策を検討したことと、あなたがその解決策を感じたことを伝えることです落ち着いたのは、あなたがこの状況で最良のアプローチだと感じたものでした。

今、あなたが毎回彼らのアドバイスに反することを選んだ場合、時々あなたは時々いくつかの波立たせられた羽を滑らかにするために時々彼らの「アドバイス」を与えて使う必要があるかもしれません。彼らがあなたの入力を毎回拒否していると感じない限り、それはあなたとあなたの間の平和を維持するのに大いに役立ちます。

また、彼らは上級開発者であり、あなたが持っているよりも長くその環境で働いていることを考慮してください。実際のコーディングは、多くの場合、ベストプラクティスやコミュニティで受け入れられている標準に適合していません。彼らが完全に明確に表現できない特定の方法で何かすることを勧めた理由があるかもしれません。そのため、あなたがそれらに同意しない場合でも、あなたのソリューションがより良いと信じているという事実だけに基づいて、彼らのアドバイスを手に負えないようにしてください。

バランスがすべてです。コーディングのバランスだけでなく、チームのバランスも重要です。多くのプロジェクトが失敗したのは、開発者がそれを行うことができなかったためではなく、友好的に協力する方法を見つけることができなかったためです。

私の個人的な経験からいくつかのものを提供したいと思いますが、これはjzdによってここに投稿されたものに対する補足的な答えと見なされるべきです...

1. 別の上級開発者に尋ね、
2. 自分で調査を行います。

ある職業上の約束で、私は先輩から指導を受けることになっていた。彼はいくつかのことを知っていましたが、正直なところあまり知りませんでした、残念ながら彼はそれを知りませんでしたので、彼は答えに非常に自信がありました。どういうわけか彼が言ったことは間違っていると感じた。彼がしたことは、私が受けたMS認定で言及されたベストプラクティスに反していたという証拠がいくつかありました:-)。その後、私は他の会社で働いている他の人に尋ね始めました（当時はstackexchangeは稼働していませんでした）。答えを比較するためにブログを読み始めました。

私が間違っていたら、それは素晴らしいことです。なぜなら、私は自分の行動を変えるだけでしたが、そうではなかったからです。

ここ数年、私が働いているほぼすべての会社、私が取り組んでいるほぼすべてのプロジェクト、（スキル/経験レベルに関係なく）ほぼすべての新規雇用者が何か「異なる」ことを望んでいることに気付きました。

それは、コーディング標準、全体的なアーキテクチャ、言語、または方法論かもしれません。しかし、それは常に何かです。多くの場合、「エンドユーザーにとって、すべてがより良く文書化されるべきではない」という明白なことを述べているだけです。

あなたへの私のアドバイスはあの男ではない。

いつか、あなたはそれらの決定を下すために雇われて給料を払われるキックバット上級レベルの男になるでしょう。その日が来たら、行きましょう！その日まで、あなたの立場が何であるかを理解してください。上司がいますが、私の仕事全体が上司を幸せにすることです。私の賃金等級の外で下された決定を推測することではありません。本当にわからない場合は、上司/監督者に相談して調べてください。

ただし、一般的に言えば、チームの半分が時代遅れのアプローチ、チームの1/4が新しいアプローチ、チームの1/4が最先端の開発を試みているよりも、全員に時代遅れのアプローチを採用する方がはるかに優れています、まったく新しいアプローチ。

私は明らかに引き出されるべきだと思う、これらの全ての底流があります：好戦ことはありません。彼との関係を維持してください。彼のアドバイスを一粒の塩で取り、本やこのようなサイトで検証することは素晴らしいことですが、彼を攻撃しないでください。彼が上級開発者であり、多くのプロジェクトを経験している場合、彼はバカではなく、彼から学ぶべきことがたくさんあります。あなたはすでにやったように見えるので、彼の視点を理解したいというあなたの願望を表明してください。あなたが彼が間違っていると確信していて、あなたが正しいとしても、反対の可能性を受け入れてください（あなたはすでにこれを理解しているようです）。彼が間違っていることを証明しようとしているからではなく、彼の視点をよりよく理解したいからと主張していることを明確にしてください。

質問してもすぐに返事が来ない場合や、答えがあいまいで役に立たない場合は、彼があなたを吹き飛ばしていると思い込まないでください。ここですでに述べたように、彼は忙しく、ストレスを感じているかもしれません。

忍耐することも素晴らしいことです。頭の中で別のやり方でやるべきだと思うことのリストを保持し、適切なタイミングでそれらを提示してください。「ベストプラクティス」に加えて、提案の正当性があることを確認してください。そして、物事を正しく行い、間違いを犯さないように注意してください。そうすれば、後で議論をするときに信頼性が得られます。

これまでのところ、私は彼に耳を傾け、カウンターポイントを上げることで問題を回避しようとしました、彼は元のポイントを再び上げます（ほとんどの場合、彼はベストプラクティスと言いますが、よりメンテナンス性がありますが、それ以上は進みませんでした）、私は。 ..自宅で考えてみてください。しかし、私はまだ確信していません。しかし最近、彼は...私のコードを見て、なぜ彼の提案に変えないのかと尋ねました。これは2〜3週間で3回目です。

（アクション用にわずかに編集されています。）

この部分は私に関係しています。自分が正しいかどうかを確認する1つの方法は、彼が言っていることを理解することです。私が読んだもの（私の歴史では、他の人は異なるかもしれません）は、メンターが言っていることを理解しておらず、明確化を求めていないジュニア開発者です。それを理解する1つの方法は、明確にするように彼に依頼することです。または、なぜこれが私たちのコードよりも保守しやすいのですか？これに対する彼の答えがわからない場合、彼が良いアドバイスをしているかどうかは本当にわかりません。

私が本当に心配しているのは、彼が何度も変更するようにあなたに頼んだが、あなたはそうしていないということです。これは彼の側から見た一例です。彼はあなたに変更を要求し、あなたはその理由を尋ね、彼はあなたに（有効な、彼の心に）理由を与え、あなたは変更を拒否します。あなたは明確化を求めないので、彼はあなたがその理由を理解していると仮定し、それを変更するには怠tooすぎるか頑固すぎるかのどちらかです。私を信頼してください。この方法で評判を得るよりも、質問する方がずっと良いです。

いくつかの考え：

1 /動作しますか？彼のやり方はうまく機能しているか？彼のやり方が劣る客観的な理由はありますか？

客観的な理由から、私はあいまいさなしに測定できるもの（パフォーマンス、バグ、コードの長さ...）を意味します。彼のソリューションが機能し、それが貧弱なソリューションであることを示す客観的なメトリックがない場合は、自分でやります。彼の方法はより優れています...それはおそらく他のコードベースとより一貫性があり、彼があなたの仕事を使用/再利用するのが簡単になるからです。あなたはそれを好きではないかもしれませんが、それはそれが何であるかではありませんか？

うまくいかない場合、または重要な測定基準を下回っている場合は、それを実装し、彼のソリューションをあなたのソリューションと比較して、あなたは自分のやり方を試したことを伝えますが、それをうまく実行することはできません（メトリックを与えます）実装を間違えた場合、または知らない要件がある場合

2 /スタープログラマーは言う...どうしてそんなことするの？有名なプログラマーは、計画、設計、OOP対手続き、ユニットテスト、例外処理、ソース管理など、多くの基本的なテーマについて互いに対立しています。

2つのソリューションの作業性の唯一の違いが、それを好む人だけである場合は、スキップしてください。あなたが好きではないパラダイムで働くことによって必要とされる精神的なトレーニングの恩恵を受けるかもしれません

あなたはあなたになりたい人からのアドバイスのみを取るべきだという考えに基づいて、答えはあなたが彼/彼女のようになりたい場合、上級のアドバイスは良いということです。

私の問題のほとんどは、フォーラムに投稿したり、他の人からの返信を受け取ったりすることで分類しており、このように約1年間生き延びています。

そのような状況ではどうすればよいですか？

正直に言うと、これは多くの技術的な仕事のようなものです。必要な場合は、自分で難しい問題を解決できる自発的である必要があります（インターネットとそれが住む人の場合は助けが必要です）。

コードレビューを取得し、アーキテクチャ設計のヘルプを取得するという観点からは、優れたマネージャーがいる場合でも、「静的変数には接頭辞s_を付ける必要がある」以外のコードレビューはほとんどありませんでした。

学び、学ぶ方法を学ぶ機会をとってください。これらは、将来使用できるスキルになります。

経営陣があなたが本当に仕事を成し遂げる能力を本当に理解していないと少しでも考えるなら、あなたはおそらく間違っているでしょう。経営陣はおそらく、彼があなたに取って代わり、あなたの仕事を引き継いだ場合、あなたの現在のリードは完全に役に立たないことも理解しています。

彼らがあなたを移転しなかった本当の理由は、あなたが彼らに提示するあなたの挑戦のすべてにもかかわらず、あなたがまだ仕事のための最高の人だからです。彼らは明らかにあなたの仕事を他の誰かに引き渡すリスクを負いすぎます。

経営陣の知性を過小評価しないでください...

彼らはほとんどの開発者が彼らに信用を与えるよりもはるかに賢いです。私は管理を開始するまでこれを理解していませんでした。彼らはおそらくあなたのリードが本当に役に立たないことも知っていますが、おそらくその問題に対処するには無力です。

絵を描いてみましょう。会社で5年の経験を持つリードAは無能です。マネージャーはこれを知っており、上司にリードAを解雇することを推奨しています。マネージャーAは、特にリードAが無益のために支払われていた肥大化した給料を持っているので、特に悪いように見えます...

ここに別の潜在的なシナリオがあります。リードAは重要な誰かと親しい友人です。彼は政治的に熱すぎて引き受けられません。

いずれにせよ、大規模な組織が無能な人々を敷物の下に追い詰め、忙しい仕事を与え、あまりにも大きなダメージを与えることができない「経験」の年にふさわしい偽の力を与えるのは簡単です。残念ながら、多くの組織は、実際に問題に対処するのではなく、これを行うことを望んでいます。

もちろん、この理由は、この種の組織のマネージャーは、この種の人々が組織にもたらす可能性のある長期的な問題に対処するよりも、常にこのような方法で悪い才能に対処する方が良いからです。

したがって、近視眼的で潜在的に非倫理的ですが、多くの開発者が実際に信用しているよりも少し賢いことを認めなければなりません。

ああああ この質問は多くのことを思い出させます。まず、最後の職場でマネージャーの一人と仲良くなれなかったと言います。それは人格の問題ではありませんでした。これはコミュニケーションの問題でした。私はXYZと言いました、そして、その特定のマネージャーは私がABCとして言っていたことを中断します。私はそのマネージャーと1年以上働いていなければ、うまくコミュニケーションできません。

この先週末。ある人がシングルトンについて私と議論/反対しました。私は、それらは良くない、決して使われるべきではなく、絶対に使う理由がないと言った。私は彼をリンクさhttp://www.gmannickg.com/?p=24し、より深みの記事では、へのリンク議論の数日後。別のプログラマーの日（DudeB）は、適切な場合にのみシングルトンを使用することに言及しています（「never」で追加しました）。DudeBはそれについて何も言わなかったが、DudeBはすべてのスレッドがシングルトンにアクセスしているため、DudeBはメモリ競合のあるプロジェクトに属していると言った。これについて言及した後、記事を示し、メモリ競合について言及した後、私が議論した人は、私がシングルトンについて話すのが好きではないので、同意したことに同意する必要があると言いました（まだこのドーを書いています）

ポイントです。この男のように、あなたは完全に間違っている可能性があります（コメントで私とシングルトンに反対する人がいるかもしれません）。上級プログラマーであるマネージャーとの私の状況では、明確に求められたことを実行しただけで、その職場で品質を二度と重視しませんでした。私は許可されたときに好きなことをしましたが、いつも私に頼まれたことをしましたが、同意しない場合は少なくとも一度は持ち出します。

私はこれについて完全に異なる/物議を醸す意見を持っています。

多くの場合、ほとんどの業界では利益を最大化し、損失を最小化するという最終目標を人々が追跡していません。私はこれが無情に聞こえることを知っています（そのためネガティブなポイントです）が、結果を出そうとしないなら経験とs明さはほとんど関係ありません。

人々は、会社の直接的な結果にほとんど影響を与えない、非常に間接的な微妙な事柄に追いつくことができます。

あなたが何かについて正しいと思うなら、あなたの最善の策は、それがより良い測定可能な結果を生み出す方法を示すことです。

私は最初にそれを試してみますが、一日の終わりには、少なくともより多くの経験と尊敬を得るまで、シニアへの抵抗は無駄になりそうです。これを学習体験として使用し、2年後には同じ方法を感じている場合は、別の会社に移動してください。それは、あなたとあなたの先輩の優れたアイデアを組み合わせて、新しい雇用主に印象づけることができるときです。もちろん、あなたはキャリアの早い段階で悪い決断だと感じたもののいくつかの理由に気づき始めるかもしれませんし、ある時点であなたのために働いている若い開発者がいるかもしれません。

[再投稿：何らかの理由でここに2つ目のアカウントを作成したため]

しかし、最近、彼は再び私に近づき、私のコードを見て、なぜ私が彼の提案に変えなかったのかと尋ねました。

これらが提案であるか、注文/指示/指令/その他であるかを明確にする必要があります。

提案=この方法で行う方が良いと思います。しかし、それはあなたの選択です。

注文/など =この方法でやりたい。そして、それは私の選択です。

それが本当に提案であるなら、あなたが望むようにして、あなたのコードを立ててください。それが注文の場合（そして、このメンターがこの方法であなたに対する権限を持っている場合）-彼らが言うようにします。