バグをより速く解決する方法はありますか？私はちょうど上司から警告を受けました[終了]

上司から、月曜日にパフォーマンスに関する否定的なレビューを受けると言われました。彼は、なぜ私がそんなに遅いのか、そしてなぜ私のバグ修正率がそんなに低いのかについて私に話したいと思っています。

私はプログラミングと問題の解決が大好きですが、実際に仕事は本当に難しいと感じています。

私は実際に約10年間プログラマーです。しかし、これは私の最初のマルチスレッディング組み込みLinuxの仕事です-私はここに2年来ましたが、私がまだ苦労していることは誰にとっても明らかです。そして、私は非常に士気を失い、社会から疎外されたと感じているので、仕事を始めたときの多くの火を失いました。

誰も同じような状況に陥ったことはありますか？また、バグ修正率をどのように上げますか？

更新：レビューがありました。私は3か月間の「従業員開発プログラム」（Dunkが言及したタイプの）に参加しました。これを好転させることができるかどうかわからない。しかし、先に進まなければならない場合でも、この経験から多くのことを学びました。

別の更新

最初のレビューから約6週間です。同じ状況に直面している人への私のアドバイスは、批判を受け入れ、あなたの過ちから学ぶのに十分謙虚であることです。そして、愚かに見えることを恐れないために。たくさんの質問をしてください。あなたが学ぼうとしていることを人々に知らせ、理解するまで尋ね続けます。しかし、うまくいかないように準備してください。私はコードのポートフォリオを構築しています...そしてそれをベストショットにします。

さらに別の更新

将来の雇用者に私のstackoverflowプロファイルを参照することができないのではないかと心配しているので、これをここに置くのをためらっています...しかし、とにかく、この質問を読んでいる人にとって興味があるかもしれませんが、実際には数週間前の仕事。私は必要なすべてのスキルを磨く最中です-ここで与えられたアドバイスから多くを取りました。

多くの回答が上司の方法/戦術/メトリックスなどに疑問を投げかけています。しかし、それは重要なことです。たぶんあなたは遅いです。開発者のすべての部屋には、他の部屋よりも遅いONEが必要ですよね？（それは単なる直線のセット理論です。）それがあなただと仮定しましょう。答えは、なぜ遅いのですか？（明らかに、それはあなたが速くなる方法のあなたの述べられた質問を解決することができる前に答えなければならない質問です。）

あらゆる種類の理由がある可能性がありますが、考慮すべきいくつかの可能な説明を以下に示します。

1. あなたは彼らより知性が劣ります。可能ですよね？（研究は、私たち全員があまり人気がなく、興味がなく、（それに従う）友人よりも知性が低いことを示しています。）繰り返しますが、あなたの場合、これはまずないと思います。一目あなたのStackOverflowのプロファイルを使用すると、トピックの広い範囲で、インテリジェントな質問を尋ねるの歴史を持っていることを示しています。だから、あなたは明らかに思想家であり、おそらくそれで良い人です。

2. 薄く広がっています。あなたの同じSOプロファイルは、あなたの質問が過去2年間の非常に幅広い技術を網羅していることを示しています（グラフィック、ウェブ、Python、C ++、C、Linux、組み込み、スレッド、ソケットなど）。個人的に、私は多くの異なるストリームを掘り下げたい（または望んでいる）状況に置かれたとき、私は自分が本当に速く（またはむしろ、本当に遅い）泳いでいることに気付きます。おそらくここで本当に必要なのはFOCUSです。そして多分健康的な優先順位付け。とにかく重要度の低いポットをバックバーナーに委ねて、メインディッシュの熱を上げることができますか？

