誰が新しいプログラマーを訓練すべきですか？ジュニアまたはシニアのプログラマーですか？[閉まっている]

私のチームでは、ほとんどの上級プログラマーに真新しいジュニアプログラマーを訓練/指導することをしばしば要求します。ただし、これらの同じ上級プログラマーは、実際の重要な作業の大部分を実行しているプログラマーです。

私は上司に、高い適性を示している若いプログラマーに新しいプログラマーを彼らの翼の下に連れて行くのは理にかなっていると主張しようとしました。まず、上級開発者がより重要なイニシアチブに取り組むことができるようにします（メンタリングは重要ではありません）。次に、ジュニアプログラマーは、そのような責任を求められ、教えることで何かを学ぶことができるという彼らの仕事に少しの誇りを与えます。最後に、上級開発者は後輩よりも多くの費用がかかるため、会社のお金を節約できます。

これが明らかに時間の始まりからこのチームで働いている方法なので、私のボスは説得できませんでした。何らかのトレーニング/メンタリングが必須であるという決定がなされたと仮定すると、誰かが私にいくつかのより良い議論を提供したり、私が間違っている理由を教えてもらえますか？あなたのチームは何をしていますか？

**年功序列は必ずしも能力を示すものではないので、「シニアプログラマー」、つまり「トッププログラマー」を意味するものとみなすことができます。

前の会社でこのような状況がありました。ほんの数人のシニア開発者は、割り当てられた他のタスクを実行できなくなるほど多くのジュニア開発者を指導していました。しばらくして、シニア開発者がマネージャーと一緒にそれを持ち出し、ジュニアとシニアの間のどこかにいた開発者がメンターとして行動することが決定されましたが、難しい問題についてはシニア開発者に尋ねることができました。

かなりうまくいきました。それ以前は、仕事で挑戦されていなかったため、数人の上級開発者が新しい仕事を探し始めていました。その後、彼らは新しい機能に取り組み、作業を完了することができました。上級開発者はこの状況についてどう思いますか？

私の見解では、シニアになることは、ドメインの専門知識、メールのフッターのタイトル、またはあなたが働いた時間だけではありません。また、ジュニア開発者を支援および指導するための考え方でもあります。そして、チーム内でより多くの上級開発者を獲得するために、それほど上級ではない人にメンタリングをさせるよりも良い方法はありますか？

すべてのトッププログラマーがトップティーチャーであるとは限りません。説明ができ、会社の「環境」についての概要を持っている人（技術的なことだけでなく、連絡先のような組織的な人）によるトレーニングを行うことをお勧めします。

私は既に言われたことのいくつかを繰り返しますが、私は2つの見解を持っています。

ビジネス：ビジネスとして、あなたは生産性と低リスクを求めています。上級開発者は大部分の作業を行っていますが、リスクを下げるためにシステムに関する知識を移転してもらいたいと考えています。これらの高齢者にあまり重要でないことをするための休憩時間を与える必要があるため、生産性はそれほど影響を受けません（ジュニア開発者を教える）。システムとは別に、彼らはまた、ジュニア開発者がまだ知らない、または把握していない多くの分野を持っています。

敬意：新しい開発者を彼らの翼の下に連れて行くジュニアは、盲人を導く盲人のようなものです。ジュニアは、他の人に教えることを担当するすべてのものについて、まだ最新の状態ではありません。また、敬意がそこにないかもしれないので、うまくいかないかもしれません。あなたのスキルセットと初心者のスキルセットはそれほど遠くないので、ジュニア開発者に対する敬意が問題になります。しかし、一緒に問題に取り組むことは別の話です。初心者やジュニアを教える上級開発者に関しては、敬意を払うことは間違いありません。私たちは皆、2人の個人またはチームに敬意が欠けているとき、災害が起こるのを待っていることを知っています...

これを別の角度から見てください。ここのプログラマーの間でどのようなスキルと知識を伝えたいですか？上級プログラマーが本物の大部分の仕事をしている場合、誰がどのシステムを知っているかという点で、これは少しの隔離を維持しませんか？後輩がシステムを知ってシニアのバックアップになるようにすることは、ここで最も重要なのは、蓄積された潜在的な長年の知識のシニア知識が受け継がれるということです。後輩を指導する先輩は、私の考えでは一種の自然な形成のように思えます。

ジュニアプログラマーが別のジュニアプログラマーを指導しているのは、私の考えではまったく意味がありません。ただし、いくつかのジュニアプログラマをペアにすることは、ある意味で理にかなっています。1人のアイデアだけではなく、チームがある意味でチームをまとめるより協調的な環境を促進するのに役立つように、2人の人々がタスクで一緒に作業するようにすることで。使用している環境に応じて、これは実行するのが理にかなっている場合とそうでない場合があります。

