「なぜ」という答えを得ずにプログラマに質問する方法

私たちは皆この経験をしました。質問への回答を知っている人に行き、その人に質問すると、彼らは典型的な回答「なぜ？」で答えます。あなたはあなたが知る必要がある理由を説明し、彼らはあなたの問題を解決しようとします。

会話を元の質問に戻してその答えを得るには、時間がかかり、腕をひねり、忍耐が必要です。

プログラマーがこれを常に行うのはなぜですか？また、プログラマーが年をとるにつれて行動が悪化するのはなぜですか？

元の質問に対する答えを抽出するのに最も効率的な方法でプログラマに質問をする方法はありますか？

誰かがソリューションの実装方法を尋ねたときに、なぜ開発者が「なぜ」と尋ねるのですか？

ソリューションが実際にソリューションを実装するよりも適切かどうかを評価するには、より多くの知識が必要だからです。

「これを行う方法がわからないが、私がする必要があることは確かだ」と言うとき、誰かを信じることは非常に困難です。人々は常に間違った質問をすることを主張するので、プログラマーは常により深く探ることを主張します。はい、最終的に元の質問に戻ってくる場合もありますが、常にではありません。

類推として、誰かがメカニックに近づいて、車のバッテリーを交換する方法を尋ねたとします。通常、欠陥のあるバッテリーを診断する資格がある場合は、交換する資格があるため、メカニックは交換が必要かどうかを尋ねます。

彼はこれを行わないかどうかを知っており、バッテリーを必要としないことがわかります走っていない。あなたに前もって尋ねることによって、彼はあなたの時間を浪費しているように感じますが、彼はあなたの両方からもっと多くの時間を節約する可能性があることを経験から本当に知っています。

したがって、質問の列を避けたい場合は、あなたが話していることを知っていることを前もって彼に納得させる必要があります。

「具体的には、質問をするために他のプログラマーとどのように関与し、他のプログラマーが答えを持ち、質問が行われている理由についての議論をスキップするかです。」

少なくとも決定論的にはできません。他のプログラマーは人であり、コンピューターではなく、使用人ではありません。あなたが彼らに質問をすると、彼らは彼らが最良の答えだと思うものを選ぶようになります。彼らはより多くのコンテキストが必要だと思うなら、彼らはそれを求めます。

質問の前に、短い、最終的な答えだけを探しているというステートメントを付けて試してみることもできますが、彼らは、彼らが最善だと思うので自由に答えることができます。

問題は、具体的には、他のプログラマがどのように質問をするか、他のプログラマがどのように答えを持っているか、そしてなぜ質問されているのかについての議論をスキップすることです。

できません。プログラマー、特に優秀なプログラマーは、問題を解決し効率的にするために配線されています。顧客や仲間のプログラマーが答えを探しに来るとき、彼らは解決策を提示する前に、彼らが解決しようとしている問題を確実に知るでしょう。そうすれば、彼らは効率的であり（あなたの問題を解決しない答えを与えることであなたと時間を無駄にしません）、彼らは本当の問題を解決しています（あなたが尋ねるべき質問の解決策/答えを与えることによって）。

例-クライアントがあなたに来て、X機能を実装したいと言ったとき。クライアントがX機能を本当に必要としている場合があり、Xを必要とせず、完全に異なるものが必要なことを知るために、顧客を掘り下げて調査する必要がある場合があります。プログラマーが年長で経験豊富なほど、過去に解決策を提示する前に問題の核心に到達しないために火傷を負った可能性が高くなります。

要約すると、質問に正確に回答する場合は、次のことを確認する必要があります。

• 適切な質問をする（したがって、事前に問題を調査する必要がある）
• 問題のコンテキストを提供する
• 調査の一部を共有して、問題をより迅速に導きます

私が知っているほとんどの人間は人間であり、コンピューターではありません。答えが欲しいだけならグーグルで試してみてください。

プログラマーがこれを常に行うのはなぜですか？また、プログラマーが年をとるにつれて行動が悪化するのはなぜですか？

残念ながら、一般的な真実とは程遠いものです。

その振る舞いは本当に良いものの少数に制限されています。そして、あなたもそれを学ぶべきです。

理由を飛ばすとてつもない質問に答えるだけで、素早く確実にキャズムに乗り込むことができます。

教養のある部分を本当にスキップしたい場合は、制限のいくつかの文と質問をスキップしたいという質問の前に質問を置くことができます-答えを得るか、ただ送信することができます。あなた自身の研究の要約を提示することは、より良いアイデアです。

ここでのすべての答えは「なぜ」質問に対する良い答えですが、OPsの質問には誰も実際に答えていません。

元の質問に対する答えを抽出するのに最も効率的な方法でプログラマに質問をする方法はありますか？