3. あなたは楽しんでいない。火が消えると、蒸気エンジンは減速する運命にあります。あなたは自分の士気が最近深刻な打撃を受けたことを投稿で認めました。残念ながら、あなたは自己強化負の倍音の吸う渦に飲み込まれました- 橋を破壊することができる力。それはあまりにも馴染みのあるスパイラルです：難しいタスク->ストレス->締め切りに間に合わない->より多くのストレス->不十分な対処メカニズム->より多くのストレス->先延ばし->より多くの締め切りに間に合わない->批判/ゴシップ（現実または想像）- >さらにストレス。写真が撮れます。これが有用な場所につながることはめったにありません。ホワイトウォーターラフティングで私の日々の教訓を学びましょう：クラス4の急流の裏側の循環流によって水中に吸い込まれた場合、ライフジャケットは水面に浮かぶ。最善の戦略は、（非直感的であるが）を見つけることです下の川のを、と出て行く激浪の。だからあなたに私のアドバイスは次のとおりです。いくつかの地面、男、（友人、教会、健康的な新しい習慣など）を見つけて、渦から自分自身を歩き回るのにそれを利用してください。

4. あなたはあなたのゾーンにいません。マイケル・ジョーダンはかなり不自由な野球選手を作りました。（OK、彼はまだ私よりも優れていましたが、間違いなくマイナーリーグです。）「マルチスレッド組み込みLinux」はあなたの仕事ではないかもしれません。しかし、ソフトウェア開発は非常に広い分野です（ご存じのとおり、上記の＃2を参照）。あなたの会社は別のニッチを見つけるのに十分な広さですか？私の最後の仕事では、組み込みSW開発者として雇われました。（私はその領域での経験がありませんでしたが、私は彼らに「速い学習者」だと言いました。）私はすぐに石のように沈みました。しかし、私は懸命に働き続け、自分がやった問題を探し続けました彼らのために解決する方法を知っています。判明したように、私は次第に輝かしい新しい責任に移行することができ、最終的にはかなりの称賛を受けました。そのため、自分自身のブランドを変更する必要があるかもしれません。

重要なのは、遅い場合は理由があるということです。しかし、ちょっと -あなたはソフトウェアエンジニアです、おい！自分でデバッグしてください！

あなたの上司は正しいかもしれません：あなたは「不採算」であるかもしれません（それについてはあと1分で）。しかし、責任があるのはあなたの能力レベルだけではありません。あなたのコントロールの外の力があなたのストレスを引き起こしており、それがあなたのパフォーマンスにマイナスの影響を与えていることを示唆することは手が届かないと思います。

あなたの上司が今これを持ち出しているかもしれないいくつかの理由を見てみましょう。

文化と政治

上司が懸念を表明することを要求する、あなたの制御を超えた力が存在するかもしれません。あなたが働いているシステムを理解することは重要です。あなたの仕事は、上司の見栄えを良くすることです。それを行う唯一の方法は、彼/彼女が下にある圧力を理解することです。

能力

あなたが彼が公然と述べたように、能力が標準に達していない可能性があります。この状況で私がすることは次のとおりです。

取得特定のフィードバックを、彼はパフォーマンスを測定する方法に上司から。X人と同じくらい多くのバグを閉じていませんか？解決すべき一連のバグはありますか？あなたが一人で働いているなら、あなたはあなたのパフォーマンスを測定する人々が公正に測定していることを確認する必要があります。

パフォーマンスが遅く、実際のギャップに基づいている場合は、そのギャップを特定し、上司と一緒に詳細な計画を立てて、それを埋めます。

このレビューは、あなたが幸せではないという事実を持ち出す良い機会でもあります。あなたがこの仕事を愛していないことを確認したのは良いことです。しかし、理由を理解してください。あなたの仕事のどの部分が好きですか？この仕事はあなたのためではないかもしれません...

一部の作業環境は機能しません。私は、誰も生き残れない環境を見てきました（最初にいた人たちのために保存してください）。

あなたは本当にあなたがそれらを満たすために提供される期待とリソースに関して自分自身に正直である必要があります。問題はあなたではないかもしれません。

あなたはあなたと同じような仕事をしている人がいると言いますが、私は難しいとは思いませんが、あなたの2歳以上で5年以上の経験があります。この点であなたを完全に上回っているロックスターですか、それとも彼らはあなたに似ていますか？おそらく、彼らはシステムがより簡単だったときにシステムを知るようになっただけでしょう...この作業の前に8年間のプログラミング経験があるとおっしゃいました。どうしましたか？あなたがうまくやったなら、それはあなたに何かを伝えるはずです。

私に衝撃を与えたのは、あなたがやってくるすべてのバグに関して、あなたが自分を暗闇の中にいると説明することについてのビットです。コードベースが広大で未知であるため、期待が妥当ではない可能性があります。

