上級開発者からのアドバイスが悪いかどうかはどうやってわかりますか？
最近、私はジュニア開発者として最初の仕事を始め、この小さな会社で私を指導することを担当するより上級の開発者がいます。しかし、私が同意できなかった事柄について彼がアドバイスをすることも何度かあります（専門家によって書かれたトピックに関するいくつかの優れた本で学んだこと、いくつかのQ＆Aサイトで尋ねた質問にも同意しません）私と一緒に）そして忙しいスケジュールを考えると、おそらく長い議論の時間はありません。
これまでのところ、私は彼の話を聞いて問題を回避しようと努めており、現在の良い習慣として私が学んだことを基にしてカウンターポイントを上げています。彼は最初のポイントを再度上げます（ほとんどの場合、彼はベストプラクティスを言うでしょう、より保守可能ですが、それ以上進めませんでした）。それと自宅で研究しますが、変更を加えないでください（私はまだ確信していません）。しかし、最近、彼は再び私に近づき、私のコードを見て、なぜ私がそれを彼の提案に変更しなかったのかと尋ねました。 2〜3週間で3回目です。
ジュニア開発者として、私は彼を尊重する必要があることを知っていますが、同時に彼のアドバイスのいくつかに同意することはできません。それでも、プロジェクトを悪化させると思われる変更を加えるように迫られています。もちろん、経験の浅い開発者として、私は間違っている可能性があり、彼のやり方はより良いかもしれません、それはそれらの例外的なケースの1つかもしれません。
私の質問は、上級開発者のアドバイスが良いか、悪いか、あるいは良いかもしれないが、今日の文脈では時代遅れであるかどうかをより適切に判断するにはどうすればよいですか？そしてそれが悪い/時代遅れである場合、私が彼を先輩として尊敬しているという事実を維持しながら、彼の「プレッシャー」にもかかわらず彼のやり方でそれを実装しないためにどのような戦術を使うことができますか？
まず、シニア開発者として、私がプロジェクトを率いる後輩が率直に直接的な方法で懸念を私にもたらすことを期待しています。彼らが同意しない場合、それは私にはまったく問題ありません。場合によっては、私は彼らの懸念に対処します。ほとんどの場合、彼らの懸念は 捨てる 推論の簡単な説明は別としてください、開発者自身に対する無礼ではなく、次のような他の理由によるものです。
- ジュニアは、決定が行われたときにその決定を理解するためのすべての情報を手元に持っているわけではありません。場合によっては、少しの説明が、開発者が懸念を乗り越えて理想的ではない状況に対処するのに役立つことがあります。
- ジュニアは悪い情報を持っています。あなたが実際にはジュニアであることを忘れないでください。これは、ソフトウェアの面でティーンエイジャーであることに相当します。素晴らしいアイデアはたくさんあると思いますが、すべてを知っているわけではありません。私が最も抵抗力のあるジュニア開発者は、コード、会社、世界にとって何が最良かをしっかりと知っていると信じている開発者だと思います。これらの開発者は、謙虚さを身に付けることでより良いサービスを提供できます。
- 特定の方法で何かをするという決定は、先輩の頭の上でなされました。先輩は結局まだ誰かのために働いています。実際には、何かを行うためのより良い方法、何かを書くためのより効率的な方法、または仕事をするのに役立つより良いソフトウェア/ハードウェアがあるかもしれません。しかし、ビジネスは依然として決断を後押しします。ビジネスマネージャー、ディレクター、VPなどは、開発プロセスに影響を与える決定を行うことがよくあります。これらはシニアのコントロールを超えており、ジュニアがそれについて不満を言うとき、彼らがしていることはすべてシニアのストレスに加わっています。
- ちょうどフラットアウトシニアはそれを考慮に入れる時間がありません。締め切りがあり、途中でパターン、実践、行動を変更することは、その締め切りまでにコストがかかります。それはまな板の彼の首なので、製品を機能的かつ時間通りに出すことは「完全に書かれた」ことよりもしばしば重要です。
これらは、頭の中で思い浮かぶものです。アイデア、実践、コンセプトがあなたよりも上の人に却下または破棄される理由はたくさんあります。それらの多くは不快ですが、それらはすべて私たち全員が人間であり、私たち全員が意見を持っているという事実に要約されます。彼の意見は、たまたま現時点であなたの意見よりも数値的に優れています。
これらの概念を念頭に置いて、引き続きシニア開発者に懸念を持ち込む必要があります。空白を埋めることができる別の上級開発者を見つけます。多くの上級開発者がいるのは、人よりソフトウェアの方が優れているからです。彼らがインターンだったときにキスする相手のお尻を知っていたので、彼らがいるところもあります。メンターがそれが何を意味するかを実際に理解し、正直な意見を得る人を見つけます。彼らはあなたに同意せず、あなたが持っていない空白を埋めます。彼らはあなたに同意し、あなたの大義を結集するか、あなたの状況をより良くするのを助けるかもしれません。
どんな種類の反乱も起こすべきではありません。自分のやり方が正しいと心に信じている場合でも、従うように指示が与えられているので、従う必要があります（明らかに違法でない限り）。これらの指示に従うのに問題がある場合は、このような動作のパターンを発見して、あらゆる種類のソフトウェアを製造する非常に多くの企業で非常に蔓延しているので、その理由を考えてみてください。
あなたの最善の選択肢は、倫理的かつ専門的に仕事を続けることです。模範的な方法で完了するように求められているソフトウェアを入手し、それから昇格することで状況を回避します。プロモーションが来ない場合は、他の部門や会社で機会を追求するための豊富なリファレンスと経験を持っています。
上級開発者を尊重してください。彼はあなたよりもプロジェクトの成功に向けて進んでいます。彼には責任があるので、彼にも権限を与えます。彼が何かを変えると言ったらそれをしなさい。
そうは言っても、すでにあるような問題に遭遇したときは、遠慮なく懸念を表明してください。
最後に、彼と一緒に座って、ここに投稿したのと同じ質問を彼に説明します。多分あなたは何か大きなものを見逃しているかもしれません、多分彼はあなたの提案をもっと開くでしょう、どちらにせよ、あなたが彼のアドバイスが貧弱だと思うなら暗闇の中で彼を保たないでください。
これが発生した場合、必要なのは上級開発者と会話するです。おそらく彼は、コードや技術/ビジネス要件についてあなたが知らないことを知っています。もしそうなら、あなたはそれを学ぶべきです。
非公開で行います。それは挑戦的な権威とみなされるかもしれません、そしてそのようなことは一対一で行われるのが最善です。彼の年功序列を認め、尊重することによって妥協し、協力する意欲を示しますが、質問への回答を得るには粘り強くあります。闘争的な枠組みからではなく、協調的な枠組みから状況に取り組みます。あなたは彼にあなたにメンターをするよう頼むことを考えるかもしれません。
結局のところ、自分の考え（公平にするために、比較的新しく、テストされていない）と彼の考えのバランスをとる必要があります。おそらくあなたは本当に正しいかもしれませんが、より知識豊富な決定を下すことができるように、より経験豊富な人々から学ぶために最善を尽くす必要があります。優れたシニア開発者は、ジュニア開発者とさえ協力し、メンターし、学ぶ機会を歓迎します。また、彼らが間違っていることを知っているため、建設的な方法で彼らのアイデアに挑戦することを歓迎します。
あなたがよく言う方法は常識的なアプローチによるものです。上級開発者mayはプロジェクトについてはよく知っていますが、物事を行うための正しい方法についてはあまり知らない可能性があることに注意してください。あなたは彼があなたに何をするように言っているかを測定する必要があります-彼が言ったことが何に直面してもうまくいかない場合、彼はあなたに悪いアドバイスをしていますhisより良い主張（すなわち、彼より年上の人々;必ずしもあなたの会社ではない）。 ..私は、ソフトウェア開発の正しい方法、または少なくとも業界で受け入れられているベストプラクティスについての本を頻繁に投稿または執筆している有名な「有名人」開発者について話しています。
上級開発者（または任意の開発者）からの「悪いアドバイス」の例を次に示します。彼らが疎結合とは何か、なぜそれが良いのかをまったく知らず、すべてのコードを書き込むように指示された場合、たとえば、コード-ASPXファイルの背後には、上級開発者が無知であり、彼のアドバイスを聞いてはならないことは明らかです。
一方、システム内の特定のモジュールがどのように機能するかを彼が言っている場合、適切な開発原則に直面して口に出さないようにもう一度聞くのが最善の場合がよくあります。
私の経験則は次のとおりです。会社の上級開発者は、在職期間が最も長い開発者かもしれません。彼は本当のスキルを持っていないかもしれません。彼はあなたの分野で最も尊敬されている開発者の何人かが言うことに反対することを言っていますか？（彼よりはるかに多くの経験を持ち、はるかに有能で尊敬されている人々）もしそうなら、非常に極端な状況でない限り、彼のアドバイスが悪い可能性があります。
非常に偏った見解に対する反対票/意見の不一致を完全に期待しています。
上級者が業界のベストプラクティスを無視している理由を説明できない場合は、そこで時間を無駄にしないでください。脅迫されすぎて前進することはありません。とにかく、悪いコードの山を維持するのに時間をかけたいですか？
ほとんどの開発者は、大学を卒業すると読書を停止します。あなたはそうではないので、あなたはすでにトップ10％にいます。最近はたくさんの機会があります。あなたの町に仕事の市場がない場合は、より良い町を探してください。
うわーそれはあなたが輝き、あなたのスキルを誇示する素晴らしい機会です。私のキャリアの早い段階で、私には決定を下すことができない上司である人がいました。そのため、その機会を利用して、次の上位レベルの作業を行う方法を学びました。それは私を昇進させました。同じことをする必要があります。
上級開発者の視点を理解するのは難しいかもしれませんし、そうです、彼は物事を間違った方向に導いているかもしれませんが、大規模なプロジェクトに関しては、一貫性がより重要です。
50人の開発者全員が独自のコーディングスタイル、標準、方法論、およびデザインパターンに従っていると、まったく混乱するでしょう。物事が間違って行われている場合、多くの異なる種類の間違いや正しく行われたいくつかのことよりも、常に一貫して間違っている方が良いです。
メンテナンスを実行したり、機能を追加したり、「間違った」ものを修正したりするときは、既存の設計の問題が事前にわかっていると、はるかに簡単です。
敬意を払わずに同意するのは良いことですが、最終的には列に並ぶのが最善です。不正になるチームの誰もチームプレーヤーとは見なされません。
シニア開発者として、このタイプの受動的な積極的なnitの選択は私を狂わせ、対決した後は私にあなたに悪いレビューをさせます。完璧な解決策は、チームが一緒に生活できるソリューションです。
スタイルに関しては、これはあなたのスタイルガイドとあなたのオリジネーションによって決定されたベストプラクティスによって決定されるべきです。あなたがそれについて情熱を持っていると主張しているが、それが決定されたら、それを使ってライブになり、チームの境界内で作業します。
あなたはそれほど良い状況ではありませんが、HLGEMが指摘したように、これらの立場を変装した祝福に変えることができます。あなたの質問は多面的であるため、私は部分的にそれに取り組みます。
彼は知らないと思う。同時に、彼は私に傲慢さを見せつけようとしますが、私は質問に対してあまり彼に頼りません。
これは本当かもしれません。 decadesのために業界にいて、有能なソフトウェアリードではない開発者の発疹があります-開発からorメンタリングの観点（違いがあります）。経験は、新鮮な課題に取り組み、新しいアイデアを試し、新しいスキルを学ぶことから生まれますが、プログラマーのmajorityは、忠実なVisual Basicおよび= Javaツール。寒い灰色のオフィスで世界が競争するのを見たことはありません。
これに問題はありませんがあります。多くの開発者にとって、これはすべてこれまで望んでいたことであり、状況に完全に満足しています。ただし、開発者をリードすることはもちろん、次世代のプログラマーを育成するための理想的な状況でもありません。
Bravadoと傲慢は、不適切な点をカバーしようとする防御メカニズムとなる可能性があります。それをどのように扱いますか？ しないでください真正面から向き合う-リードが無能で、上司が状況を修正することに消極的である場合あなたはそれに耐えなければならない。それはロールオーバーして死ぬことを意味するわけではありませんが、誰かが良いリードになることはできませんforce。
ただし、彼は私のコードをレビューするだけであり、彼のコメントのほとんどはコーディングガイドラインに関連しています
これは、彼が良いプログラマではないかもしれないという点で、あなたが正しいと私に思わせるものです。それは彼が現時点であなたよりも優れたプログラマーではないということではありません（少なくとも、彼は業界に長くいるために、より多くの経験と露出を持っているでしょう）再び、それは効果的なリード。ガイドラインはすべて適切で優れていますが、コードの機能、有効性、効率に次ぐものです。
このような状況ではどうすればよいですか？
私はこの状況をマネージャーに通知しました、そして私は彼に私のリードを変更するように頼みました、しかし彼は毎回「はい」と言いますが、彼は真剣な行動をとっていません。
これらすべての具体的なポイントをマネージャーに列挙し、それをバックアップする具体的な例を挙げましたか？単に彼のところに行って「新しいリードが必要です」と言っただけでは、彼はあなたを真剣に受け止めず、技術的な問題ではなく「対人関係の問題」として認識しません。この状況での多くのボスの反応は、それが「うまくいく」ことを期待してそれを無視することです。
ここにいくつかの提案があります。
- あなたの状況で摩擦しないでください-火の試練は楽しいものではありませんが、あなたのキャリアの後半のためにいくつかの重要な研究スキルを教えてくれます。
- よりリードするようにリードを押し上げます。これを行う慎重かつ丁寧に。プッシュし続け、彼が屈するまでしつこいようにします（これは実際には人生の多くの状況で機能します）。
- あなたのリードされないが関与する場合は、あなたを助けることができる他の人がいるかどうか確認してください。搾乳時間のみに関係するスウェットショップで作業しているのでない限り、あなたの会社は、いくつかのロープを示し、コードをレビューした経験のある別の開発者を気にしません。
- 新しい仕事に目が離せないところから始めましょう。あなたが「立ち去らなければならない」状況にあるとは言いませんが、プログラマとしてのyour開発をより真剣に受け止める場所にいることがキャリアに害を及ぼすことはありません。
特定の問題を解決するより良い方法がある場合は、単にDO ITと入力します。
あなたのコード/ソリューションがあなたの最良の議論であるとしましょう。それ以外の場合は、言われたことに固執します。
適切な事例
私がジュニアだったとき、コードの特定のセクションが最高ではない状況がありました。私はそれについて単に議論するのではなく、単にそれを改善しました[〜＃〜]その後[〜＃〜]先輩に結果を示しました。コードは常に王様であるので、彼はそれを受け入れました。
もちろん、経験の浅い開発者として、私は間違っている可能性があり、彼のやり方はより良いかもしれないので、私の質問は、上級開発者のアドバイスが良いものか悪いか古いものかを判断するためにどのようにすればよいかです。
あなたは経験豊富な開発者になることができます。そうするまでは、後輩としてのあなたの直感が正しかったかどうかを判断するのに不十分であり、それまではそれは問題になりません。
それまでの間、Joel Ethertonの回答を読んでください。
「自分のやり方で実装しない」ことを試みないことを強くお勧めします。
これまでのところ、あなたは正しいことをしたようです。あなたは謙虚で、相手を育てました。単にあなたが彼の方法に同意しないのか、あなたが同意せずに代替案を提示したのか、あなたの質問からはわかりませんでした。結論としては、他の人のアプローチを打ち倒そうとするときは、常に明確で考え抜かれた選択肢を提供します。彼がそれを見るかもしれないように、あなたはうまくいくかもしれない良い考えを持っています、そして彼はうまくいく考えを持っています。
どのような立場にあっても、私たちは常に次善のことをしなければなりません。あなたが本当にそれが気に入らない場合は、あなたがしたようにしてそれを育てることができます。その後、そのボスの方法または高速道路。明るい面では、後輩としての決定が下がるリスクの多くから隔離されています。
戦いを選んでください。 1時間の作業について話す場合は、次の段階に進むまでコードを変更する必要があります。次に大規模なプロジェクトを取得するときは、開始する前に事前にアイデアを発表する機会を求めてください。少し時間をかけて素晴らしいデモやプロトタイプを作成してください。
驚いたことに、私がやったことは質問をやめることです。別のオプションが与えられたとき、私は脱線して彼のやり方でそれを行いますが、それに私自身の才能を加えます。これを学習体験として使用して、能力を高めながら、古い学校を維持する必要性を和らげます。
結局、すべての上級開発者が物事の新しい方法に注意を払うわけではありません。彼らは時々、20年前に始めた言語にぴったりの古い方法を持っていますが、今日の世界ではハック、または「悪臭を持っている」と考えられています。
これは、続けるための恐ろしい方法のように聞こえるかもしれませんが、そうです。しかし、私は先輩から物事のやり方から多くを学びました。しかし、これは本当に私の意見です。最終的には、仕事に満足し、気晴らしと緊張を低いレベルに保つ必要があります。そして、物事に反対しないことで、あなたはストレスがずっと下がるのを見るでしょう。
そこに年功があるので年配の人を信用しないでください。できるだけ頻繁に権限に挑戦します。所管官庁は、あらゆる質問に説得力をもって答えることができなければならない。それがそもそも彼を権威にしているのではないでしょうか。
誰かが彼の人生のすべてに対して迷信的な信念を持っているので、彼が正しいとは限りません。中世には、地球は平らであると人々は信じており、それらの自尊心のあるロバの一部は、疑い深い人々を殺すことは正当化されるとさえ感じていました。疑い深い人が正しかったことがわかりました。悪いレビューのためにそんなに。
悪いレビューを恐れることはありません。色を判断する盲人を信用しますか？
上記の良い答えは、「ベストプラクティス」または「より保守しやすい」のような応答が何かを学ぶの機会であることを追加します。 「違いが理解できるように、その方法が最適な理由の例を教えてもらえますか？」または「この方法が他の方法よりも保守しやすいので、私はそのように前もって計画することを学ぶことができますか？」
先輩が正しければ、例をあげるのは簡単です。彼がオウムの場合...クラッカーを鳴らしてスコーキンを止め、あなたが最善だと思うことをしてください。他に注文するまで。
シニアの役割がメンターである場合は、尋ねられたときに理由を説明します。
HLGEMとJarrodが前に言ったように、これは本当に変装の祝福です。彼らの答えはどちらも素晴らしいので、私はいくつかのポイントを追加したいと思います。
あなたのリードはあなたのドメインにないので、あなたのリードはミドルウェアについてあまり知らないので、あなたはアプリケーションのあなたの部分のための重要な決定のいくつかをすることになります。また、アプリケーションがどのように進むべきか、製品のユーザーが何を望んでいるのか、および製品チームによって提示された状況に上司がどのように対処したいのかについて、上司とのやり取りもあります。アプリケーションでそのような知識を得る人は何人いるのか教えてください。
大規模なチームにいるときは、必ずチームメイトやリードからの助けがありますが、そのようなことは一般的にリードを通過し、チームの一部の上級開発者。私は一人のプロジェクトが運ぶのが少し難しいのに同意しますが、コインの反対側がとても大きいのでなぜチャンスを逃すのですか？習得できることを学び、できる限り楽しんでください。難しい場合は、ジャロッドが言ったように上司を説得するか、状況に応じて新しい仕事/プロジェクトを見つけてください。
経営陣があなたが本当に仕事を成し遂げる能力があるかを理解していないと少し思ったなら、あなたはおそらく間違っています。経営陣はおそらく、現在のあなたのリードが、あなたに取って代わり、あなたの仕事を引き継いだ場合、完全に役に立たないことも理解しています。
彼らがあなたを再配置しなかった本当の理由は、あなたが彼らに提示するすべての課題にもかかわらず、あなたはまだ仕事の最高人だからです。彼らは明らかにあなたの仕事をあまりにも高く評価して、他の人にそれを渡す危険を冒しません。
管理のインテリジェンスを過小評価しないでください...
彼らはほとんどの開発者が彼らに信用を与えるよりもはるかに賢いです。管理を開始するまで、私はこれを理解しませんでした。彼らはおそらくまたあなたのリードが実際にどれほど役に立たないかを知っていますが、おそらくその問題に対処するための無力です。
絵を描いてみましょう。会社での5年間の経験を持つリードAは無能です。マネージャーはこれを知っており、上司にリードAを解雇するよう勧めています。上司は、彼がその能力がない場合、何年も前に対処されなかった理由を尋ねます。特にリードAの給与が肥大化し、給付がなかったため、マネージャーの見た目が悪くなりました...
ここに別の潜在的なシナリオがあります。リードAは重要な誰かと親しい友人です。彼は政治的に熱くて引き受けることができない。
いずれにせよ、大規模な組織が無能な人々を敷物の下で一掃するような長い間続くミスがあると、多すぎるダメージを与えられない長年の「経験」にふさわしい忙しい仕事と偽の力を彼らに与えることができます。残念ながら、多くの組織では、この方法を採用する方が望ましいでしょう実際に問題に対処します
もちろん、その理由は、この種の組織のマネージャーは常に、短期間にこのような方法で悪い才能に対処する方が、これらの種類の人々が組織にもたらす可能性がある長期的な問題に対処するよりも優れているためです。
したがって、近視眼的で潜在的に非倫理的ですが、多くの開発者が実際に認めているよりも少し賢いことを認めなければなりません。
私が明確に引き出されるべきだと私が思うこれらすべての底流があります： 戦闘しないでください。彼との関係を守ってください。彼のアドバイスを細かく見て、本やこのようなサイトで検証するのは素晴らしいことですが、攻撃しないでください。彼が上級開発者であり、多くのプロジェクトを経験している場合、彼はばかではなく、彼から学ぶことはたくさんあります。もうやり遂げたようですが、彼の視点を理解したいという気持ちを伝えてください。あなたが彼が間違っていてあなたが正しいと確信している場合でも、反対の可能性を受け入れてください（すでにこれを理解しているようです）。あなたが彼の見方をよりよく理解したいのではなく、彼が間違っていることを証明しようとしているのではなく、あなたが議論していることを明確にしてください。
彼があなたに質問したときにすぐに返答しない場合、または彼の答えが曖昧で役に立たない場合は、彼があなたを怒らせていると思い込まないでください。ここですでに述べたように、彼は忙しいか、ストレスを感じるかもしれません。
我慢するのも素晴らしいことです。違ったやり方でやるべきだと思うことを頭に入れておき、適切なタイミングで提示します。 「ベストプラクティス」以外の提案の正当性があることを確認してください。そして、正しいことを行い、間違いを犯さないように注意してください。そうすれば、後で議論をするときに信頼性を得ることができます。
これまで私は彼の話を聞き、カウンターポイントを上げることで問題を回避しようとしてきました。彼は元のポイントを再び上げます（ほとんどの場合、彼はベストプラクティスを言うでしょう、より保守可能ですが、それ以上は進みませんでした）。 ..家で考えてみてください...まだ確信がありません。しかし、最近彼は...私のコードを見て、なぜ彼の提案に変更しないのかと尋ねました。 2〜3週間で3回目です。
（アクション用に少し編集されています。）
この部分は私に関係しています。あなたが正しいかどうかを確認する1つの方法は、彼の言っていることを理解することです。私が読んだのは（私自身の歴史では、他の人は異なる場合があります）、メンターが言っていることを理解しておらず、説明を求めていないジュニア開発者です。あなたがそれを理解することができる一つの方法は、明確にするように彼に頼むことです：これはそれより良い方法は何ですか？または、なぜこれが私たちのコードよりも保守しやすいのですか？これに対する彼の答えがわからない場合は、彼が良いアドバイスをしているかどうかは本当にわかりません。
私が本当に心配しているのは、彼が何度も変更するように頼まれ、あなたはそうではないということです。これは彼の側から見るかもしれない1つの方法です。彼はあなたに変更を加えることを要求し、あなたは理由を尋ね、彼はあなたに（正当な、彼の心に）理由を与え、あなたは変更を加えることを拒否します。あなたは説明を求めないので、彼はあなたが理由を理解していると仮定し、怠惰すぎるか頑固すぎてそれを変更できない-どちらも上級開発者があなたについて考えるのは良いことではありません。私を信じて、このように評判を得るよりも質問をする方がはるかに良いです。
いくつかの考え：
1 /機能しますか？彼のやり方はうまくいっているか？彼のやり方が劣っている客観的な理由はありますか？
客観的な理由から、あいまいさなしに測定できるもの（パフォーマンス、バグ、コードの長さなど）を意味します。彼のソリューションが機能し、それが貧弱なソリューションであることを示す客観的な指標がない場合は、彼の方法で行ってください。彼の方法の方が優れています...おそらく他のコードベースとの一貫性があり、彼が作業を使用/再利用するのが容易になるためです。あなたはそれを好きではないかもしれませんが、それはそれがそうであるということではありませんよね？
それが機能しない場合、または重要なメトリックスでパフォーマンスが低い場合は、それを実装し、彼のソリューションをソリューションと比較して、あなたが彼の方法を試したことを伝えますが、うまく実行できず（メトリックスを提供）、彼に尋ねます実装を間違えた場合、または知らなかった要件がある場合
2 /スタープログラマーは言う...なぜいまいましいのですか？計画、設計、OOP vs手続き型、ユニットテスト、例外処理、ソース管理など）など、多くの基本的なテーマについて有名なプログラマーが互いに対立しています。
2つのソリューション間の実行可能性の唯一の違いが誰がそれを支持するかである場合、それをスキップします。あなたが好きではないパラダイムで働くことによって必要とされるメンタルワークアウトから利益を得るかもしれません
好きになりたい人からアドバイスをもらうだけでいいという考えに基づいて、その人のようになりたいなら先輩のアドバイスがいいと答えています。
あなたはそのような人々とあなたの全キャリアを扱うことになるでしょう。また、コーディングの問題に対する最善のアプローチについて意見が分かれる人もたくさんいます。私が長年にわたって私のために働いてきたと思う最高のことは、彼らが問題を押し続けている場合、彼らに前向きになり、さまざまな可能な解決策の中で彼らの解決策を検討したこと、そしてあなたが解決したのは、この状況で最良のアプローチであると感じた方です。
さて、あなたが毎回彼らのアドバイスに反対することを選択した場合、時々あなたはいくつかの波状の羽を滑らかにするために時々彼らの「アドバイス」を与えて使う必要があるかもしれません。彼らがあなたの入力を毎回拒否していると感じない限り、それはあなたの間の平和を維持するための長い道のりになるでしょう。
また、彼らは上級開発者であり、その環境であなたよりも長く働いていることも考慮してください。実際のコーディングは、多くの場合、ベストプラクティスやコミュニティで受け入れられている標準に対応していません。彼らがあなたが何かを完全に表現できない特定の方法で行うことを勧めた理由があるかもしれません。したがって、あなたが彼らに同意しない場合でも、あなたの解決策がより良いと信じているという事実だけに基づいて、彼らのアドバイスをすぐに却下しないようにしてください。
それはすべてバランスについてです。コーディングのバランスだけでなく、チームのバランスも重要です。多くのプロジェクトが失敗したのは、開発者がそれを実行できなかったためではなく、友好的に協力する方法を見つけられなかったためです。
私の個人的な経験からいくつかのものを提供したいと思います。これは、jzdによってここに投稿されたものに対する補足的な回答と見なされるべきです...
- 別の上級開発者に尋ね、
- 自分で研究してください。
ある専門職との面談では、私はシニアの誰かから指導を受けることになっていた。彼はいくつかのことを知っていましたが、正直言ってそれほど多くはありませんでしたが、残念ながら彼はそれを知りませんでした。どういうわけか、彼の言ったことは間違っていると感じました。彼がしたことが私が取ったMS認定で言及されたベストプラクティスに違反したとき、私にはいくつかの証拠がありました:-)。その後、私は他の会社で働いている他の人たちに尋ね始め（当時、stackexchangeは稼働していませんでした）、答えを比較するためにブログを読み始めました。
私が間違っていた場合、それは素晴らしかったのです。行動を変えただけなのですが、そうではありませんでした。
ここ数年、私が現在取り組んでいるほぼすべての会社で、ほぼすべてのプロジェクトに取り組み、ほぼすべての新規採用者（スキル/経験レベルに関係なく）が何か別のことをしたいと思っています。
それは、コーディング標準、全体的なアーキテクチャ、言語、または方法論の可能性があります。しかし、それは常に何かです。多くの場合、それは「エンドユーザーにとって、すべてがより適切に文書化されるべきではないのではないか」という明白なことを述べているだけです。
あなたへの私のアドバイスはあの男にならないでくださいです。
いつか、あなたはそれらの決定をするために雇われ給料を支払われるキックバット上級レベルの男になるでしょう。その日が来たら、それに行ってください！その日まで、あなたの立場が何であるかを理解してください。私には上司がいますが、私の仕事は上司を幸せにすることです。私の給与水準以外で行われた決定を推測することではありません。本当にわからない場合は、上司や監督者に相談して調べてください。
一般的に言えば、チームの半分が古いアプローチを採用し、チームの1/4が新しいアプローチを採用し、チームの1/4が最先端を開発しようとするよりも、古いアプローチを採用する方がはるかに優れています。 、まったく新しいアプローチ。
私が抱える問題のほとんどは、フォーラムに投稿したり、他の人から返信を得たりすることでソートし、このように約1年間生き残っています。
そのような状況ではどうすればよいですか？
正直なところ、これは多くの技術的な仕事のようなものです。必要な場合は、自分で難しい問題を（インターネットの場合は住人の助けを借りて）自分で解決できる自発的である必要があります。
コードレビューを取得し、アーキテクチャの設計を支援するという観点から見ると、優れたマネージャーがいても、「静的変数の先頭にs_を付ける必要があります」以上のコードレビューはありませんでした。
学ぶ機会と学び方を学ぶ;それらはあなたが将来使用できるスキルになります。
私はこれに関して完全に異なる/物議をかもす意見を持っています。
多くの場合、人々は、ほとんどの産業にとって、利益を最大化し、損失を最小化するという最終目標を見失っています。私はこれが無情に聞こえることを知っています（したがって、否定的な点です）が、結果を生み出すつもりでなければ、経験と賢さはほとんど問題になりません。
人々は、会社の直接的な結果にほとんど影響を及ぼさない、非常に間接的な細かい事柄に気を取られる可能性があります。
あなたが何かについてあなたが正しいと思うなら、あなたの最善の策は、それがどのようにしてより良い測定可能な---結果を生み出すかを示すことです。
[再投稿：どういうわけかここに2つ目のアカウントを作成したため]
しかし、最近、彼は再び私に近づき、私のコードを見て、なぜそれを彼のsuggestionに変更しないのかと尋ねました。
これらが提案であるか、注文/指示/ディレクティブ/何であるかを明確にする必要があります。
提案=この方法で行う方が良いと思います。しかし、それはあなたの選択です。
注文など=このようにしてほしい。そしてそれは私の選択です。
それが本当に提案であるならば、あなたが望むようにして、あなたのコードを立たせてください。それが命令である場合（そしてこのメンターがこのようにあなたに対して権限を持っている場合）-彼らが言うようにしてください。
ああああ。この質問は私に多くのことを思い出させます。まず、最後の職場でマネージャーの1人とうまくいかなかったと言います。それは人格の問題ではありませんでした。コミュニケーションの問題でした。私はXYZと言った、そしてその特定のマネージャーは私がABCとして言っていたことを妨害するだろう。私はそのマネージャーと1年以上働いていないと、うまくコミュニケーションをとることができません。
この先週末。男がシングルトンについて私と議論/反対しました。私はそれらは良くないので決して使用すべきではなく、絶対に使用する理由はないと述べました。私は彼を http://www.gmannickg.com/?p=24 にリンクし、 詳細なリンク先の記事 を議論の数日後にリンクしました。別のプログラマー（DudeB）の日は、彼が適切な場合にのみシングルトンを使用することに言及しました（これは 'never'で追加しました）。 DudeBはそのことについては何も述べていませんが、DudeBは、すべてのスレッドがシングルトンにアクセスしていたため、メモリの競合が発生しているプロジェクトに属していると言いました。これについて言及し、記事を示し、メモリの競合について言及した後、私が論じた男は、シングルトンについて話すのは好きではないので、同意することに同意する必要があると述べました（まだ私はこれを書いています）
ポイントは。この男のようにあなたは時々あなたは完全に間違っているかもしれません（たぶん誰かがコメントでシングルトンについて私に同意しないでしょう）。私のシニアプログラマーであるマネージャーとの状況では、私は明示的に求められていることを実行しただけで、その職場で品質を二度と真剣に受け止めませんでした。私は許可されたときに好きなことをしましたが、常に私に求められたことをしましたが、私が同意しない場合は、少なくとも一度はそれを取り上げます。
私は最初はそれを試してみて突き出しますが、結局のところ、あなたがさらに経験と尊敬を得るまで、シニアへの抵抗は少なくとも無駄です。これを学習体験として使用し、2年以上経過しても同じように感じる場合は、別の会社に進んでください。それはあなたとあなたの先輩の良いアイデアの組み合わせを使ってあなたの新しい雇用者を感動させることができるときです。もちろん、キャリアの早い段階で悪い決定であると感じた理由のいくつかに気づき始めるかもしれませんし、いつかジュニア開発者があなたのために働いているかもしれません。
質問どおりに質問しながら質問してもかまいません。優れた上級者は、ビジネス上の理由から、または単にタスク依存性の理由のために、必要になる前に物事を行うことの正当性を常に納得させることができない場合があります。しかし、あなたの懸念を認めるには時間がかかり、彼らがそれに対処できなかったときは認め、別の時にそれについて触れなければなりません。
私の最後の仕事で、私よりも1か月以上しかそこにいなかった別の開発者と一緒に働きました。彼は、同様のシステムに取り組んでいる他の企業でいくつかの既存の経験がありました。彼はとても落ち着いていて、頭が水平だった。それでも、彼は私にネイティブのソフトウェア開発者ではないような印象を与えました。 「ネイティブ」とは、時間の経過とともに彼が開発者の立場に徐々に落ち込んだことを意味します。あなたは彼がいくつかの分野でよく読まれていたが、いくつかの基礎が欠けていたと言うことができます。一見単純そうな問題に彼が苦しんでいたことは明らかでした。彼はソフトウェアに自分のやりたいことをさせることができたが、それを「手に入れられなかった」。
個人的には、「本で読んだ方がいい」という考え方は乗り越えられませんでした。多くの点で、私の以前の経験は私にその立場への不適合をもたらしました。自分が「高度すぎる」ためなのか、それとも別の道をたどったためなのかはわかりません。
彼と私は、ユニットテストの方法について継続的に議論しました。彼は、モンキーパッチを介した非常にホワイトボックスのアプローチを信じていました。私はモックと依存性注入でサポートされているブラックボックステストを好みます。彼のアプローチは脆弱なテストにつながると思いましたが、私の意見のいくつかは私のC＃の背景に左右されていたと思います。彼は常にPythonで働いていました。誰が正しかった？二人とも？私たち二人とも？
開発者を上級の地位に昇格させる場合、企業はより慎重になる必要があります。 1つの仕事で十分な経験を積むことは非常に困難です。優れた上級開発者は、利用可能なツールと、他のショップが同様の問題をどのように処理するかについて知る必要があります。最新のWebサイトを構築する方法、継続的な展開を適切に行う方法、ソース管理ブランチを管理する方法、分散サービスを構築する方法、またはNoSQLデータベースを使用する方法を学びました。本当に上級開発者になるには、新しい哲学、テクノロジー、プロセスを学ぶ必要があります。
結局、彼が私よりも長く滞在していた6か月は、彼に有利になりました。私はいつも彼の意志にこだわり、彼のやり方をテストしました。それが専門家の仕事です。私は学ぶためにそこにいました。それでも、ほとんどの開発者ではないように、彼は管理職に就きました。 3週間も経たないうちにミーティングがあり、段ボール箱を持って出て行きました。今、私はその場所が私を涙で退屈させていたので解雇されてうれしいです。
それは自己改善の環境ではありませんでした。残念ながら、支援することを目的としたポリシーは、厳格に従った場合に生産性に悪影響を与え始めます。私は何時間もそこに座って、他の人が私のコードをレビューするのを待っていました。行間と命名規則についてのコメントを得るためだけです。私が政策に反する提案を始めたとき...私は突然反逆者、反論者、扇動者というレッテルを貼られました。
私が理解しているように、あなたの開発リーダーは実際にあなたを監視するためにそこにいるだけです。「開発者を完全に彼自身に任せるのは無責任だからです」。しかし、彼には実際にあなたの作品をどのように判断するかについての手掛かりがありません。
それについて彼に話しましたか？たぶん彼もそれをしなければならないことに疲れている。
助言と助けが必要な場合は、代わりにチームメイトがあなたのプロジェクトの側であなたと協力するほうがより良い、より生産的な解決策ではないでしょうか？