5人の新しいジュニア開発者と多くの複雑なタスク。今何？

私たちの会社は、私たちの製品開発を手伝うために5人のジュニア開発者を雇いました。残念ながら、新機能と今後のバグ修正には、最近卒業した開発者が通常持っているよりも深い知識が必要です（スレッド化/同時実行、複雑なシステムでのパフォーマンスボトルネックのデバッグなど）。

彼らが（おそらく）解決できるタスクの委任（および計画）、彼らの質問への回答、それらのメンタリング/管理、彼らのコードのレビューは私の時間のすべてを使い果たし、委任プロセス全体がかかるよりも短い時間で問題を解決できると感じていることがよくあります（私の時間のみを数えます）。また、システムの深い知識や高度なスキルを必要とするタスクを解決する時間がないため、近い将来に変更されることはないようです。

それで、今は何ですか？彼らと私の時間を効果的に使用するにはどうすればよいですか？

はい、あなたは彼らができるより速く物事を解決することができます、それがあなたがシニアであり、彼らがそうでない理由です。ただし、良い先輩は後輩も上級レベルに引き上げたいと考えています。これを行う唯一の方法は、物事のやり方を彼らに学ばせることです。

メンタリングは、コーディングではなく、現時点であなたの時間を最も効果的に使用することです。

次の6か月を効果的にメンタリングに費やし、後輩が中間開発者になるのに十分な知識を持っている場合、このように見てください。あなたがすべてのハードワークをより速いので自分で行う場合、6か月で5人のジュニアが親指をいじるのに苦労します（まあ、彼らの中で最高の人は、それまでに難しい仕事を与えなければ、それまでに他の仕事に移るでしょうから、ジュニア開発者の数が少ないか、新しい場合があります）、過労で不機嫌なシニアが1人います。

バグには通常どのような複雑な相互作用が見られるかがわかっているので、実際に問題をトラブルシューティングして見つける方法と、それらを修正するために通常必要な方法のタイプについて、それらのタイプに特化したトレーニングを開発します。次に、問題が発生したときにそれらの問題を提供します。はい、それらはそれらを修正するために時間がかかります、そしてあなたはあなたの時間の見積もりでそれを考慮に入れるべきです。

ペアプログラミングのアイデアは素晴らしいです。本当に進んでいる問題ごとに異なるものとペアリングします。問題を解決するのに十分な知識がなくても、原因を探すという観点から何を試すべきかを子供に教えながら、トラブルシューティングのプロセスを教えることができます。もちろん、彼らが口述を取ることを期待するだけではありません。あなたが彼らに探して欲しいものとその理由を説明してください。彼らのアイデアを求め、それらに耳を傾けます。彼らのアイデアがそうでない場合、それが良い選択ではない理由を説明してください。指導的な質問をすることにより、ソクラテスの教え方を使用します。彼らはあなたが説明なしで彼らに指示したものよりもあなたの主要な質問を通して彼ら自身で思いついた解決策をよりよく覚えます。彼らがあなたがそれをタイプするのを見ただけではなく、実際に解決策をタイプした方が彼らは同様によく覚えます。

ジュニアがあなたとペアの一部として特定のクラスの問題を解決するのを手伝ったら、次にそのクラスの問題が発生したときに彼を他の誰かとペアにして、相談するだけで、肩を並べることはできません。彼らは別のことを試みます。

本当に難しい5人の新しい人がいます。あなたはそれらのすべてに公平であり、あなたがペアリングしたり、ガイダンスを与える人を回転させる必要があります。お気に入りを再生しないでください。でも、誰かが成功せず、進歩していなければ、「タフな愛」を与える人になる必要があります。そのうちの1人以上を脇に呼び出し、改善する必要があることと、なぜ成功していないと感じているのかを伝える必要があるかもしれません。SOme peopelを使用すると、ペアリングできればすべての作業を実行できます。これは、簡単なためです。その人が仕事をすることができないなら、彼らは彼らに優しく、彼らがより自立することを学ぶことができないか、または学ばないことが明らかなときに彼らを運ばない方がチームにとってはるかに良いです。

思い通りの結果が得られることを忘れないでください。あなたが多くを期待しないならば、あなたは多くを得ません。それらが輝いていることを期待し、それらのほとんどはあなたの基準に達するでしょう。

ペアプログラミングはここで大きな可能性のように聞こえます。