あなたがそれを成し遂げたということは、あなたが正しいことをして、あなたのために何かをしているということです。

一番下の行は、あなたがあなた自身とあなたがやっていることについて良い気分にする必要があると思います。そして、それが先へ進むことを意味するのであれば、それもそうです。

仕事があなたの人生を台無しにするよりも先に進む方が良い。

まず、注：この回答は、従業員を退職せずに解雇することが違法である特定の地域にのみ適用される場合があります。とはいえ...

これは建設的な解雇のケースであり、違法です。

戦術は、従業員が仕事を辞めるまで士気を低下させ、自尊心を低下させることです。これは、会社が退職金を支払う必要がないことでお金を節約したり、従業員に立ち向かったり解雇したりする問題を解決する方法です。

彼は、なぜ私がそんなに遅いのか、そしてなぜ私のバグ修正率がそんなに低いのかについて私に話したいと思っています。

この欠点は非常にあいまいです。当事者のどちらの側も、他方が間違っていると主張することは不可能です。1つのバグを修正するのに1か月かかりました。だから何！これにより、1か月が必要であるという主張を裏付けるために事実を提示する必要があるため、防御的な立場に置かれます。現在のスキル、経験、知識を要因として考えてください。雇用主として、従業員の時間と労力を管理するのは雇用主の仕事です。雇用主は、バグを修正することに関連するリスクに関与している人でなければなりません。従業員ではありません。彼は常にバグを他の誰かに割り当てるという選択肢がありました。

あなたが請負業者であり、バグの修正を担当する契約書に記載されている場合、それはまったく別の話です。

雇用主があなたが長すぎると不平を言うのは間違っていますか？絶対にそうではありませんが、彼はあなたにその責任を負わせることはできません。彼はあなたに「あなたのスキルを必要とするバグはもうありません、そしてあなたは休暇に置かれます」と言うことができますが、彼らはあなたが修正できる新しい問題が出た瞬間をあなたに告げなければなりません。それ以外の場合は、切断して終了する必要があります。彼ができないことは、あなたにあなたが扱えない仕事を与え、それについて不平を言うことです。これは違法だと思います。

私はプログラミングと問題の解決が大好きですが、実際に仕事は本当に難しいと感じています。

あなたが一生懸命仕事をすることと、あなたの雇用主があなたに仕事を与えることとの間には大きな違いがあります。あなたがあなたに割り当てられた仕事があなたが会社でキャリアを積むのを思いとどまらせるために行われたと感じたら、これは違法かもしれません。

私は実際に約10年間プログラマーです。しかし、これは私の最初のマルチスレッディング組み込みLinuxの仕事です-私はここに2年来ましたが、私がまだ苦労していることは誰にとっても明らかです。

これが、建設的な解雇の最中にいることに気付いた理由です。彼らはあなたに満足していないので、あなたが去るまで彼らはあなたにがらくたを積みます。

そして、私は非常に士気を失い、社会から疎外されたと感じているので、仕事を始めたときの多くの火を失いました。

雇用主は、安全で前向きな職場環境を提供する責任があります。より多くの情報（おそらく個人）がなければ、ここで実際に何が起こっているのかを部外者が言うことは困難です。雇用弁護士に無料相談を依頼してください。彼らはあなたがプレイされているかどうかを伝えることができます。

参照資料

私は弁護士ではありませんが、月曜日にレビューを入力する前に読む価値がある建設的な解雇のトピックを議論するいくつかの文書をグーグルでやりました。ここでの主なポイントは、給料の削減、屈辱、会社でのキャリアの突然の変化に注意することです。

関連する事実は次のことに注意してください：

• 困難な労働条件の中で従業員を適切にサポートできない
• 従業員への過度の懲戒従業員の職場の変更を短期間で課す
• 給与または賃金の削減の賦課

法的Q＆A：建設的な解雇

建設的な解雇を主張する理由

ウィキペディア

建設的な解雇の要素

