上級プログラマーは、ジュニア開発者を引き受けて指導する必要がありますか？[閉まっている]

緊密で協力的であることを目的とする店では、シニア開発者がメンターとしてジュニア開発者とペアになっている文化の一部である必要がありますか？または、このメンタリングは、より有機的で自発的なもの、つまり必要ではないが、人為的な励ましなしで開発できるものでなければなりませんか？

私はそれが奨励されるべきだと思うが、必須ではない。先輩を後輩やそのような人に割り当てるべきではありません。さもないとあなたはディルバートランドに行き着くでしょう。「メンターとメンティー」の関係には、核となるある程度の友情と、相互に敬意を払う健全な量が必要です。人々に外に出て「メンティング」するように言うだけではそれは得られません。

シニア開発者がメンターとしてジュニア開発者とペアになるのは文化の一部でしょうか？

はい。

有機的かつ自発的、すなわち必須ではないが、人為的な励ましなしに開発する

実際に誰かを助けるほど頻繁には起こりません。

組織内に既存の関係を持つ人々は、新しい人々によってクリークまたはエリート主義者として認識されます。クリークは通常、故障しません。私たちは知っている人々に固執します-それは人間性の本質的な要素です。

30年以上にわたるコンサルタントとして（数百のクライアントとのエンゲージメント）、私は新しい人々は常に部外者であると断言できます。「文化」や「雰囲気」の特徴ではありません。それは人々の働き方の重要な特徴です。コンサルタントは、確立されたスタッフが彼らを何にも含める傾向がないため、独自のクリークを形成します。

メンタリングを確立する唯一の方法は、新しい人々をクリークに挿入することです。

「メンター」の伝統的な意味は、割り当てにいくらか反します。友達を割り当てることもできます。

私の経験では、新しいチームメンバーを割り当てて、確立されたチームメンバーを最初の週、月などに質問の主な連絡先として使用することは問題ありません。

シニア開発者は、ジュニア開発者を指導する必要がありますか？

絶対違う。優秀なシニア開発者の中には恐ろしいメンターになる人もいますし、メンターシップを成功させるにはパーソナリティのマッチングが不可欠です。しかし、上級開発者は開発チームについて何か改善する必要があると思います。それは、何かをプロトタイピングすること、プロセスやプラクティスを改善すること、新しいツールを開拓すること、グループに技術資料を提示すること、チームなどをリードすることです。言い換えれば、彼らは個々のワークシェアよりも大きい何かに対して責任を負うべきです。

または、このメンタリングは、より有機的で自発的なもの、つまり必要ではないが、人為的な励ましなしで開発できるものでなければなりませんか？

いいえ、そのテイクにも同意しません。私は、メンタリングが「有機的かつ自発的」であると予想される状況をあまりにも多く見てきましたが、めったに起こりません。組織は、メンターシップに感染する機会を与える責任を負う必要があると思いますが、強制することはできません。それは難しいですが、価値があります。組織は次のようなことができると思います。

• 潜在的なメンターと潜在的なプロテジェの間の非公式の出会い
• メンターシップが組織によって正式に認識されるための提案された方法と機会）
• メンターのトレーニングとサポート
• メンターの選び方と期待されることについての指導者へのガイダンス
• 何を期待し、何を提供するかについてのメンターへのガイダンス
• 参加用のテンプレートを使用したメンターシップの推奨（または強制）パターン-たとえば、毎週のミートアップで3か月間の経験があり、新しい開発者の起業を支援するという目標が事前にわかっている場合、試してみるのがはるかに簡単ですそして会社に行く。それ以上に発展しないと言うわけではありません...しかし、それは人々が始めるための場所を与えます。

一部の人々は単にそのように配線されておらず、アイデアによって非常にオフになるため、それを要件にすることは潜在的に裏目に出る可能性があると思います。そうは言っても、あなたはメンターにふさわしいと思う人々を特定し、彼らがメンタリングにおいてより積極的な役割を果たすことについてアプローチしなければなりません（彼らがまだいない場合）。この例によるアプローチは、より自発的なメンタリングをキャッチし、刺激することができます。

また、定期的に行われるグループアクティビティをスケジュールすることもできます。これは、チームがゼリーするのに役立ちます。これらは、チームランチのような完全な社会的活動、または毎週のプログラミングブッククラブのようなプログラミングについての学習を取り入れた活動です。

また、システム上で定期的な「ミニ事後分析」を行うこともできます。これは、グループコードレビューのように機能します。グループ設定でレビューを行うことの利点の1つは、元のコードを書いた人だけでなく、全員がフィードバックの恩恵を受けることができることです。コードを判断して作業を開始することに満足しているボランティアを獲得し、礼儀正しさを維持する必要があります。

ジュニアプログラマーとシニアプログラマーという用語が好きではありませんでした。たとえば、私はしばらくプログラミングを行ってきましたが、一部の分野では経験がありますが、他の分野では非常に環境に優しいです。たとえば、私たちはWPFに移行しており、Windowsフォームアプリケーションの経験は豊富にありますが、WPFはまだ新しいものであり、私にとっては予見できません。したがって、私は「シニア」プログラマーですが、「トータル」な経験をあまり持たずに路上で誰かを雇うことができ、おそらく現時点で私よりもWPFアプリケーションをより良く、より速くプログラミングできます。