• それらのうちの4つにこれらのバグのうちのより単純な2つを与え、それらをペアにして、各ペアがそれらの1つに取り組むようにします。
  • このリクエストは「何が原因なのか理解できますか？」と表現します。まだ修正方法を考えさせないでください。
  • 彼らは説明のいくつかのレベルを持っているしたら、その後、それが固定される可能性がありますどのようにそれらを尋ねます。このようにして、彼らは巨大な仕事で一度に圧倒されることはありません。まだ行っていない場合は、コードを試してもらい、計画があれば（曖昧な計画であっても）、優れたソリューションに導くことができます。
• もう1つは、ペアにして、より難しいものの1つに取り掛かることができます。コードに不慣れなため、これはさらに難しいかもしれませんが、彼はコードを使用した経験のある人にとってもメリットがあります。
  • あなたの経験を考えると、これを行うには新しい機能が良い方法だと思います。新しい機能が開発されるときに、既存のAPIを彼に示すことができます。

この提案が機能する逸話/例について：これは私が取り組んでいるコードベースの最も毛深い部分に紹介された方法でした-私がペアを組んでいた他の比較的新しい開発者と一緒に、私たちは次のようなことをしました：

• 私たちはバグを与えられ、約10分の紹介の後、何が起こっているのかを理解しようとするように言われました。
• 約1時間後、私たちは2つの異なる考え方の列に分かれて掘り下げました。
• それから約2時間後、私は一般的にコードがどのように機能するかを理解しましたが、不正な出力が生成されている場所を正確には知りませんでした。彼は生データと非正規化データを掘り下げて、それがどのように生成されているかを理解しましたが、コードを理解できませんでした。
• 私たちはペアを組み、コードパスを一緒にたどり、正確な答えを得ました。このことから、マネージャーと考えられる解決策についてブレインストーミングを行い、後で実装することにしました。

私はコードベースの全体のメンテナンスを引き継ぎました。なぜなら、私は本当にそれがどのように機能するかを理解している唯一の人間だからです（まだ残っている元の開発者は完全に思い出すことすらできません）。

それらを教える。簡単に解決できるタスクを割り当てます。

簡単に言えば、問題は、前述の労働力は、彼らが持っているタスクを非常に生産的にするのに十分なスキルを持っていないということです。そのため、1）タスクを容易にする2）労働力のスキルを向上させることができます。

同様の問題は、新しい人がチームに参加し、経験のないコードベースで作業を開始するたびに（ある程度）ほとんど常に発生します。ツールや方法論が不明な場合、これはさらに問題になります。ツールと方法論に慣れるように人を訓練することにより、問題をより早く緩和することができます。

ただし、そのような問題の解決には時間がかかります。他の人がすべてを知っていることや、すべてを一瞬で学ぶことを期待することはできません。おそらく、必要な並行性、ソフトウェアの最適化、一般的な方法論についていくつかの本を紹介することから始めるのがよいでしょう。

あなたは採用決定の一部ではなかったようです。現在のタスクを処理する能力を公平に評価します。推奨事項（納期に影響を与えない限り、外部トレーニングなどのタスク）を記載したレポートを書き留め、そのレポートをマネージャーに送信します。マネージャーは、彼らを雇った人と話し始める可能性があります。1人の新しい人がチームに夢中になっているかもしれませんが、リラックスした店がない限り、一度に5人の新しい人が良い音を出すことはありません。これが計画で説明されていない限り、プロジェクト時間にそれらを教えようとしないでください。

編集：この状況で はブルックの法則に言及するのが適切な場合があります。

サンドボックス環境を作成して、害を及ぼすことなく困難な問題に取り組むための時間を費やすことができるかもしれません。できる限り徹底的にソリューションをテストしてもらいます。同じ問題に2つ以上当てはめてください。

これらすべてのものは、彼らが有用になるのに十分な熟練の可能性を彼らに与えます、そして、彼らはあなたのより少ない時間を必要とします。もちろん、あなたがそれらを（ほとんど）沈めたり泳いだりして、それらがかなり沈んでいるなら、あなたは物事を再考する必要があります。

プログラミングの専門家では、ほとんど自分で学ぶことができない人々は、おそらく彼らを教えるのにかかる努力に本当に値するものではありません。しかし、私は彼らがおそらくあなたがヘルプを削減したときに彼らがどれだけうまくやっていくかであなたを驚かせることでしょう。