おそらく、あなたはプロジェクトの元のプログラマの一人と比較されているでしょう。私が取り組んでいるプロジェクトの元の開発者として、バグを修正する際に非常に大きな利点があることを知っています。ドキュメントがないためだとは思いませんが、私の脳はすべてのコードを知っているので、潜在的な問題に直観的に跳躍できるのです。

あなたがそれと比較されているなら、あなたはただ測定するつもりはありません。プロジェクトの速度を上げるには常に時間がかかり、すべての潜在的なインタラクションポイントがどこにあるのかわかりません。

他のプログラマーが問題を解決するために使用しているツールやトリックを見つけられないというコメントを読みました。おそらく次のバグ修正のために、ペアプログラミングを試す必要があります。これは非常に便利です。順番にキーボードを運転してください。たくさん話してください。

ノートブックまたはホワイトボードを使用して、関数パス、スレッド、およびロックの有効期間をグラフ化し、さまざまな動作を観察する場所と新しいプローブを挿入できる場所をマークできます。

このような低レベルのスレッドの問題を解決することは本当に難しい場合があり、私はあなたに多くの同情を持っています。2行の問題を見つける前に、数ギガバイトのログファイルを分析する必要がありました。そして、あなたは何を知っていますか？数年前からそれを見つめていましたが、1年前にインターンをしていたジュニアエンジニアに助けを求めると、彼は新しいアプローチを思いつき、1時間で問題を見つけました。そのため、バグに時間をかけた後、バグに目を向けてください。それは多くを助けることができます！

この業界で最も一般的な管理機能障害の1つは、デバッグが本質的に難しいことを理解していないことです。私は経験のほぼ20年を持っていると私は今でも定期的に50のうち、プログラムのクラッシュを一度作る1行の間違いを見つける完全な一週間を過ごすことがあります。そして、もし私のマネージャーがこれらのことを理解していないと、1行のコードを変更するのに1週間かかるので、私は面倒です。

あなたはそれについて何ができますか？

• デバッグしながらメモを取ります。常にエディターウィンドウを開いて、意識の流れを書き留めてください。それはあなた以外の誰にとっても意味をなさない。これはデバッグの高速化に役立つことがわかるかもしれませんが、それはまた、Nethackを1週間プレイしていないことを示すための具体的なポイントがあることを意味します。

• メモをすべての同僚と比較します。通常、バグを修正するのにどれくらいかかりますか？バグは修正されたままですか？彼らはどれくらいの頻度で一つの小さなことを変えて、カスケードの結果の山の下に埋もれているのに気づきますか？これらの質問に対する回答は、他の部門と比べて本当に苦労しているかどうかのある程度の感覚を与えてくれます。

• QA担当者およびカスタマーサポート担当者と友達になります。それらは、バグがどれほど重要であるかを最もよく知っているものです。多くの場合、これはバグの難易度とほとんどまたはまったく相関関係がないため、システムを少しゲームして、重要度が高く、難易度の低いすべてのバグを割り当てようとすることができます。（これは実際に不正行為ではありません。よく組織されたチームは常にそれらのバグを最初に追跡します。）

• 上司が2年間のランニングでパフォーマンスに関する適切なフィードバックを提供していない場合は、このパフォーマンスレビューで最初に立ち上げてから、上司に上司に提起するために回避策を与えたときに問題になります。礼儀正しく、特にあなたがどれほど怒っているかを見せないでください。しかし、書面で特定の批判を受けてください。

プログラミングや問題解決が好きな人もいるかもしれませんが、学んだことを他の分野にどれだけうまく応用できるのかという疑問があるかもしれません。修正した最後の数十個のバグのいずれかが、修正に役立つものが別のものに役立つほど十分に類似していますか？これは、あなたがしたことと、それを成し遂げるのにどれくらい時間がかかったかを振り返る部分です。考えてみてください。

第二に、私はあなたがどのようにあなたの仕事をしているのかを見ます。定期的に中断されているので、バグAを修正しようとすると、バグBとCが優先度が高いと言われますか？上司が知りたいことの一部である可能性があるため、ここであなたの仕事のやり方にどのような変化が役立つかを慎重に検討してください。

