ジュニアを修正するが、彼が自分で考えることを奨励する方法は？[閉まっている]

私は、全員が1年未満のソフトウェア開発経験を持つ小さなチームのリーダーです。私は決して自分をソフトウェアの第一人者とは言いませんが、ここ数年でソフトウェアを書いていることをいくつか学びました。

コードレビューを行うとき、私はかなりのミスを教えて修正します。「これは非常に複雑で複雑であり、これが理由です」または「このメソッドを別のクラスに移動することについてどう思いますか？」質問や意見の相違がある場合は大丈夫ですので、話し合う必要があることを伝えるのは特に慎重です。私は誰かを修正するたびに、「あなたはどう思いますか？」と尋ねます。または類似のもの。

しかし、意見が合わない場合や理由を尋ねることはめったにありません。そして最近、私は彼らが私の声明に盲目的に同意し、彼ら自身の意見を形成していないというより露骨な兆候に気付いています。

指示に従うだけでなく、物事を自律的に正しく行うことを学ぶことができるチームが必要です。ジュニア開発者をどのように修正しますが、それでも彼が自分で考えることを奨励しますか？

編集：ここに、彼らが彼ら自身の意見を形成していないというこれらの明白な兆候の1つの例があります：

私：拡張メソッドを作成するというあなたのアイデアは好きですが、大きな複雑なラムダをパラメーターとして渡す方法は好きではありません。ラムダは、メソッドの実装について他人にあまりにも多くのことを強制します。

ジュニア（私を誤解した後）：はい、私は完全に同意します。ここで拡張メソッドを使用しないでください。これは、他の開発者に実装について多くの知識を強要させるためです。

誤解があり、それは対処されました。しかし、彼の声明には論理のOUNCEさえありませんでした！彼は私の論理を逆流していると思い、なぜ彼がそれを言っているのか全く分からないときに理にかなっていると思った。

簡潔な答え：

参加させ（パズルを思い浮かべて）、力を与えます（答えを信頼します）。

私たちを駆り立てるのは質問です！-マトリックス。

一般的に、私の観察では、後輩は自分の世界を持っています-自分の考え方に対する限定された視野と、物事に対する熱意/お気に入り/意見の一部。

あなたが間違っていることを真正面から伝えることについては何も悪いことはありません-しかし、最も良いのはあなたに彼らに考えさせることです。どうして？他の方法はありますか？同じことをするより良い方法はありますか？私がいつも使っている逸話の1つは、「（この問題に対する）3つの解決策を与えてください！」です。

彼らがこれらの解決策について考えるまでに、彼らは多くの問題を認識し始めます。時間をかけて投資する必要がありますが、時間の経過とともに、思考の限界や欠点を視覚化する傾向があります。彼らはそれを「私はそれを考えていなかった！」と見始めます。「私は間違っていた！」という気持ちで家に帰るよりもずっといいです。またはさらに悪い「有効な視点を持っていたとしても間違っていると言われた/証明された」。

一般的に、幼い子供は、プロセスの問題よりも技術的な問題（どのデザインパターンがより効果的かなど）に関連して熟達する傾向がありますが、時間をかけてコーチングすればうまくいきます。

しかし、意見が合わない場合や理由を尋ねることはめったにありません。そして最近、私は彼らが私の声明に盲目的に同意し、彼ら自身の意見を形成していないというより露骨な兆候に気付いています。

これは一般的にあなたが彼らの提案を受け入れた結果ですが、後でそれらを却下し、あなたの意見についても同様に納得しません。あなたが先輩だからといって、彼らは戦いを避けています！

私が過去のボスの一人から学んだ最高のこと：彼はチームメンバーに最初に議論するように頼みます（ここではかなり平等だと感じています）。不一致のポイントは？」-ポイントは、人々は常に議論や議論に参加することを好むが、彼らの（有効な）点が次回行動に持ち込まれない場合、彼らは議論に参加する価値はないと感じます。

ソフトウェアだけでなく、どこでも最終的には、最も権限のあるチームメイトだけが、システムへの質問は言うまでもなく、あえて返信します。

あなたの後輩が自分で考えるようにしたい場合は、それらを修正しない：するためにそれらを得る自分自身を修正。

あなたが彼らの解決策について間違っていると思うことを彼らに伝える代わりに、彼らにそれについて適切な質問をしてください。あなたの例では、ラムダを作成するために拡張メソッドを使用する人が何を知る必要があるかを彼らに尋ねることができます。問題であると示唆されるまで、このような質問を続けてください。そうすれば、彼らは彼らの解決策が問題になる理由を理解し、さらにそこから学ぶ可能性が高いことを知っています-単に彼らの解決策が間違っていると伝えるならば、それは外部判断であり、簡単に無視されます。彼らが（少しのプロンプトで）自分で実現に来た場合、彼らはそれがどれほどしっかりしているのかを理解し、彼らの間違いから学ぶ可能性がはるかに高くなります。

さらに、これはあなたのジュニアに彼らのデザインを守る機会を与えます-おそらく彼らは問題について考えており、あなたの懸念に対処する正当な正当性を持っているので、あなたは修正する必要はありません。これにより、経営者が法定で支配しているという認識（ただし意図的ではない）が減少します。

複数のジュニア開発者がいるので、1つではなくグループとしてコードレビューを行います1。

グループに「他にどのように問題を解決できますか？」と尋ねて開き、他のジュニア開発者が最初に実装を提案できるようにします。実装を追加するのは、他のチームメンバーが発言した後、そして何もあなたのアイデアに似たものを提案していない場合のみです。

