バグをすばやく解決する方法はありますか？上司から警告を受けました
月曜日に否定的な業績評価を受けると上司から言われたところです。なぜ私が遅いのか、なぜバグ修正率が低いのか、彼は私に話したいと思っています。
私はプログラミングと問題解決が大好きですが、実際には自分の仕事が本当に難しいと感じています。
私は実際にプログラマーとして約10年間働いています。しかし、これは私の最初のマルチスレッド組み込みLinuxジョブです-私はここに2年間いるので、私がまだ苦労していることは誰にとっても明らかです。そして、私は非常に士気が低下し、非常に疎外されたと感じ、仕事の始めに持っていた火の多くを失いました。
誰かが同じような状況にあったことはありますか？バグ修正率を上げるにはどうすればいいですか？
更新：レビューがありました。私は3か月の「従業員開発プログラム」（ダンクが言及したタイプ）を課されました。私はこれを好転させることができるかどうかわかりません。しかし、先に進む必要があるとしても、私はこの経験から多くを学びました。
別のアップデート
最初のレビューから約6週間になります。同じ状況に直面している人への私のアドバイスは、批判を受け入れ、あなたの過ちから学ぶのに十分控え目であることです。そして、馬鹿に見えるのを恐れないように。たくさんの質問をしてください。あなたが学習しようとしていることを人々に知らせ、理解するまで尋ね続けます。しかし、うまくいかない場合に備えてください。私はコードのポートフォリオを構築しています...それにベストショットを与えています。
さらに別のアップデート
私はこれをここに置くのをためらっています。これは、将来の雇用主を私のstackoverflowプロファイルに参照できなくなるのではないかと心配しているためです。数週間前に仕事。私は必要なすべてのスキルをブラッシュアップしている最中です-私はここで与えられたアドバイスから多くを学びました。
多くの回答が上司の方法/戦術/測定基準などに疑問を投げかけています。しかし、それは要点の外です。多分あなたは遅いです。開発者の各部屋には、他の部屋よりも遅いONEが必要です。 （これは、単なるセット理論です。）では、それがあなたであると仮定しましょう。答えは、なぜあなたは遅いのですか？ （明らかに、それはあなたが速くなる方法についてあなたが述べた質問を解決する前に答えなければならない質問です。）
さまざまな理由がある可能性がありますが、考慮すべきいくつかの説明があります：
あなたは彼らよりも知的ではありません。可能ですよね？ （私たち[〜＃〜] all [〜＃〜]は less-popular 、 less-interesting =、そして（それに続く）私たちの友人よりもインテリジェントではありません。次に、あなたの場合、これはありそうにないと思います。 StackOverflowプロファイル をざっと見ると、幅広いトピックについてインテリジェントな質問をしてきた歴史があることがわかります。あなたは明らかに思想家であり、おそらくその点で優れた人です。
広がりすぎます。同じですSOあなたのプロフィールは、あなたの質問が非常に広い範囲をカバーしていることを示しています過去2年間のテクノロジー（グラフィックス、ウェブ、Python、C++、C、Linux、組み込み、スレッド、ソケットなど）個人的には、私は（または）必要な状況に置かれていることを知っています。さまざまなストリームがたくさんあるので、私は現在のスピードが非常に速い（または、むしろslowです）と思います。おそらく、ここで本当に必要なのは[ 〜＃〜]フォーカス[〜＃〜]そしておそらく優先順位付けの健全な線量とにかく重要性の低いポットを後ろに置くことができますか？バーナーとメインディッシュの熱を上げますか？
あなたは楽しんでいません。火が消えると、Steamエンジンは減速する運命にあります。あなたのポストであなたの士気が最近ひどい打撃を受けたことを認めました。残念ながら、自己強化型の負の高調波の吸い込み渦に飲み込まれています-できる力 ブリッジを破壊する 。それはあまりにも親しみのあるスパイラルです：困難なタスク->ストレス->期限の遅れ->より多くのストレス->不十分な対処メカニズム->より多くのストレス->先延ばし->より多くの期限の遅れ->批評/ゴシップ（現実または想像）- >さらにストレス。あなたは写真を取得します。これが役立つ場所につながることはめったにありません。私の急流ラフティングの日々からレッスンを受けてください：クラス4急流の裏側の循環流によって水中で吸い込まれると、ライフジャケットは浮上して水面に戻ります。最良の戦略（直感的ではありませんが）は、川のbottomを見つけ、波のwalk outを見つけることです。だからあなたへの私のアドバイスは：地面、男、（友達、教会、健康的な新しい習慣など）を見つけてそれを利用して渦からあなた自身を歩き回らせることです。
あなたはあなたのゾーンにいません。マイケル・ジョーダンはかなり下手な野球選手を作りました。 （OK、彼は私よりもまだ優れていたが、間違いなくマイナーリーガーだった。）多分「マルチスレッド組み込みLinux」はあなたのギグではない。しかし、ソフトウェア開発は非常に広い分野です（ご存じのとおり、上記の＃2を参照）。あなたの会社はあなたが別のニッチを見つけることができるのに十分広いですか？私の最後の仕事で私は組み込みソフトウェア開発者として雇われました。 （私はその領域での経験はありませんでしたが、私は「迅速な学習者」であると彼らに言いました。）私はすぐに石のように沈みました。しかし、私は懸命に働き続け、私がdidがそれらの解決方法を知っている問題を探し続けました。結局、次第に自分を輝かせることができる新しい責任に移ることができるようになり、最終的にはかなりの表彰を受けました。だから、おそらくあなたは自分でブランドを変える必要があります。
重要なのは、遅い場合は理由があります。しかし、hey-あなたはソフトウェアエンジニアですよ！ 自分でデバッグしてください！
あなたの上司は正しいかもしれません：あなたは「パフォーマンスが悪い」かもしれません（これについては後で詳しく説明します）。しかし、責任があるのはあなたの能力レベルだけではないかもしれません。あなたのコントロールの外の力があなたにストレスを引き起こしていることを示唆するのはリーチではないと思います、それはあなたのパフォーマンスに悪影響を及ぼしています。
あなたの上司がこれを持ち出した理由のいくつかを見てみましょう：
文化と政治
上司に懸念を表明するように要求する力があなたの手に負えないほどあるかもしれません。あなたが働いているシステムを理解することは重要です。あなたの仕事はあなたの上司を美しく見せることです。それを行う唯一の方法は、彼/彼女が受けているプレッシャーを理解することです。
能力
彼が公然と述べたように、能力が標準に達していない可能性があります。この状況で私が行うことは次のとおりです。
上司からパフォーマンスの測定方法について特定のフィードバックを取得します。 X人ほど多くのバグをクローズしていませんか？解決すべきバグはいくつかありますか？一人で作業している場合は、パフォーマンスを測定している人々が、何らかの先入観に基づいてではなく、公正に測定していることを確認する必要があります。
パフォーマンスが遅く、実際のギャップに基づいている場合は、そのギャップを特定し、それを閉じることを目的として上司と一緒に詳細な計画を作成します。
このレビューは、あなたが幸せではないという事実を育てる良い機会でもあります。あなたがこの仕事を好きではないことがわかったのは良いことです。しかし、その理由を理解してください。あなたの仕事のどの部分が好きで、何が嫌いですか？この仕事はあなたのためではないかもしれません...
一部の作業環境は機能しません。あまりにも多くの情報が文書化されておらず、質問が激しく抑えられていたため、誰も生き残ることができない環境（最初にいた人のために保存）を見てきました。
期待に応えるために提供される期待とリソースについて、自分に正直である必要があります。問題はあなたではないかもしれません。
あなたと同じような仕事をしている人たちがいるとおっしゃっていますが、私は困難はないと思いますが、2年以上5年以上の経験があります。彼らはあなたを完全に（この点で）上回っているロックスターですか、それとも彼らはあなたと同じですか？多分彼らはそれがより単純だったときにシステムを知るようになっただけです...あなたはこの仕事の前に8年のプログラミング経験があると述べました。そこでどうしたの？あなたが素晴らしかったなら、それはあなたに何かを伝えるはずです。
私を驚かせた部分は、あなたがあなたの方法でやって来るすべてのバグに関して暗闇の中でであるとあなた自身を説明していることについてのビットです。コードベースが広大で未知であるため、期待が妥当ではない可能性があります。
あなたが自分のできる限りそれを成し遂げるということは、あなたが何か正しいことをし、あなたのために何かをしていることを意味します。
結論としては、自分自身について、そして自分が何をしているのかについて、気持ちを良くする必要があると私は思います。そして、それが先へ進むことを意味するのであれば、そうです。
仕事があなたの人生を台無しにするよりも先に進む方が良いです。
まず、注：この回答は、退職なしに従業員を解雇することが違法である特定の地域にのみ適用される場合があります。それは言った...
これはConstructive dismissalの場合であり、これは違法です。
戦術は、従業員が仕事を辞めるまで、士気を落とし、自尊心を下げることです。それは会社が退職金を支払う必要がないことによってお金を節約する方法です、または従業員に立ち向かい、解雇しなければならないという問題を解決します。
なぜ私が遅いのか、なぜバグ修正率が低いのか、彼は私に話したいと思っています。
この障害は非常にあいまいです。党の一方が他方を間違っていると主張することは不可能です。 1つのバグを修正するのに1か月かかりました。だから何！これにより、1か月が必要だったという主張を裏付ける事実を提示する必要があるため、防御的な立場になります。あなたの現在のスキル、経験、知識を要因として考えてください。雇用主として、彼の従業員の時間と労力を管理するのは雇用主の仕事です。雇用者は、バグの修正に関連するリスクに従事している人物でなければなりません。従業員ではありません。彼は常にバグを他の誰かに割り当てるという選択がありました。
あなたが請負業者であり、バグの修正を担当することが契約に明記されている場合、それはまったく別の話です。
雇用者があなたが時間がかかりすぎると文句を言うのは間違っていますか？絶対にそうではありませんが、彼はあなたにそれを説明する責任を負わせることができず、彼はあなたを解雇することはできません。 「私たちにはあなたのスキルを必要とするバグはもうありません、そしてあなたは休暇を取っています」と彼はあなたに言うことができます、しかし彼らはあなたが修正できる新しい問題が出てきた瞬間をあなたに知らせなければなりません。それ以外の場合は、切断して終了する必要があります。彼ができないことは、あなたが扱えない仕事をあなたに与え、そしてそれについて不満を言うことです。これは違法だと思います。
私はプログラミングと問題解決が大好きですが、実際には自分の仕事が本当に難しいと感じています。
あなたが一生懸命見つけた仕事をすることと、あなたの雇用主があなたに大変すぎる仕事を与えることとの間には大きな違いがあります。あなたに割り当てられたタスクが会社でのキャリアを妨げるように行われたと感じた場合、これは違法である可能性があります。
私は実際にプログラマーとして約10年間働いています。しかし、これは私の最初のマルチスレッド組み込みLinuxジョブです-私はここに2年間いるので、私がまだ苦労していることは誰にとっても明らかです。
これが、あなたが建設的な解雇の真っ只中にいると私が思う理由です。彼らはあなたに不満を持っているので、あなたが去るまであなたにがらくたを積み重ねます。
そして、私は非常に士気が低下し、非常に疎外されたと感じ、仕事の始めに持っていた火の多くを失いました。
雇用主は安全で前向きな労働環境を提供する責任があります。より多くの情報（おそらく個人的なもの）がなければ、部外者がここで実際に何が起こっているのかを言うのは困難です。弁護士に無料相談を依頼してください。彼らはあなたがプレイされているかどうかを教えてくれるでしょう。
参照
私は弁護士ではありませんが、月曜日にあなたのレビューを入力する前に読む価値がある建設的な解雇のトピックを説明するいくつかの文書をGoogleに提出しました。ここでの主なポイントは、給与の低下、屈辱、会社でのキャリアの突然の変化に注意することです。
関連する事実には以下の点に注意してください。
- 困難な労働条件の中で従業員を適切にサポートできない
- 従業員の過度の規律従業員の勤務先を急遽変更する
- 給与または賃金の引き下げを課す
おそらく、プロジェクトの元のプログラマーの1人と比較されているでしょう。私が取り組んでいるプロジェクトの最初の開発者として、そのバグを修正する際に非常に大きな利点があることを知っています。ドキュメントが不足しているからではないと思います。脳がすべてのコードを知っているので、潜在的な問題に直感的にジャンプできるというだけです。
あなたがそれと比較されているなら、あなたはただ測定するつもりはありません。プロジェクトの速度を上げるには常に時間がかかるため、潜在的な相互作用ポイントのすべてがどこにあるかはわかりません。
他のプログラマが問題を解決するために使用しているツールやトリックを見つけられないというコメントを読みました。おそらく、次のバグ修正のためにペアプログラミングを試す必要があります。これは非常に便利です。交互にキーボードを運転してください。 lotを話します。
ノートブックまたはホワイトボードを使用して、関数パス、スレッド、およびロックの有効期間をグラフ化し、動作のさまざまなビットを観察する場所と新しいプローブを挿入できる場所にマークを付けることができます。
この種の低レベルのスレッド化問題を解決することは非常に難しい場合があり、私はあなたに多くの同情を抱いています。 2行の問題を見つける前に、数ギガバイトのログファイルを分析する必要がありました。そして、あなたは何を知っていますか？何年も前からじっと見つめていたのですが、その前の年にインターンだったジュニアエンジニアに助けを求めたところ、彼は新しいアプローチを考え出し、1時間で問題を発見しました。ですから、バグに少し時間を置いた後、そのバグに新しい目を向けてください。それは大いに役立ちます！
この業界で最も一般的な管理機能障害の1つは、デバッグは本質的に難しいであることを理解していません。私は20年近くの経験があり、私はまだプログラムを50回に1回クラッシュさせる1行の間違いを見つけるために1週間を費やす必要があります。そして、私のマネージャーがこれらのことを理解していないと、1行のコードを変更するのに1週間かかるので、面倒です。
あなたはそれについて何ができますか？
デバッグしながらメモを取ります。エディターウィンドウを常に開いて、意識の流れを書き留めてください。それはあなた以外の誰かに意味をなす必要はありません。これはデバッグを高速化するのに役立つかもしれませんが、Nethackを1週間プレイしていなかったことを示すために具体的なポイントがあることも意味します。
すべての同僚とメモを比較します。彼らがバグを修正するのに通常どれくらい時間がかかりますか？彼らのバグは修正されたままですか？彼らはどれほど頻繁に1つの小さなことを変えて、カスケードの影響の山の下に埋もれていると思いますか？これらの質問に対する答えは、あなたが本当にが部門の残りの部分と比較して苦労しているのかどうかの感覚を与えてくれます。
QA担当者やカスタマーサポート担当者と友達になります。それらは、バグがどのように重要であるかについての最良の考えを持つものです。多くの場合、これはdifficultのバグとの相関がほとんどないかまったくないため、システムを少しゲームして、重要度が高く難易度の高いすべてのバグを割り当ててみることができます。 （これは実際には不正行為ではありません。よく編成されたチームは常にこれらのバグを最初に追跡します。）
上司が2年間のパフォーマンスについて十分なフィードバックをしていない場合、これは最初にこのパフォーマンスレビューで取り上げ、次にその上で回避策が与えられたときに上司の上司と一緒にレイズするのは問題です。礼儀正しく、特にあなたがどれほど怒っているのかを見させないでください。ただし、書面で具体的な批判を受けてください。
プログラミングや問題の解決が好きな方もいらっしゃるかもしれませんが、学んでいることを他の分野にどの程度うまく適用しているかという問題があるかもしれません。あなたが修正した過去12か所ほどのバグのどれかが、ある修正に役立つものが別の修正に役立つほど十分に類似していますか？これは、あなたが何をしたか、そしてそれを完了するのにどれくらい時間がかかったかを振り返ることの一部です。検討するだけのアイデア。
第二に、私はあなたがどのようにあなたの仕事をしているのかを見守ります。定期的に中断されていますか？そのため、バグAを修正しようとすると、バグBおよびCが優先度が高いと言われますか？上司が知りたいことの一部である可能性が高いので、仕事のやり方のどのような変更がここで役立つかを慎重に検討してください。
私はいくつかの職場で、私の仕事の一部を完了するのにどれほど時間がかかるか気に入らなかったと言ってきました。もちろん、これらは、私が1つのことを成し遂げた場合、5つの新しいものが私の膝に落とされ、それで圧倒されやすい場所でした。私はもうそこで働くことはないかもしれませんが、一度に1,000のことを習得しようとしているような気分にならないように、いくつかのことに注意を向けさせる良い解決策がありませんでした。実行するいくつかの重要な事柄と自分の作業がどのように判断されるかを知ることができれば、長さ1マイルの「やること」リストを持っている場合よりもはるかに優れています。それの一部が完了しました。したがって、組織内には文化的な要素が含まれている可能性がありますが、ここで変更を求めるように注意します。頻繁にフィードバックを求めた1つの職場で、やるべきことのリストにあるものだけを守っていなかったために終了するまで、最終的にマイクロマネージメントになってしまったことを覚えています。
仕事に就いて2年が経過した後、あなたがどこに立っているかは誰でも（あなた、あなたの上司、同僚）に明らかです。つまり、年に1度しかうまくいっていないことを決して知るべきではありません。理想的な作業環境は、継続的なフィードバックを提供します。
とにかく、マルチスレッドコードのデバッグ方法に関しては、これがyourコードなのか、他の誰かのコードなのかについては言及していません。同時実行を処理できるいくつかの新しいデバッガーと静的アナライザーがあります。しかし、実際には、何を探すべきかがわかるので、パターンを知ることが最善の策になります。
重要なセクション、競合状態、デッドロックがどのように機能するかを理解していれば、予期しないことを発見するのにより適した位置にいることになります。条件変数のない2つのスレッド間の「通信」が見られる場合、またはリソースが特定の順序なしでミューテックスされている場合、またはローカル変数がstaticと宣言されている場合は、明らかな理由がありません。したがって、ドメインのベストプラクティスを学ぶと、何かが異常な場合に判断するのに適した状態になります。
必要がない限り、一人で闘争しないでください。同僚を募集します。バグハントを手伝ってもらいます。彼らの思考プロセスとツールについて尋ねます。おそらく、改善計画の一部としてレビューでこれを言及してください。もしあなたの周りの誰もが上手にやっているとしたらこのシステムでは、おそらく彼らは何か特定のものを知っていますか？
月曜日に否定的な業績評価を受けると上司から言われたところです。なぜ私が遅いのか、なぜ私のバグ修正率が低いのか、彼は私に話したいと思っています。
機能していない会社では、この注文で問題が発生しないことに注意してください。上司があなたのパフォーマンスに関心がある場合、上司は短期的な目標を設定し、結果について話し合って、問題がどこにあるのかを見つける必要があります。
代わりに、彼はあなたに否定的なレビューを与えることを決め、その理由を見つけます。彼は問題に自分を巻き込むつもりはないようで、彼は結果を表にしたいだけです。
バグの迅速な解決を目指してはいけません。あなた自身の能力を評価し、同僚がどのように働いているか、彼らが彼らが知っていることをどのように知っているかをチェックし、これが理想的な会社ではないことを認識してください。
実用的なヒントとして、私はコードスニペットと自分のメディアウィキを使用してメモを取ります。私は常に次に読むべき本と、私の学習を続けるためにどの方向に行くべきかを常に念頭に置いています。学習は、より良い仕事と幸せな人生への道です。
まず、自信を高める：
なぜ苦しむのですか？バグ修正率に関係なく、Linuxが何でも埋め込むことができるからといって、彼らがあなたを「神」だと思ってくれる仕事を簡単に見つけることができます。
とにかく、バグの狩猟に時間制限を設定することは不可能です。バグハンティングは間違いなくスキルであり、その効率は非常に貴重です。
あなたは他の人が知っているいくつかの基本的なトリックを見逃しているかもしれません、それはあなたを遅くします。
たとえば、あなたと私がいくつかのLinuxミドルウェアで作業していて、Valgrindを使用してメモリ破損の問題とデータ競合状態を見つけているのに、gdbとprintfだけに依存している場合、私はおそらくあなたのお尻を蹴りますあなたは私よりも賢いです。
また、 concurrency をどのように理解していますか？ 10年間開発を続けてきたが、その経験のほとんどがマルチスレッドコードに関するものでなかった場合、それは問題になる可能性があります。
マルチスレッドについては、APIの使い方を知るだけでなく、詳細に検討する必要があります。あなたがマルチスレッドプログラミングをしているなら、あなたはマイルベースからコードベースを見て、競合状態、デッドロック、優先順位の逆転、飢餓のシナリオを見つけることができる開発者でなければなりません...
私は最近本 （Working Effectively With Legacy Code を読みました、そしてそれは私にあらゆる問題に取り組むときの自信の大きなブーストを与えてくれますコードベース。
作業しているコードが完璧ではない場合、この本は役に立ちます。多くの場合、バグを修正するために、周囲のコードをリファクタリングして理解する必要があります。次に、理解したらコード、そしてうまくいけば、コードをテスト可能にして、問題を追跡して修正することは、それほど困難なことではありません。 （コードを理解するためだけにコードを書き直すこともありますが、変更を元に戻して、新しいバグが発生するリスクを減らします。その後、バグ修正を挿入します。この手法は、本のトリックに基づいています。）
私の提案はあなたの問題の一部のみを取り上げており、多少間接的ですが、レガシーコードを扱うことはあらゆる開発者にとって必然であるため、この本は何があっても読む価値があります。
あなたが彼らのためではなく、雇用主や顧客と一緒に働くことを認識してください。インタビューでそのことを言及することをためらわないでください、ちょうど最初からまっすぐに記録を設定するために。
あなたは小規模ビジネス、つまり自分自身に多くの投資をした専門家です。
関心のある連合が毎日あなたをラックから追い出す間、あなたは喜んで働きます。
その推進力がしばらくの間存在しない場合は、次に進みます。
あなたは、あなたの関心を継続させたり、スキルを更新したり、課題をやりがいや興味深いものにしたりしない仕事に時間とエネルギーを浪費しています。それが経営者の仕事です。それ以外は、それらは純粋なオーバーヘッドです。
それが鍵なので、あなたの情熱を続けてください。
上司に、バグを修正する速度と、チームがバグを修正する平均速度とは何かを尋ねます。さらに重要なことは、彼に尋ねてくださいバグ修正の速度はどのように測定されますか ...
これは一種のメトリックであり、実際にはメトリックではありません。そうなると、LOCよりも信頼性が低くなります（ただし、異なるものを測定します）。そして、適切な測定がなければ、何かを非難する理由はありません。
助けを求めるのが怖かったので、私も同じような状況にあります。このコメントであなたが言ったことで判断すると...
「しかし、いらいらしているのは、1年半そこに行った後で初めて見つけた特定のツール/ヒント/トリックがあることです。私はチームからチームに転向しました（私はパフォーマンスが低かったと思います）。これらの「隠された」ツールは、時々頻繁に使用されます。」
...私と同じ問題があったかもしれません。デバッグは、そもそもデバッグをそれほど必要としないコードを書くのと同じくらい巧妙です。デバッグの問題を通じて他の開発者の作業を監視することは、非常に教育的です。何かを整理するのに問題があるとき、彼らに助けを求めてください。特に、これまでにない地面をカバーしている場合は。そして、あなたが何も成し遂げられていないので、それがパニックになる時の前に理想的にそうしなさい。
とはいえ、経営陣が何か間違ったことをしているというコメントには同意します。誰かが何かに苦労している場合、否定的なレビューの楽しみが始まる前に、彼らはそれについて助けを得ているはずです。地獄、チームの誰かが苦労していて助けをまったく得られない場合、そのチームのすべてのメンバーが何か間違っていると言います（それは、人々がバグ修正率を非常に注意深く見ていることの直接的な結果である可能性があります）。
OPに欠けているのは、バグを解決するために実行されている繰り返し可能なプロセスまたはメソッドについての言及です。
したがって、最初に、従うプロセスを文書化します。プロセスの各ステップが達成することを意図しているものを必ず文書化してください。
次のようなタスクを持つプロセスの概要を説明できます。
- 報告されている問題が何であるかを正確に理解してください。
- 問題を再現してみてください。
- 問題を小さな部分に分解し始めます
- 問題の考えられる原因を考えてください。
- それらの仮説をテストする
バグが長い間存在していたか、または最近の変更で導入されているかを知ることは役に立ちます。最近の変更でバグが導入された場合、コードレビューを行ったり、人々が作成しているコードを読んだりするだけで解決する場合があります。
たとえば、「バグを解決しようとするときにテストする仮説を考えるのに苦労している」など、問題を明確に定義できれば、より的確なアドバイスを得ることができると思います。