WPFアプリケーションに適用できるアプリケーションの設計とアーキテクチャの経験があまりないというわけではありませんが、自分の限界を知っています。

私はあなたが時々メンターになり、他のメンターになりたいと思う必要があると思います。

知識を持っているときにメンターになることを恐れないチームメンバーがいて、知識が必要なときにメンターになることができれば、実り多い経験になります。

開発者が謙虚で新しいアイデアを受け入れ、必要なときに他の人を助けるような開発環境を育てることができれば、先輩と後輩の関係は自然に生まれます。

メンタリングを強制すると、おそらく開発者が互いにresするカーストシステムが作成されます。すべての開発者を同じレベルで平等に扱う方が良いでしょう。

この業界は非常に異なっています。セノリティは常に良いとは限りません。

時々、高齢者は後輩から指導を受ける必要があります。

私は物事を両方の方法で行う環境にいました。

私が学校を出た最初の仕事は、メンターに割り当てられました。私はその男が好きではありませんでしたし、すべてについて彼に同意しませんでした。私は彼と働くことを余儀なくされたことにresし、私の雇用主が間違いを犯したと確信していましたが、振り返ってみると多くのことを学びました。

数年先に進み、今では私は開発者を一人ひとりの態度で扱う会社にいます。開発者は厳しい締め切りの下にあり、他の人を自分の翼の下に連れてロープを見せるために時間を費やす開発者のための余裕はほとんどありません。残念だと思います。ジュニア開発者が私と同じことに苦労しているのはわかりますが、彼らを助けるメンターがいなければ、もっと時間がかかります。

私は「メンター」としての評判を確立しました。なぜなら、新入社員は「私が彼らに提供できる助けに感謝しているようだ」からです。私の知る限り、これは平凡な生産性のレビューを容認して喜んでそれを行うことができると言っている派手なHRの方法です。

私はそれが私たちの後輩従業員にふさわしいものだと思います、そして、後知恵と経験の恩恵で、私が働いた最初の会社と、私を指導したその人は、私が当時考えていたよりもずっと多くを理解していたと思います。

これはすべて、メンターを割り当てる必要がなかったらいいのにと思いますが、おそらくそれが作品の周りに広がる唯一の公正な方法だということです。そうしない場合、それをする人々に彼らの当然を与えるべきです。簡単な作業ではありません。対人スキルとエンジニアリングスキルの両方が必要です。そして時間がかかります。

上級開発者は、コードの混乱を超えることを期待されるべきです。ただし、彼らが進む方向は、すべての上級開発者にとって同じではないはずです。

メンタリングに向いている人もいます。他の人はそうではなく、アーキテクチャの改善を計画して実装するか、新しい技術を評価するか、プロセスの改善を計画してリードするか（たとえば、継続的統合、TDDなど）、他の上級レベルの目標を追求する必要があります

基本的に、シニアは、ジュニアよりも数年間コードをカットしている人だけではないはずです。チームの成功に貢献する追加の責任を喜んで引き受けられる人でなければなりません。後輩のメンタリングは重要ですが、それだけが重要なことではなく、誰もが適しているものでもありません。

そのようなメンタリングを義務付けることは、人間が自然に強制的な活動、行動、関係に対して非常に自然に努力するため、逆効果です。より良いアプローチは、良いメンタリングを行った人々に報いることです。たいということです。

もちろん、これはこの文脈で「良い」を測定する問題を持ち出します。不完全ですが、簡単に実装できるソリューションは、1年後に（おそらく匿名で）新人に、会社やコードベースへの統合を支援したトップ3人の名前を書くことです。その後、名前が最も言及される人に報酬を与えることができます。ただし、金銭的な報酬はここでは機能しません。何らかの社会的報酬を見つけたほうがいいです。

チームが構造をリードし、コードレビューにつながるトリックを行う必要があります...

1人または複数の後輩を担当するスタッフの上級メンバーが必要です。私はそれが自発的な助けであるべきではないと信じていますが、むしろ正式なプロセスです。ある意味で、上級メンバーは新参者によって生み出された仕事の質に責任を負うということです。このアプローチには（少なくとも）2つの利点があります。シニアに管理スタイルを教え、後輩が高品質のコードを生成するようにします。

プログラミングのすべてにおいて、それは依存します。しかし、新入社員を後輩であるかどうかに関係なく指導する上級開発者に、当面の仕事に最適なトレーニングをしてもらいたいです。

いいえ。これは、シニア開発者とジュニア開発者の数が常に同じであることを意味するためです。メンターになりたいシニア開発者を励ますことはできましたが、ペアリングを強制することは本当に悪い考えかもしれません。メンタリング関係をサポートするというアイデアは良いものであり、ここで捨てるべきではありません。

ただし、人工的な励ましは悪い考えではありません。ジュニアやシニアのデベロッパー全員に、少し宗教的で裏目に出たとしても、メンティーやメンターになることを伝えます。