私は、仕事の一部を成し遂げるのにどれだけ時間がかかったかを彼らが嫌いだと言う職場がいくつかありました。もちろん、これらの場所は、1つのことを完了させると、5つの新しいものが膝に落ちてしまうため、簡単に圧倒されてしまう場所でした。私はそこで働いていないかもしれませんが、いくつかのことに注意を向ける良い解決策がなかったので、一度に1,000のことをマスターしようとしているような気がしません。完了すべきいくつかの重要な事柄と私の仕事がどのように判断されるかを知ることができれば、1マイルの「to-do」リストを持っている場合よりもはるかに良く、誰も気にしないようですそれの一部が完了しました。したがって、私はここで何かを変えるように頼むことに注意しますが、組織にはこれに文化的な要素がある可能性があります。

仕事を始めて2年が経つと、あなた（あなた、上司、同僚）が自分の立場を明確に理解できるはずです。すなわち、あなたはあなたが年に一度だけ悪いことをしていることを決して発見すべきではありません。理想的な作業環境が継続的なフィードバックを提供します。

とにかく、マルチスレッドコードのデバッグ方法については、これが自分のコードであるか他の誰かのものであるかについては言及していません。並行性を処理できるいくつかの新しいデバッガーと静的アナライザーがあります。しかし、実際には、何を探すべきかがわかるので、パターンを知ることが最善策です。

クリティカルセクション、競合状態、およびデッドロックがどのように機能するかを理解していれば、予期しないものを見つけるのに適した立場になります。条件変数のない2つのスレッド間で「通信」が見られる場合、リソースが特定の順序なしでミューテックスされている場合、またはローカル変数がstatic明確な理由なく宣言されている場合、潜在的なバグがあります。そのため、ドメインのベストプラクティスを学習すれば、異常が発生した場合に判断できるようになります。

必要がない限り、一人で苦労しないでください。同僚を募集します。バグの捜索を手伝ってもらいましょう。彼らの思考プロセスとツールについて尋ねます。おそらく、改善計画の一環として、レビューでこれを言及してください。あなたの周りの誰もがこのシステムでうまくやっているなら、彼らは何か具体的なことを知っているのでしょうか？

上司から、月曜日にパフォーマンスに関する否定的なレビューを受けると言われました。彼は、なぜ私がそんなに遅いのか、そしてなぜ私のバグ修正率がそんなに低いのかについて私に話したいと思っています。

正常に機能しない会社では、この注文では何も起こらないことに注意してください。あなたの上司があなたのパフォーマンスを心配している場合、彼は短期目標を設定し、問題がどこにあるかを見つけるためにあなたの結果について話す必要があります。

その代わりに、彼はあなたに否定的なレビューを与え、それから理由を見つけようと決めました。彼は問題に自分自身を関与させたくなく、結果を表にしたいだけです。

バグの迅速な解決を目指してはいけません。自分の能力を評価し、同僚がどのように働いているか、彼らが知っていることをどのように知っているかを確認し、これが理想的な会社ではないことに注意してください。

実用的なヒントについては、コードスニペットと独自のメディアウィキを使用してメモを取ります。次に読む本、学習を続ける方向を常に念頭に置いています。学習は、より良い仕事と幸せな生活への道です。

まず、自信を高める：

なぜ苦しむのですか？バグ修正率に関係なく、Linuxに何でも埋め込めるという理由だけで、彼らがあなたを「神」だと思う仕事を簡単に見つけることができます。

とにかく、バグの追跡に時間制限を設定することは不可能です。バグハンティングは間違いなくスキルであり、その効率は非常に価値があります。

あなたは他の人が知っている基本的なトリックを逃しているかもしれません。

たとえば、あなたと私がLinuxミドルウェアで作業していて、メモリ破損の問題とデータの競合状態を見つけるためにValgrindを使用しているのに、gdbとprintfだけに依存している場合は、おそらくあなたは私より賢い。

また、並行性についてどのように理解していますか？10年間開発してきたが、その経験のほとんどがマルチスレッドコードではなかった場合、問題になる可能性があります。

マルチスレッドの詳細を学習する必要があります。APIの使用方法を知っているだけでなく、実際に深いレベルで「取得」する必要があります。マルチスレッドプログラミングを行っている場合は、1マイル離れたところからコードベースを見て、競合状態、デッドロック、優先順位の逆転、飢vのシナリオを見つけることができる開発者でなければなりません...

