誰が新しいプログラマを訓練するべきですか？ジュニアまたはシニアのプログラマー？
私のチームでは、多くの場合、最も上級のプログラマーに真新しいジュニアプログラマーのトレーニング/メンターを依頼しています。ただし、これらの同じ上級プログラマは、実際の重要な作業の大部分を行っているプログラマです。
私は、高い適性を示しているジュニアプログラマーが彼らの下に新しいプログラマーを連れて行くことが理にかなっていることをマネージャーに主張しようとしました。まず、上級開発者を解放して、より重要なイニシアチブに取り組むことができます（メンタリングは重要ではありません）。次に、それはジュニアプログラマーにそのような責任について期待され、彼らが教えることで何かを学ぶかもしれないことを彼らの仕事に少し誇りを与えるでしょう。最後に、上級開発者は後輩よりもはるかに多くの費用がかかるので、それは会社のお金を節約します。
どうやら、当初からこのチームで働いていた方法であるため、上司は説得に失敗しました。ある種のトレーニング/メンタリングが必須であるという決定が下されたと仮定すると、誰かが私にいくつかのより良い議論を提供したり、なぜ私が間違っているのか教えたりできますか？あなたのチームは何をしますか？
**年功序列は必ずしも能力を表すものではないということに同意できるので、「上級プログラマ」とは「トッププログラマ」を意味するものと想定してください。
私は前の会社でこのような状況にありました。上級開発者はほんの数人でしたが、彼らに割り当てられた他のタスクを実行できなくなるまで、ますます多くの後輩開発者を指導していました。しばらくして、シニア開発者が私たちのマネージャーにそれを持ち込み、ジュニアとシニアの中間にいる開発者がメンターとして行動することを決めましたが、難しい問題については、シニア開発者に尋ねることができました。
それはかなりうまくいきました。その前は、上級開発者の何人かは、仕事に挑戦していなかったため、新しい仕事を探し始めていました。その後、彼らは新機能に取り組み、物事を成し遂げることができました。あなたの上級開発者は状況をどう思いますか？
私の見解では、上級者になることは、ドメインの専門知識、メールのフッターのタイトル、またはどれだけの期間働いたかだけではありません。また、ジュニア開発者を助け、導くための考え方でもあります。そして、それほど多くのシニア開発者がメンタリングを行うのを許可するよりも、チームでより多くのシニア開発者を獲得するためのより良い方法は何ですか？
すべてのトッププログラマーがトップティーチャーであるとは限りません。トレーニングは、会社の「環境」（技術的なことだけでなく、組織的な連絡先）についても説明できる、概要を理解できる人が行うことをお勧めします。
すでに述べられていることのいくつかを繰り返しますが、私は2つの見解を持っています。
ビジネス：ビジネスとして、あなたは生産性とより低いリスクを望んでいます。上級開発者は作業の大部分を行っていますが、リスクを下げるシステムの知識を彼らに伝えてほしいと思っています。重要度の低いこと（ジュニア開発者を指導する）をするために、これらの高齢者に休息時間を与える必要があるため、生産性はそれほど影響を受けません。システムの他に、ジュニア開発者がまだ知らない、または把握していない分野も数多くあります。
尊重：新しい開発者を彼らの翼の下に連れて行くジュニアは、ブラインドを導くブラインドのようなものです。ジュニアはまだ他の人を教えることに責任を負うすべてのものに対応できていません。また、尊敬の念がないため、うまくいかない場合もあります。初心者のスキルセットと初心者のスキルセットはおそらくそれほど離れていないため、ジュニア開発者に対する尊重は問題です。しかし、問題への取り組みは別の話です。上級開発者が初心者や後輩を教えるという点では、尊敬の念はありません。私たちは皆、2人の個人またはチームで尊敬が欠けているとき、災害が起こるのを待っていることを知っています...
これを別の角度から見てください。ここのプログラマーの間でどのようなスキルと知識を伝えたいですか？上級プログラマーが実際の重要な作業のほとんどを行っている場合、誰がどのシステムを知っているかという点で、これは少し孤立していますか？後輩がシステムのことを知っているようにして、彼らが高齢者のバックアップになるようにすることは、ここで最も重要なことです。後輩にメンタリングをする高齢者は、私の心には一種の自然な形成のように思えます。
別のジュニアプログラマーを指導するジュニアプログラマーは、私の心にはまったく意味がありません。いくつかのジュニアプログラマーをペアリングすることは、ある意味で理にかなっています。 1人のアイデアだけでなく、2人が一緒にタスクを実行することは、チームがある意味で集まるより協調的な環境を促進するのに役立つだけでなく、非常に役立ちます。使用している環境によっては、これが意味をなす場合とそうでない場合があります。
まあ、チームの上級プログラマーが後輩よりも実際に取引を習得せず、チーム内でより長く、および/またはより高い社会的/政治的地位を持っている場合、実際、それは実際に大きな違いはありません誰でも-もしあれば-初心者を指導します。とにかく、それらはすべて同じレベルの平凡さに向かって引き付けられるでしょう... :
OTOH、先輩が世界の真の意味で本当に（少なくとも目立って近い）マスタープログラマーである場合、大きな違いを生む可能性があります。ジュニアは、ブロックにいる新しい子供にそれほどベストではない実践を簡単に教えるかもしれません。そして---（ベストプラクティスを学ぶことから始めるよりも、次善のアプローチまたは悪いアプローチを学ぶのははるかに困難です。
とはいえ、ジュニアに才能があり、特定のツール、テクニック、またはエリアに関して彼が何をしているのかを知っていることを確実に示した場合、彼は確かに有用なトレーナーになることができますその特定のエリア。
ただし、特定の観点からは、メンタリング/トレーニングの全体の目的は、高齢者がそれほど難しいタスクの一部を他の人に委任できるようにすることであり、そうすることで、彼らは本当に難しいことに集中できるようになります。これが起こるためには、彼らは実際にそれらのタスクとスキルを最初に仲間に教えて、それらをうまく教える必要がある。
簡単な答え：トレーニングを行う人は、トレーニングもしたい、トレーニングが得意な人である必要があります。
トレーニングやメンタリングを楽しむ人もいます。一部の人々はそれを嫌います。人が嫌うことをしたくないのです。それは彼らにとって悪いことであり、訓練を受けている人にとってはおそらく悪いことであり、チーム全体にとってはおそらく悪いことです。何も追加されません。その間、人々に彼らが楽しんでいることをさせることは彼らにとって、チームにとって、そしてうまくいけば、訓練生がいくらかの熱意をつかむことになるでしょう。
同様に、トレーニングが得意な人もいれば、得意でない人もいます。一部の人々が他の人がどのようにカチカチ動いているかを理解することを可能にするタイプの人間の相互作用または知性があります。トレーナーは、研修生が理解できる方法で知識を提供できる必要があります。優れたトレーナーはこれを行うことができ、訓練生が物事を「理解する」、「見る」、または「行う」ことを好むことを知ることができます-人々が学ぶさまざまな方法。悪いトレーナーはリハーサルされたスピーチを提供し、柔軟性がありません、そして、トレーニーが彼らの特異な学習方法に追いつかなければイライラします。
研修生に最高のトレーニングを受けさせたいと思います-徹底的かつ効率的です。 「トッププログラマー」がトレーニングに熱心である場合は、トレーニングを行う必要があります。 「ジュニアプログラマー」がそれを実行できる場合は、彼らもショットを持っている必要があります。何人かがトレーニングプログラムに参加しても問題ありません。これにより、トレーニングの対象となるwantsとトレーニングのgoodを決定できます。
あなたがトレーニングから抜け出したい上級のプログラマーであるかどうか（批判はありません-あなたはもっと重要なことをしているのですか、それとも好きではないのですか）か、それに乗りたい。しかし、どちらにしても、あなたは自分が楽しんでいることをしようとしています。幸せな従業員は、より良い職場環境とより良い生産につながります。
私が働いたほとんどの企業では、ジュニアプログラマーは3年未満の経験を持つ人でした。私は幸いですが、特定のトピックについてトレーニングするために新しいプログラマをジュニアプログラマに紹介するメンタリング経験を持つ経験豊富なプログラマとして、すべてのメンタリング責任をまだメンタリング監督が必要な人に委任するのではなく、コントロールを保持したいです自分自身。
ビジネスルールやデザインガイドラインなどは、上級プログラマーが後輩開発者、または新しく雇用された上級/専門家開発者や請負業者に引き継がなければならない最も重要なものであることがわかりました。この重要な情報が蓄積されていたり、説明されていなかったりすると、問題が発生する傾向があります。おそらく、これは上司が実際のプログラミング知識以上に懸念していることです。
プログラミングの知識自体に関しては、それはすべてのレベルでグループ全体に渡されるのが最善です。経験豊富なプログラマーでも、特に複雑な開発フレームワークでは、常に新しいことを学びます。この共有は、ランチアンドラーニングセッションのように正式なものにすることも、時間が許せば非公式なディスカッションを通じて行うこともできます。
私は、メンターが主に組織のトッププログラマーよりも1〜2歩下にいることを選びます。
あなたはそれについていくつかの正当な理由を挙げていますが、私が特に重要だと思うもう1つを指摘します。教えることは、学習の最良の方法の1つです。素晴らしい。これの特に重要な部分の1つは、doのことだけでなく、articulatingの優れた仕事をすることを学ぶことです。私は、なぜ私が特定の方法で何かをしているのかをうまく説明するために、1）自分の理解がかなり向上し、2）私がそれについて十分に考えなければならないことを頻繁に発見しました。多くの場合、自分の仕事を改善するのに十分な状況を再評価します。
彼らにとってそれを行うのはもっと難しいかもしれませんが、これは、同僚に比べて社会的スキルがやや不足しているプログラマにとって特に役立ちます。純粋なコーディングから、メンタリングなどのより社会的な側面に彼らの快適ゾーンから少し押し出すことは、彼らがメンターする人々と同じくらい彼らを助けるかもしれません。ただし、これを行う場合は、ペアリングする相手を選択する際に特に注意する必要があります。誤ったペアリングは、両方を傷つける可能性があります。
タスクのメンターvolunteerが一番うまくいくと思います。この辺りには、正式なメンタリングプロセスはありません。私たちのマネージャーは特定のことを念頭に置いている場合もあれば、「誰もが新しい人のためのプロジェクトについて良いアイデアを持っているのですか？」そして、最高のアイデアを持っている人は誰でもメンタリングを行うことになります。
結局のところ、新しい採用は、学習曲線の時間に余裕のあるプロジェクトに投入され、プロジェクトに最も精通している人によって指導されます。 10か月または10年ここにいる人かもしれません。人々はメンターを少しずつメンターすることになるかもしれませんが、新しい人が新しいことのすべての困難と彼らがどのように彼らを克服したかを覚えているという利点があります。