チームのシニアプログラマーが実際に後輩よりも自分のトレードをマスターしていなくても、チーム内でより長い時間を過ごしていて、および/またはより高い社会的/政治的地位を持っているなら、実際には大きな違いはありません誰が-誰でも-新参者を指導します。とにかく、彼らはとにかく同じレベルの平凡に向かって引き寄せられるでしょう... :-(

OTOH、先輩が世界の本当の意味で実際に（少なくとも顕著に近い）マスタープログラマーである場合、大きな違いを生むことができます。ジュニアは、ブロック上の新しい子供にあまり良くない実践を簡単に教えることができます。そして、ベストプラクティスを学ぶことから始めるよりも、次善策または悪いアプローチを後で学ぶことははるかに困難です。

そうは言っても、後輩に才能があり、特定のツール、技術、または領域に関して自分が何をしているかを確実に証明している場合、その特定の領域で実際に有用なトレーナーになることができます。。

しかし、特定の観点から、メンタリング/トレーニングの全体のポイントは、高齢者がそれほど困難ではないタスクの一部を他のタスクに委任できるようにすることであるため、彼らは本当に厳しいものに集中できます。これを実現するためには、彼らが実際にそれらのタスクとスキルを仲間に最初に教え、よく教える必要があります。

簡単な答え：トレーニングを行う人は、トレーニングを行うことを望んでいるトレーニングが得意な人でなければなりません。

一部の人々は、トレーニングとメンタリングを楽​​しんでいます。嫌いな人もいます。人々が嫌いなことをするのは望ましくありません。それは彼らにとって悪いことです。訓練を受けている人にとってはおそらく悪いことであり、おそらくチーム全体にとっても悪いことです。何も追加しません。一方、人々が自分の好きなことをさせることは、彼らにとってもチームにとっても良いことであり、できれば訓練生が熱意を感じることを願っています。

同様に、トレーニングが得意な人もいれば、そうでない人もいます。一部の人が他の人がどのようにカチカチ音をたてるかを理解するのを可能にする人間の相互作用または知性のタイプがあります。トレーナーは、研修生が理解できる方法で知識を提供できる必要があります。優れたトレーナーはこれを行うことができ、訓練生が物事を「理解する」、「物事を見る」、「物事をする」ことを好むことを知ることができます-人々が学ぶさまざまな方法。悪いトレーナーは、リハーサルされたスピーチを提供し、柔軟性がなく、訓練生が彼らの特異な学習方法に追いつかないとイライラするでしょう。

私はあなたが訓練生に最高の訓練をしてもらいたいと思います-徹底的かつ効率的です。あなたの「トッププログラマー」が訓練に熱心なら、彼らはそれをするべきです。「ジュニアプログラマ」がそれをやっているなら、彼らもショットを持っているはずです。少数の人々がトレーニングプログラムに参加することは害になりません-トレーニングしたい人とトレーニングが得意な人を決定できます。

あなたがトレーニングから抜け出したい上級プログラマーであるかどうか（批判なし-あなたはもっと重要なことをしている、または単にそれを愛していない）、または若いプログラマーであるかどうかあなたの質問からわかりませんそれに参加したい。しかし、いずれにせよ、あなたはあなたが楽しんでいることをしようとしている-そして私たち全員が私たちが楽しんでいる仕事をしたくないのですか？幸せな従業員は、より良い職場環境とより良い生産につながります。

私が働いたほとんどの会社では、ジュニアプログラマーは3年未満の経験を持つ人でした。メンタリングの経験がある経験豊富なプログラマーとして、特定のトピックに関するトレーニングのために新しいプログラマーをジュニアプログラマーに紹介したいのですが、メンタリングの監督をまだ必要とする人にすべてのメンタリングの責任を委任するのではなく、コントロールを維持したいと思います自分自身。

私は、ビジネスルールや設計ガイドラインなどが、より上級のプログラマーがジュニア開発者に、あるいは新しく採用されたシニア/エキスパート開発者や請負業者にさえ渡さなければならない最も重要なものであることを発見しました。この重要な情報が保存されているか、説明されていない場合、問題が発生する傾向があります。おそらくこれは、実際のプログラミングの知識以上にマネージャーが心配していることです。

プログラミングの知識自体については、すべてのレベルでグループ全体に渡すのが最適です。経験豊富なプログラマでさえ、特に複雑な開発フレームワークでは常に新しいことを学びます。この共有は、昼食と学習のセッションのように、または時間が許せば非公式の議論を通じて、正式なものにすることができます。

メンターは、主に組織のトッププログラマーの1〜2歩下になります。

それにはいくつかの理由がありますが、特に重要だと思うことをもう1つ指摘します。教育は学習の最良の方法の1つです。素晴らしい。これの特に重要な部分の1つは、物事をうまく行うだけでなく、あなたがしていることとその理由を明確に伝えることを学ぶことです。私は、特定の方法で何かをしている理由を説明するのに良い仕事をするために、1）自分自身の理解がかなり向上し、2）私が多くの場合、自分の仕事を改善するのに十分な状況を再評価します。

彼らがそれを行うのはかなり難しいかもしれませんが、これは社会的スキルが仲間と比べていくらか欠けているかもしれないプログラマにとって特に役立ちます。純粋なコーディングからメンタリングのようなより社会的な側面に彼らの快適ゾーンから少し押し出すことは、彼らがメンタリングする人々と同じくらい彼らを助けるかもしれません。ただし、明らかにそれを行う場合は、ペアリングする相手を選択する際に特に注意する必要があります。間違ったペアリングは両方を傷つける可能性があります。

メンターがタスクに志願するとき、それが最もうまくいくと思います。このあたりでは、あまり正式なメンタリングプロセスはありません。私たちのマネージャーは具体的なことを念頭に置いていることもありますが、「新しい男のプロジェクトについてだれかが良いアイデアを持っている人はいますか？」そして、最高のアイデアを持っている人は誰でもメンタリングをすることになります。

最終的に起こるのは、新しい雇用が学習曲線の時間に余裕があるプロジェクトに置かれ、プロジェクトに最も精通している人によって指導されることです。それはここに10ヶ月か10年来た人かもしれません。時にはメンターを少し指導することもありますが、新しい人はまだ新しいことの難しさをすべて覚えており、どのように彼らを克服したかが利点です。