最近、「レガシーコードを使用して効果的に作業する」という本を読みました。コードベースの問題に取り組む際に、自信が大幅に高まりました。

使用しているコードが完璧ではない場合は、この本が役立つと思います。バグを修正するために多くの時間を費やしているので、それを理解するために最初に周囲のコードをリファクタリングする必要があり、コードを理解したら、コードをテスト可能にし、追跡し、問題を修正するのは、それほど苦労しません。（時々、それを理解するためだけにコードを書き直しますが、新しいバグを導入するリスクを減らすために変更を元に戻します。それからバグ修正を挿入します。そのテクニックは本のトリックに基づいています。）

私の提案はあなたの問題の一部、そしてある程度間接的にしか対処していないと思いますが、レガシーコードを扱うことはどんな開発者にとっても避けられないことなので、この本は何を読んでも価値があります。

バグ修正の速度とチームのバグ修正の平均速度を上司に尋ねてください。もっと重要なのは、彼に尋ねるどのように測定されたバグの修正の速度が ...

これは一種のメトリックであり、実際にはメトリックではありません。もしそうなら、LOCよりもさらに信頼性が低くなります（ただし、異なるものを測定します）。そして、適切な測定がなければ、何かを非難する理由はありません。

雇用主および/または顧客ではなく、彼らのために働いていることを認識してください。インタビューでそれを言及することをheしないでください、ただ記録を最初からまっすぐに設定するだけです。

あなたはあなたの中小企業、すなわちあなた自身に多くの投資をしている専門家です。

連盟があなたを毎日ラックから追い出している間、あなたは喜んで働きます。

その推進力がしばらくの間存在しない場合は、次に進みます。

あなたは、あなたの興味の継続/スキルの更新/割り当てに挑戦したり、仕事をするのに面白くなかったりしない、熱心な雇用者に時間とエネルギーを浪費しています。それが経営陣の仕事です。それ以外は、純粋なオーバーヘッドです.....

それが鍵であるため、情熱を持ち続けてください。

私は助けを求めることを恐れていたので、私は同様の状況にありました。このコメントであなたが言ったことから判断すると...

「しかし、イライラしているのは、1年半ぶりに見つけた特定のツール/ヒント/トリックがあることです。チームからチームへとシフトしてきました（私はパフォーマンスが低かったと思います）。これらの「隠れた」ツールはたびたびあります。」

...あなたが私と同じ問題を抱えている可能性があります。デバッグは、そもそもそれほどデバッグを必要としないコードを書くのと同じくらい手間のかかる作業です。デバッグ問題を通して他の開発者が動作するのを見るのは非常に教育的です。何かを整理するのに苦労しているとき、彼らに助けを求めてください。特に、これまでにない地面をカバーしている場合。そして、何も完了していないので、パニックに陥る前に理想的に実行してください。

そうは言っても、経営陣が何か間違ったことをしているというコメントには同意します。誰かが何かに苦労している場合、否定的なレビューの楽しみが始まる前に彼らはそれで助けを得る必要があります。地獄、チームの誰かが苦労して助けを得られない場合、そのチームのすべてのメンバーが何か間違ったことをしていると言います（ただし、バグ修正率を過度に注意深く見ている人々の直接の結果かもしれません）。

OPに欠けているのは、バグを解決するために追跡されている反復可能なプロセスまたは方法に関する言及です。

そのため、最初に、従うプロセスを文書化します。プロセスの各ステップが何を達成するのかを文書化してください。

次のようなタスクを持つプロセスを概説できます。

1. 報告されている問題を正確に理解してください。
2. 問題を再現してください。
3. 問題を小さな断片に分解し始めます
4. 問題の考えられる原因を考えてください。
5. それらの仮説をテストする

バグが長い間存在していたのか、最近の変更で導入されたのかを知ることは役立ちます。最近の変更でバグが導入され、コードレビューが行われたり、人々が作成しているコードを読むだけで役立つ場合があります。

「バグを解決しようとするときにテストする仮説を考えるのが難しい」など、問題を明確に定義できれば、より集中的なアドバイスを得ることができると思います。