どうすればエラーメッセージを読むように人々を促すことができますか？
コンパイルが失敗したときにエラーメッセージを読むように人々を促すためのいくつかの良い方法があるかどうか疑問に思っていました。
人々（特に）の後輩は、通常、エラーメッセージを無視して、助けを求めます。私は彼らがより良くなり、アイデアを使い果たしてほしいと思っています。これらは私が試したものです。
- コンパイルが失敗したときにエラーメッセージをチェックするように指示します。
- 座ってエラーメッセージを確認します。
- 彼らが私に助けを求めるとき、私は彼らがエラーをチェックしたかどうか尋ねます。
似たような経験があれば、どう対処するか教えてください。
すぐに助けてはいけません。ジュニアの同僚に少なくとも15分間待機させ、この15分のサイクルの1つまたは2つ後、彼/彼女は自分で問題を検討し始めます。 「15分待って」と直接言うのではなく、「忙しいので、xを終わらせてから、お手伝いします」のようなものを使用します。
彼をすぐに助けるなら、これは彼が問題の解決のために持っている最短の道です、そしてもちろん彼はこの道を使います。しかし、代わりにあなたが言った場合、私はあなたを助けて問題を解決しますが、私があなたを助けることができる前に15分間待ってください。この間、彼は画面を見つめ、この「待ち時間」に何を試みるかを確認します。 、彼はおそらく自分でエラーメッセージを確認します。 :-)
彼らが自分でエラーを探し始めない場合は、その人には主導権や経験がないと言えます。問題が主導的である場合、解決することは困難です。一緒に1つまたは2つの分析を行った後の経験であれば、彼らはそれを理解し始める必要があります。
私はシニア開発者が同じ間違いを犯しているのを見つけました。これが、「気にしない」ではなく圧倒されている兆候だと私が思う理由です。
私の反応は常に同じです。「動作しない」と聞くと、「どのエラーメッセージが表示されますか？」と質問します。 （そして私は礼儀正しくするよう努めます）。
答えは、その人がもう一度考え始める前に、Steamをベントする必要があるかどうかを教えてくれます。誰かがこの状態にある場合、彼らは単に聞くことができないため、世界中のアドバイスは機能しません。まず、落ち着かせてください。
怠惰だった場合は、戻ってエラーメッセージを読むように要求します。それが何を意味するのか、どのように解決するのかを彼らが知っている必要があると思われる場合は、「これを引き起こす可能性があると思いますか？」、「fooの意味」、「何を変更しましたか？」エラーが発生する直前？」ほとんどの人は質問されたときに助けようとするので、質問することは他の誰かの脳をキックスタートする良い方法です。そのため、実際に彼らを「支援」しなくても、これは肯定的なサポートとして受け取られます。
彼らが単純に何が起こっているのか理解していない場合は、彼らと一緒に座って、エラーを修正する方法を説明します。私は2つの理由でエラーを自分で修正する傾向があります。
- 脳は、自分がやったことを他の誰かがするのを見るのではなく、よりよく覚えています。
- 彼らが説明を理解していない場合、それは彼らに尋ねる機会を与えます。
私が自分でエラーを修正する場合、彼らが今は機能しているコードを持っているがなぜなのか分からない危険が常にあります。
PS：これはすべての上級開発者に行きます：より良いエラーメッセージを書いてください。適切なエラーメッセージは、問題を修正する方法を説明します;悪いのは「エラーが発生した」の変形です。
したがって、File not foundの代わりにFile ...path... not foundと言います。 Glabarfel couldn't be initializedの代わりに、Glabarfel wasn't initialited properly; missing Foo. See http://.../docs/setup/glabarfel/foo.html for details.と発声してください
これは動作変更の質問ですが、開発チーム環境で対処する必要があります。あなたの後輩の開発者はサポートやバグ修正をしなければなりませんか？他の情報なしで誰かが「エラーが発生しました」とだけ言ったときの気持ちを尋ねます。彼らが愚かなユーザーに対処しなければならないときにおそらく続くすべての名前の呼びかけを避けることができます。
エラーが発生したと彼らから言われたら、エラーメッセージを教えてください。彼らはそれを電子メールに含めたり、ある種のバグ追跡システム/チーム情報/ wikiシステムに登録したりできます。このようにして、他のユーザーは、再発したときにこのエラーメッセージの解決策を調べることができます。
あなたは勤勉である必要があります。メッセージを求めます。以前の解決策のメッセージを調べたかどうかを尋ねます（ユーザーに伝えるように）。役に立たないと見なされたくないので、それが新しい問題である場合は、できるだけ便利に対処するようにしてください。これらのエラーの文書化に貢献した人を褒めましょう。
チームとして、中断の問題に対処する必要があります。答えをすぐに知っている人に尋ねるだけの方が便利に思えるかもしれませんが、コードから引き離されると、他の問題や長期的な遅れが生じます。ジュニア開発者はこれを学ぶ必要があります。
「コンパイルが失敗したとき」...そのような場合、私はあたかも、新しく、困難で、経験が必要なエラーを支援するかのようにそれらに行きます... 「それから、コンパイラーによって表示されたエラーメッセージを読み、それが実際にエラーメッセージの処理のケースである場合は、最善の「あなたは子供です」の顔をしました。 、なぜ彼らが自分でそれを読むことができなかったのかを尋ね、それから立ち去ります。
彼らが尋ねたとき、あなたは本当に彼らを助けられないでしょうが、彼らがあなたの時間を浪費しているなら、あなたはそれについて軽蔑することができます。
- コンパイルが失敗したときにエラーメッセージをチェックするように指示します。
- 私は座って、彼らと一緒にエラーメッセージをチェックします。
- 彼らが私に助けを求めるとき、私は彼らがエラーをチェックしたかどうか尋ねます。
あなたが書いているものから、あなたの後輩はあなたの解決策を本当に理解しておらず、前のものと100％同一ではない他の状況でそれらを適用することができないか、彼らがあなたが魔法のソリューションの妖精とあなたを悩ませることは、彼らの問題を取り除く最も速い方法です。
幸いなことに、ほとんどの場合、あなたは同じ方法で彼らを助けることができます：あなたの知識ではなく分析的な質問で彼らを導きます。
「何が問題のように思われますか？」時々、あなたに問題を説明しようとするだけで、彼らの答えが明かされます。少なくとも、それはあなたに彼らの参照の枠組みを調べることを可能にし、重要性を過小評価してはいけません、彼らが問題であると認識しているものをあなたに伝えます。
"documentation/Google/whatever say？"彼らは少なくともそれを理解しようとしたと仮定します。彼らがそうしていない場合、彼らがそれを調べている間、彼らと少し一緒にいてください（先にジャンプして解決策を与えないでください）。解決策がある場合は、友好的なさよならを与えて、喜んで助け、仕事に戻ります。そうでない場合、または実際に適用できない場合は、次のビットに進んでください。
根本的な問題を見つけることを通してそれらを歩きます。関数はすでに定義されていますか？他に関数を定義できる場所を尋ねます。必要に応じて、検索機能を指定してください。未定義の変数？定義した場所を確認し、スペルを精査するように依頼します。予期しない
if？これは本当に新しい声明の始まりですか？前のものを終了しましたか？（知識を身に付けたりアリストテレスの教え660に行ったりする必要はありませんが、解決策を見つけるために必要な手順をガイドする必要があり、オープンで忍耐強くなければなりません。）
問題の原因を見つけたら、うまくいけば解決策は簡単です。そうでない場合は、ジュニア開発者が、初心者には明らかではない実際の障害にぶつかります。
しかし、これはあなたの以前のアプローチよりも長くかかりませんか？恐らく。このアプローチの原則は3つあります。
あなたは人々に彼らの問題の解決策を見つける方法を教えます。特に、アクション（エラーメッセージ）からのフィードバックを分析することは、解決策を見つけるために重要です。これにより、独立性が向上するだけでなく、分析的思考同様に、最終的には自動化された環境で自宅にいる人を増やすか、少なくとも、他の人を積極的に妨害する可能性を低くします。
あなたは彼らがばかであるか怠惰であると思い込みません。これにより、彼らはあなたに耳を傾け、あなたの例に従う可能性が高くなります。解決する必要がある実際の真正な問題として彼らの問題に取り組みます。誰が知っているか、多分そうです。
あなたが理解できない問題を解決するために助けを求めても大丈夫であり、コーチして彼らが解決策を見つけて学ぶのを助けても構わないが、あなたがそうではないという文化的（チーム）標準の確立を助けるオフィスの魔法の解決の妖精、そして彼らの側から少なくともトークンの努力がなければならないこと。エラーメッセージなど、入手した情報を把握することが最も基本的な手順です。