後輩を正すが、自分で考えるように奨励する方法は？
私は、誰もがソフトウェア開発の経験が1年未満の小さなチームのリーダーです。私は決してソフトウェアの第一人者とは言いませんが、ソフトウェアを書いているということを数年の間にいくつか学びました。
コードレビューを行うとき、私はかなりの間違いを教え、修正します。 「これは過度に複雑で入り組んでいるので、ここに理由があります」または「このメソッドを別のクラスに移動することについてどう思いますか？」彼らが質問や反対意見を持っている場合、それは大丈夫であり、私たちは議論する必要があることを伝えるために私は特に注意深く話します。私は誰かを訂正するたびに、「あなたはどう思いますか？」と尋ねます。または似たようなもの。
しかし、彼らが意見を異にしたり、理由を尋ねたりすることはほとんどありません。そして最近、私は彼らが盲目的に私の声明に同意し、彼ら自身の意見を形成していないというより明白な兆候に気づいています。
指示に従うだけでなく、自律的に正しいことを行うことを学ぶことができるチームが必要です。ジュニア開発者をどのように修正しますが、それでも彼に自分で考えるように勧めますか？
編集：これは、彼らが自分の意見を形成していないというこれらの明らかな兆候の1つの例です。
私：拡張メソッドを作成するという考えは好きですが、大きな複雑なラムダをパラメーターとして渡す方法は好きではありません。ラムダは、メソッドの実装について多くのことを他の人に知らせます。
ジュニア（私を誤解した後）：はい、完全に同意します。ここでは拡張メソッドを使用しないでください。拡張メソッドは、他の開発者に実装についての知識を強要します。
誤解があり、それは対処されました。しかし、彼の声明には論理のOUNCEさえありませんでした！彼は私の論理を私に逆流していると思っていました。なぜ彼がそれを言っているのか本当に手がかりがないときは理にかなっていると思いました。
短い答え：
それらをエンゲージ（パズルを頭に入れて）、エンパワー（彼らの答えを信頼）。
私たちを駆り立てるのは質問です！ -マトリックス。
一般的に、私の観察では、そのジュニアは自分の世界を持っています-彼らの考え方についての彼ら自身の限られた見方、そして一部には物事に対する自分の熱意/お気に入り/意見。
自分が間違っていることを正面から彼らに伝えることには何の問題もありませんが、最善のことは、彼らに考えさせることです。どうして？他の方法はありますか？同じことをするより良い方法はありますか？私が常に使用する逸話の1つは、「（この問題に対して）3つの解決策を教えてください！」です。
彼らがこれらの解決策について考えるときまでに、彼らは多くの問題を実現し始めます。それは彼らにいくらかの時間の投資を必要とします-しかし、彼らは時間とともに彼らの思考の限界と欠点を視覚化する傾向があります。彼らはそれを"私はそれを考えていませんでした！"としてもっと見始めます"私は間違っていた！"または悪い"私は有効な視点を持っていても教えられた/間違っていると証明された"。
一般的に、非常に幼い子供はtechnicalの問題（どのデザインパターンが適切に機能するかなど）に関連する傾向がありますprocessの問題よりも時間がかかりますそれら、それは動作します。
しかし、彼らが意見を異にしたり、理由を尋ねたりすることはほとんどありません。そして最近、私は彼らが盲目的に私の声明に同意し、彼ら自身の意見を形成していないというより明白な兆候に気づいています。
これは通常、あなたがdo彼らの提案を受け入れる結果ですが、後でそれらを却下し、彼らはあなたの見解について同様に確信が持てません。あなたが先輩だからといって、彼らは戦いを避けています！
私が過去の上司の1人から学んだ最高のもの：彼はチームメンバーに最初に議論するように頼み（彼らはここではかなり平等に感じます）、うまくいけばすべての議論が尽きた後、彼はたった1つの質問で部屋に入ります-「何が意見の相違点は？」 -重要なのは、人々は常にディベートやディスカッションに参加することを好みますが、彼らの（有効な）ポイントが次回行動に移されない場合、ディスカッションに参加する価値がないと感じます。
ソフトウェアだけでなく、どこにでも、最終的には最も権限を与えられたチームメイトだけがシステムに質問するだけでなく、返信することになりますdare。
後輩に自分で考えてもらいたい場合は、修正しないでください。自分自身を修正にしてください。
解決策のどこが悪いと思うかを伝えるのではなく、適切な質問をしてください。あなたの例では、拡張メソッドを使用している誰かがラムダを作成するために何を知る必要があるかについて彼らに尋ねることができます。 theyが問題であることを示唆するまで、このような質問を繰り返してください。そうすれば、彼らは彼らの解決策が問題である理由を理解し、さらにそれから学ぶ可能性が高くなります-単に彼らの解決策が間違っている、それは外部の判断であり、簡単に無視されると彼らに伝えれば。彼らが自分で（少しのプロンプトで）実現に至った場合、彼らはそれがどれほど根拠があるかを理解し、彼らの間違いから学ぶ可能性がはるかに高くなります。
さらに、これはあなたのジュニアにデザインを守る機会を与えます-おそらく彼らはhave問題を考え、あなたの懸念に対処する正当な理由があります。これにより、エグゼクティブフィアットによって判決している認識（意図的ではないにせよ）が減ります。
複数のジュニア開発者がいるので、コードレビューを1対1ではなくグループとして行います。
グループに「他にどのようにして問題を解決できるでしょうか？」と質問し、他のジュニア開発者が最初に実装を提案できるようにします。他のチームメンバーが話し、誰もあなたのアイデアに似たものを提案していない場合にのみ、実装を追加してください。
次に、ジュニア開発者が何であるかを知らされることなく最高の実装を選択するように導くことを目的として、さまざまな実装の相対的な長所と短所について円卓会議を行います。
ジュニア開発者のための信頼ビルダーとして、あなたが最良のオプションだと思うものを選んだいくつかのケースから始めて、代替案を半明白な欠陥のあるストローマンにして、元の実装がなぜ最高であるかについての議論を指示することができます。
私が最初にプログラミングの仕事を始めたとき、私はあなたが説明したのとまったく同じことをしました：私ができることについて言われたとき、私はいつも同意します。それは主に私が別の言い方をするのに十分な経験がなかったからでした。
方法論やアイデアを実際に議論できるようになったのは、経験から学んだり、さまざまなアプローチや新しいテクノロジーについて読んだりすることでした。チームが自分で考えるためには、「過度に複雑で複雑な」コードなどからどのような問題が発生する可能性があるかを実際に知る必要があり、彼らが実際に見つける唯一の方法は経験を通してです。
個々の思考を促進する良い方法は、Stack OverflowやProgrammers SEなどのプログラミングWebサイトを調査させることです。これらがさまざまな技術について学ぶのに役立ち、チームの上級メンバーと盲目的に同意する代わりに、彼らと話し合うことができたことを知っています。
重要なのは、経験がなければ、シニアメンバーからの提案は常に彼らに正解であるということです。
あなたの投稿からのやり取りは、ほとんどすべてを教えるための重要な原則を示しています：彼らがあなたが言ったと思うことを説明するように依頼してください、そして応答を注意深く聞いてください：何を修正する必要があるかを正確に教えてくれます。
私が持っています 恥知らずに盗まれた 約25年前に私の数学の家庭教師からこのトリックをコピーし、それ以来私は失敗していません。私は、授業でアシスタントとして、ソフトウェアデザインについて話すときは職場で、彼女の学校の割り当てについて話すときは8歳の生徒と一緒に、それを使用しました。
もちろん、あなたがいつも言ったことを繰り返すように彼らに頼むことについて必ずしも率直であるとは限らないので、あなたの戦略を調整する必要があります。たとえば、OPからのフォローアップステートメントを「精査」質問として言い換えると次のようになります。
拡張メソッドを作成するというアイデアは気に入っていますが、大きな複雑なラムダをパラメーターとして渡す方法は好きではありません。 この複合体ラムダが他の人にどのように知らせているかを見てください
過度にメソッドの実装に関する特定の事柄？
この質問は、強調しようとしている問題を理解せずに正しく答えることは不可能です。私が今言ったことの分析を必要とする質問で説明を終えると、学習プロセスがスピードアップし、修正を行う必要があるというフィードバックが得られることがわかりました。
通常、人々があなたが望むことを言っていないとき、それはあなたがあなたのリスニングに取り組む必要があることを意味します。聞くことは、判断を下す前に彼らのデザインの理由を聞くことを意味します。それは単に反対することを許可することを彼らに伝えるだけでなく、彼らが言っていることを正直に考えて修正するだけではなく、証明を意味します。彼らのソリューションの良いところを探し、それらを組み込むようにソリューションを修正してください。
あなたも模範を示す必要があります。素晴らしいコードを書くことではなく、自分のデザインについて意見を求めてもらうことです。事後のコードレビューを待たずに、ずっと一緒に作業してください。 「私のインターフェースは複雑すぎるようですが、それを簡素化する最善の方法がわからない」のように言います。そして、最初に自分の考えに偏らせることなく、回答する時間を与えます。
私がこれに対処しなければならなかったとき、私は（正直に）次のようなことを言っています：
ご存知のように、これは私が考えたこともないような非常にクリエイティブなソリューションです。どのようにスケーリングしますか？/概念的に単純なアプローチで、開発を迅速化したり、メンテナンスを容易にしたりできると思いますか？構成は次のようになりますか？
これは通常、人々を新しい方向に向けるのに十分でした。
責任は彼らを助けることができる一つのことです。
私は過去に1、2チームを率いてきましたが、後輩を輝かせたのは個人の責任の重荷でした。彼の行動がある時点で彼に関係しているかもしれないことに気づくとき、彼/彼女は通常彼がしていることで彼自身のほんの少しだけをコミットします。彼らが自分の仕事を感じたとき、良い結果がはるかに満足できることは言うまでもありません。
彼らが盲目的にあなたをフォローしているという事実についてはあまり心配しません。これが彼らが後輩としてやるべきことです。問題は、コードレビューで対処する項目の真の理由が、ソフトウェア開発者、管理者、およびコードがひどい別の場所に移動して機能するまで理解されないことです。
その時までに彼らは習慣から良い習慣を学び、他の人が犯すコーディングと設計の間違いを乗り越えなければならず、彼らは今や不十分に設計され実装されたソフトウェアに取り組む必要があることを強いられます。
これは彼らのキャリアのある時点で最終的に必然となるでしょう。優れたコーディング標準と実践に慣れることで、優れたサービスを提供しています。残念ながら私たちのほとんどは難しい方法を学ばなければなりませんでした。
与えられた例に基づいて、私はあなたのコメントを質問でフォローアップすることがおそらく最善の方法だと思います。コメントと一緒に質問しても、少なくとも同意するか同意しないかは、少なくとも何かを実装する方法について考える必要があります。
例えば「拡張メソッドを作成するというあなたのアイデアは好きですが、大きくて複雑なラムダをパラメーターとして渡す方法は好きではありません。ラムダは、他の人にメソッドの実装について多くのことを知らせます。実装するためのより良い方法を考えられますか？それほど多くの情報を公開しないこの拡張メソッド？」
これにより、開発中の障害を確認できると同時に、アプリケーションに導入された問題を解決する機会が与えられます。