答えは驚くほど簡単です：方法を尋ねる前に、なぜこれを行う必要があるかを伝えてください。

最善の方法は、製品に関するいくつかの高レベルのミーティングに開発者を含めることです。この特定のことを行う必要がある理由がわかるように、より大きな画像を提供してください。彼らは、最初の方法を思い付くことであなたを驚かせるかもしれません。

優れたプログラマーは、単にソリューションを実装するだけではありません。特定の問題に最適なソリューションを実装したいと考えています。これには情報が必要です。質問は情報を収集する方法です。すべての情報がなければ、プログラマーは、すべての要件に適合しないソリューションを実装する危険にさらされており、それをやり直すことに固執することを知っています。プログラマから情報を隠さないでください。情報を隠すことは時間を浪費し、士気を破壊し、劣った解決策につながります。

プログラマーは問題を解決するために「ハードワイヤード」されています。

優れたプログラマーは、「正しい」問題を解決しようとします。

誰かが求めているものを提供するだけで、多くの場合、解決すべき問題が間違っています。

MS Officeの自動化が大流行した時代には、通常は数週間かけて、あるOffice製品で「これ」を実行し、他の製品で「それ」を実行する方法を尋ねる一連の質問が表示されます。 、それから別のものに再び何か。これらのそれぞれはすぐに対処されますが、「問題」-まだ完全には述べられていません-は解決されていません。彼らは、チェーン内の次の「リンク」のために戻ってきます。

それらを停止して「なぜ？」その後、彼らは達成したいことを後戻りし、より広く説明しなければなりません。彼らの目の前で問題を説明するだけではありません。（ところで、プログラマーは、これらのようなフォーラムが証しをする他の誰かと同じくらい（これ以上ではないにしても）これに苦しんでいます）。
ユーザーの「大きなデータベースからAccessにデータを取得し、Excelにデータを少し送ってからWordに送信して、結果をメールでマージし、毎週これらのユーザーにメールで送信できる」というチェーンは、すぐに置き換えられます。そのすべてを実行するバッチジョブ。結果は月曜日の朝に人々の受信トレイに最初に置かれ、ユーザーの関与は一切ありません。

そのようなユーザー。

私たちはあなたがどこに行こうとしているのかを知る必要があります。

または、（Monty Pythonを言い換えると）：「5分間の回答が必要ですか？

プログラマが小数点以下3桁の数字を入力した場合に対応するかどうかだけを知りたい場合、プログラマーが特定の関数のすべての詳細をガタガタ鳴らすことはありません。

あなたの視点を知ることは、しばしばあなたが得る答えを根本的に作り直すことができます。

最後の質問は、「元の質問に対する答えを抽出するのに最も効率的な方法でプログラマに質問をする方法はありますか？」です。

まず、「効率的」と「効果的」を混同します。最も効率的にするには、「答えは何ですか？」と書くだけです。紙の上でそれをプログラマに見せてください。それは質問をする非常に効率的な方法です。また、答えを得るのに非常に効果的ではありません。

次に、ソフトウェア開発者は質問回答者であると想定しています。ではない。彼らは問題解決者です。あなたの態度は、あなたが問題解決を理解していないことを明確に示しています。問題を解決する最も効果的な方法は、問題を問題解決者に説明できるところまで理解してから、問題解決者に提示することです。もう1つの方法は、できる限り問題を部分的に理解し、問題解決者に不完全な理解を提示することです。問題解決者は、最初にこれを完全に理解された問題に変えるために恐ろしい質問をし、それを解決します。

非常に非効率的な方法は、あなたがしようとしている方法です。問題を完全に理解せず、この問題の解決方法を推測し、問題解決者にこの解決方法を達成する方法を尋ねます。問題解決者は、以前にこの動作を見てきました。未経験の場合は10回、経験のある場合は1000回。したがって、問題解決者は、あなたが完全に間違った方向に向かっていることを知っています。そして問題解決者は、正しい方向に進むために必要なことを行い、実際の問題を理解するための質問をします。問題についての不完全な理解を理解するための最初の質問と、実際の問題を理解するための追加の質問。

何を達成したいと何をして作業している状況があるのexplicitatingで質問を開始します。あなたが与える場合は十分なコンテキストを、あなたが取得することはありません「なぜ？」、「これは本当に必要ですか？」

なぜなら、統計学的に、ほとんどの提案の特徴は吸う、および実装するための面倒な価値はありません。

典型的な反論は「しかしそれは彼の仕事」 だろう。彼の仕事は良いコードを書くことであり、ほとんどの機能は動作中のコードベースの再設計とこの「再設計」を必要とするため、通常、機能の追加はそれに反します。

1. 永遠にかかります
2. 新しいバグを追加します
3. かつて働いていたものを壊します
4. メンテナンスを不浸透にします

それは良いコードではありません、良いコードは最小限です。