次に、後任開発者が何であるかを言わずに最適な実装を選択するように導くことを目的として、さまざまな実装の相対的な長所と短所についての円卓会議の議論を行います。

ジュニア開発者の信頼を築く人として、あなたが最良の選択肢だと思うものを選んだ場合から始めて、あなたの代替品を半明白な欠陥を持つストローマンにし、元の実装がなぜ最適なのかを議論することができます。

プログラミングの仕事を始めたとき、私はあなたが説明したのとまったく同じことをしました。それは主に、そうでないと言うのに十分な経験がなかったからです。

方法論やアイデアを実際に議論できるようになったのは、経験から学び、さまざまなアプローチや新しいテクノロジーについて読むことでした。チームが自分自身で考えるためには、「過度に複雑で複雑な」コードのようなものからどのような問題が発生する可能性があるかを実際に知る必要があります。

個々の思考を促進する良い方法は、Stack OverflowやProgrammers SEなどのプログラミングWebサイトを調べてもらうことです。これらが私が世に出ているさまざまな技術について学ぶのを助け、盲目的にそれらに同意するのではなく、チームの上級メンバーと議論することを可能にしたことを知っています。

重要なのは、経験がなくても、上級メンバーからの提案は常に彼らにとって正しいことだということです。

あなたの投稿からのやり取りは、ほとんど何でも教えるための重要な原則を示しています。あなたが言ったと思うことを説明するように彼らに頼み、応答に注意深く耳を傾けてください。

25年ほど前に数学の先生からこのトリックを恥ずかしく盗まれましたが、それ以来私は失敗していません。私は授業での短いアシスタントとして、ティーチングアシスタントとして、職場でソフトウェアデザインについて話し、8歳のときに彼女の学校の割り当てについて話していました。

もちろん、あなたがいつも言ったことを繰り返すように彼らに頼むことについていつも鈍的であるとは限らないので、あなたはあなたの戦略を調整する必要があります。たとえば、OPからのフォローアップステートメントを「調査」質問として言い換える方法を次に示します。

拡張メソッドを作成するというアイデアは気に入っていますが、大きな複雑なラムダをパラメーターとして渡す方法は好きではありません。この複雑なラムダが他の人にメソッドの実装に関する特定のことをあまりにも多く知っていることを強制しますか？

この質問は、強調しようとしている問題を理解せずに正しく答えることは不可能です。説明を締めくくると、今言ったことの分析が必要な質問で終わるため、学習プロセスが高速化され、修正が必要なフィードバックが得られることがわかりました。

通常、人々があなたが望むことを言っていないとき、それはあなたがあなたのリスニングに取り組む必要があることを意味します。聞くことは、判断を下す前にデザインの理由を聞くことを意味します。それは、異議を唱えることを彼らに伝えるだけでなく、彼らが言っていることを正直に考えて、それを訂正するだけでなく、それを証明することを意味します。ソリューションの良い点を探し、ソリューションを修正してそれらの点を組み込みます。

また、例によってリードする必要があります。私は非常に素晴らしいコードを書くことを意味するのではなく、あなた自身のデザインについて彼らに意見を求めることを意味します。事後のコードレビューを待つのではなく、途中で一緒に作業します。「私のインターフェースは複雑すぎるように見えますが、それを簡素化する最善の方法はわかりません。」そして、最初に自分のアイデアに偏らせずに回答する時間を与えます。

私がこれに対処しなければならなかったとき、私は（正直に）次のようなことを言った：

ご存知のとおり、それは私が考えもしなかった本当に創造的なソリューションです。どのようにスケーリングしますか？/開発をより速くしたり、メンテナンスを簡単にしたりするために、概念的にシンプルなアプローチがあると思いますか？構成は次のように見えますか？

これは通常、人々を新しい方向に向けるのに十分です。

責任は彼らを助けることができる一つのことです。

私は過去に1つまたは2つのチームを率いてきましたが、ジュニアを輝かせたものの1つは個人的な責任の負担でした。ある時点で彼の行動が彼に影響を与える可能性があることに気づいたとき、彼/彼女は通常、彼がしていることでほんの少しだけ自分自身をコミットします。言うまでもなく、彼らが自分の仕事を感じるとき、良い結果ははるかに満足です。

彼らが盲目的にあなたをフォローしているという事実についてはあまり心配しません。これが彼らが後輩としてすべきことです。問題は、彼らが消えて、ひどいソフトウェア開発者、ひどい管理、ひどいコードを持っている他の場所で働くまで、あなたがコードレビューで対処するアイテムの本当の理由を理解しないだろうということです。

その時までに、彼らは習慣から良い習慣を学び、他の人が犯すコーディングと設計の間違いを乗り越えなければならず、彼らは今や不十分に設計され実装されたソフトウェアで働かなければならないことを強いられます。

これは、彼らのキャリアのある時点での最終的な必然性になります。優れたコーディング標準と実践に慣れることで、すばらしいサービスを提供しています。残念ながら、私たちのほとんどは難しい方法を学ばなければなりませんでした。

与えられた例に基づいて、私はあなたのコメントを質問でフォローアップすることがおそらく最善の方法だと言うでしょう。コメントとともに質問をする場合、少なくとも彼らが何かを実装する方法について考えなければならないという単純な同意または不同意を彼らに任せているわけではありません。

例えば、「拡張メソッドを作成するというあなたのアイデアは好きですが、パラメータとして大きな複雑なラムダを渡す方法が好きではありません。それほど多くの情報を公開しないこの拡張メソッドを実装しますか？」

これにより、開発者が開発中の障害を確認できると同時に、アプリケーションに導入された問題を解決する機会が与えられます。