社内でメンタリングを処理する方法がわかっているフレームワークがある場合、それは素晴らしいことです。ただし、それが存在しない場合、キーはメンターとメンティーの間にいくつかの異なる種類の瞬間を持つことになります。

1. 現在のステータス-物事は今どこにありますか？メンターが解決の支援を提供できる現在の課題は何ですか？
2. 将来の状態-求められるもの：ヒント、解決策、尋ねるべき質問、誰に尋ねるべきか？
3. レトロスペクティブ-変更の際に機能し、機能しなかったものは何ですか？
4. 将来の変更-以前に行われたものよりもうまくいくかもしれない将来的に何が試されますか？

少なくともこれらは、論理的なトップダウンアプローチをとるために、私の見解から理解し、理解できる状態です。他の人は、もっと有機的で自由な形で、同様に機能するものが欲しいかもしれません。重要なのは、この関係でコミュニケーションをとることにより、それぞれの側にスキルを磨く方法を考え出すことです。関係はそれぞれの側から何かを得ているはずであり、フィードバックはここで大したことなので、この種の関係を持つためのいくつかの共通の基本的なルールがあるはずです。

これにどれだけの時間を費やすかは公平な質問であり、現実的には何が行われているか、そしてスキルの開発と関係の構築にどの程度の時間を費やすことが容認できるかを見なければなりません。他の人はこれをカバーするために1日数時間を必要とするかもしれないが、私はこれを通過するために週に1時間を望んでいるいくつかのペアを見ることができました。正式なメンタリング関係ではなくても、シニアとジュニアが一緒に働くことができる他の相互作用があることを忘れないでください。

私は、メンターシップシステムでいくつかの異なる試みを見てきました。私が一番気に入ったのは、シニア開発者がジュニア開発者を支援するために実行した特定のタスクのセットを持っているもので、それはメンタリングを必要とせずに道を開いた。たとえば、最初の6か月間に割り当てられた上級開発者の一対一のコードレビュアーは非常に有用であり、メンターシップにつながる可能性があります。私が嫌いなのは、余分な忙しい仕事のように感じたものであり、行われている仕事に直接関係していないようです。たとえば、割り当てられたメンターと毎週30分間会います。これは、メンターシップ関係の2人のメンバーが一般的に1週間に相互にやり取りせず、互いのプロジェクトとは何の関係もなかったときに特に面倒でした。プロとして成長することに焦点を当てるのではなく、非常に強引で微妙な感じがしました。最後にしたいことは、メンターシップの関係がカウンセリングセッションのように感じることです。

IMまず、素晴らしいアイデアです。理想的には、上級メンバーはその役割に志願し、個人的な利益を認識できる必要があります。私の現在の会社では、上級開発者はプロジェクトのほとんどのリードであり、利点は彼らが自分のプロジェクトのチームを構築していることです。他の会社では、メンターが管理トラックを頻繁に調査していました。

若い開発者を雇用するすべての企業には、何らかの合理的な効果のあるメンタリングプログラムが必要です。しかし、多くの開発者は、開発がどれだけ優れていても、メンタリングが粗末だという単純な理由で、すべての上級開発者がそれを行うべきかどうか、デフォルトの位置がわからない。残念ながら領土と一緒です。私たちの何人かはあなたが好きならただの素晴らしい人ではありません。

一方、それが得意な人がいる場合は、実際の開発出力が低下するため、ブラックマークではなく認識されるはずです。たとえば、NotePadやJavacを使用しました。

これには、バランスの取れた管理が必要です。それが一般的かどうかはわかりません。

メンタリングが機能するためには、経営陣がこれが重要であることを認識し、これに時間を割り当て、これを積極的に奨励することが不可欠です！

課題を100％予約した人にとっては、文字通りメンタリングを行う時間も受ける時間もありません。それは起こりません。

一般的に、メンターシップは、シニアからチームリーダーまたはマネージャーに移行するための良い踏み台です。メンターシップをPDP（Personal Development Plan）の進歩または会社が使用するメリットプランにリンクすることはより効果的です。少なくとも昇給とキャリア開発を結び付けて、少なくとも一部は知識を伝え、新しい開発者を育てる能力は、経営陣と離職者の変化を乗り切ることができる強力なITスタッフを構築するための鍵です。重要な目標を提供し、スタッフと協力して改善を支援することは、リーダーシップへの成長の一部です。高齢者の評価を成長の一部であるジュニアのパフォーマンスに結びつけるのは公平ではないと思う人のために。ほとんどの場合、給与の削減ではなく、増加の減少または昇進の遅れについて話します。

私が最初にチームに来たとき、私はオーナーと主任開発者に指導を受けました。私はそれらのいずれかを尋ねることができ、彼らは両方とも返信するでしょう。しかし、タイムリーに理解できなかった場合を除き、私は彼らを悩ませ続けないほど敬意を持っていました。

うまくいきましたが、これを機能させるには、おそらくユーモアのセンスのある素敵な人が必要でしょう。