私は最近、中規模企業のWeb開発者としてのキャリアを始めました。開始するとすぐに、既存のアプリケーションを拡張するタスクを取得しました（不適切なコーディング、長年にわたって複数のプログラマーによって開発され、同じタスクを異なる方法で処理し、構造はゼロです）。

そのため、要求された機能を使用してこのアプリケーションを正常に拡張した後、アプリケーションを完全に保守するタスクをくれました。これはもちろん問題ではありませんでした。しかし、その後、既存のコードを改善することは許されず、バグが報告された場合にのみバグ修正に集中することができないと聞いた。

その時から、上記と同じようにさらに3つのプロジェクトがあり、それを今も維持する必要があります。そして、アプリケーションをゼロから作成することを許可された4つのプロジェクトがあり、それらも維持する必要があります。

現時点では、私が維持しなければならない各アプリケーションのユーザー（読み取りマネージャー）の毎日のメールから少しばかり夢中になり始めています。彼らは、私がこれらのメールを直接処理すると同時に、他の2つの新しいプロジェクトに取り組んでくれることを期待しています（そして、その後にさらに5つのプロジェクトが並んでいます）。残念なことに、自分でコーディングしたものに関するバグレポートをまだ受け取っていません。そのため、たまに180度のさまざまな変更要求を受け取りました。

とにかく、これは正常ですか？私の意見では、私は開発者のチーム全体と同等の仕事をしています。

最初は物事が違うと思っていたとき、私はばかでしたか？

この投稿は大暴れになったと思いますが、これはすべての開発者にとって同じではないことを教えてください。

PS私の給料は、スーパーのレジ係の給料より低くないとしても、ほぼ同じです。

インターンシップ中に、バグ修正に多くの時間を費やしたことがわかりました。あなたは、エントリーレベルの従業員として、あなたが最もセクシーな仕事を得ることはないだろう、あなたは他の誰も望んでいないうんざりする仕事を得ることになることを認識しなければなりません。それは残念ですが、それはすべての仕事でそれがどのようにあるかです。

さらに、会社にとっては、きれいなコードを持つよりも、機能するコードを持っていることが重要であることを認識しなければなりません。会社の観点からすると、既存の構造を変更すると、すでに行われていることをやり直し、さらに多くのエラーを強力に導入することに無駄な費用がかかります。通常、これらのタイプの会社はコンピューター/ソフトウェア会社ではないため、これらの大規模なオーバーホールを行う必要がある場合があることを知るための技術的背景を持つ十分に高いマネージャーはいません。とはいえ、あなたの会社が技術的に有能な人々によって運営されており、彼らが良いコードの価値を理解しているなら、あなたはもっと余裕を得るかもしれませんが、時々あなたはあなたの戦いを選ぶ必要があります）。

そうは言っても、ソフトウェアにマークを残したいので、より意味のある作業をしたいのは不合理ではありません。また、非常に多くの異なるマネージャーからの要求に対応しながら、一度に非常に多くのプロジェクトに対処する必要があることも残念です。

プログラマーとして、自分のコードをゼロから作成するよりも、他の人のコードを保守および変更するのに多くの時間を費やすことは現実です。これがあなたにとって問題であれば、おそらくあなたは趣味として開発に固執し、別のキャリアを追求する必要があります。コードのメンテナンスに問題はないが、効果的に使用されていない、または圧倒されていると感じている場合は、マネージャーと話し合う必要があります。あなたの問題がそれよりも深刻な場合、またはマネージャーがスキルセットを効果的に管理する方法を知らないと感じている場合は、別の会社で職を見つけることを検討することをお勧めします。あなたの述べた低給を考えると、これはおそらくあなたの最善の行動方針です。

管理には、ワークロードの管理とタスクの優先順位付けに問題があるようです。あなたはマネージャーに話しかけ、あなたが過負荷になっていて、すぐに達成したいリクエストで誰もがあなたを攻撃し続けたら効果的な仕事ができないことを彼らに理解させるべきです。

これにより、あるタスクから別のプロジェクトにジャンプして、ギアを切り替えるのに多くの時間を費やすことになります。効果的なソフトウェア開発作業を行うには、タスクに没頭し、完全にタスクに集中できる必要があります。中断が多いほど、コンテキストの切り替えにより多くの時間が浪費されます。調査によれば、私たちの心が最も効率的に機能するフローの状態に浸り、到達するのに約15分かかります。15分ごとに中断が発生した場合、フローすることはありません。これは、あなたと会社の両方にとって大きな無駄です。

ですから、より賢明な作業モードをマネージャーと交渉しようとするべきです。これには、着信要求の優先順位付けと、ある程度の事前計画が含まれます。すべてのユーザーリクエストは、優先度順に並べられたリストで管理する必要があります。そして、優先順位はリクエスターによって決定されるべきではありません（当然、誰もが自分のリクエストは地球上で最も重要だと考えているため）製品の所有者）。

理想的には、すべての受信リクエストはJIRAやMantisなどの課題追跡に入力する必要があります。または、少なくともあなたではなく、製品の所有者に郵送してください。そして、「なぜ私のリクエストはまだ準備ができていないのですか！」ということで、ユーザーからの苦情もすべて処理して、開発作業に集中できるようにする必要があります。これが達成できない場合は、少なくとも着信要求を調べて処理する時間のいくつかの時間をネゴシエートし、開発のためだけに時間の途切れない部分を確保する必要があります。

これが可能であれば、次のステップはある程度前もって計画することです。つまり、最優先のリクエストを実装するのに必要な時間を見積もり、スプリントに時間をスケジュールします。スプリントはそれぞれ1週間以上になることがあり、次のスプリントに十分なタスクを割り当てて時間をカバーします。

おそらく緊急のリクエストを受信するために時間の一部を保持したいでしょうが、残りは前もって計画することができます。また、さまざまなプロジェクトの作業を別々の「ストリーク」に整理することもできます。つまり、月曜日にプロジェクトA、火曜日〜水曜日にプロジェクトB、木曜日の朝にプロジェクトC、午後にプロジェクトDに取り組みます。コンテキストの切り替えを減らします。

これにより、今後1週間または数週間で何をすべきかを大まかに把握できます。さらに、これはクライアントにもロードマップを提供します。クライアントは、どのリクエストを実装するかをいつでも確認できます。ここであなたのマネージャーに「アジャイル」という言葉に言及したいかもしれません。これは基本的にアジャイル開発ですが、一部の人々は実際にそれが何であるか知らずにアジャイルに反対しています:-)

現在の地位が会社によって低く評価されているように見えても、維持するプロジェクトが多いほど、交渉力が高まります。

これらのすべてのプロジェクトを維持するために新しい雇用を見つけてトレーニングするには、会社にとってかなりの時間（=お金）がかかります。そして、あなたのコードはこれらのアプリケーションのレガシー部分よりもはるかに優れていることを正しく指摘することができます。したがって、同じ金額で同様の機能の候補を簡単に見つけることができるということはありません。言うまでもなく、彼らが労働条件を改善しなければ、彼らは次の人をあなたと同じくらい早く飽きさせてやめさせます... あなたを維持することが彼ら自身の最大の利益であることを彼らに理解させてください、そしてあなたがいる場所であなたを幸せに保つために :-)これはあなたに上記の条件を交渉し、そして/または、昇給を要求するいくらかの力を与えるかもしれません。

あなたが持っている交渉力の大きさ-それは大きな問題です。あなたの経営陣は、これらのアイデアに対してオープンであるかもしれないし、そうでないかもしれません。しかし、カードをうまくプレイすれば、チャンスがあります。そして、彼らが拒否した場合...あなたは常により良い職場を探すことができます。この状況はすべてのスターターで同じではありませんが、（残念ながら）あなたの経験はかなり典型的です。しかし、本当に良い職場がそこにあります。職場の質は地理的位置と大まかに相関しているだけですが、私の考えでは、北ヨーロッパでは平均よりも高い可能性があります。したがって、現在の状態を著しく改善できない場合は、すぐに探し始めて、完全にうんざりして燃え尽きる前に始める必要があります。

まだ仕事をしている間に仕事を探す方が非常に良いので、すぐにお金が必要になるからといって最初のオファーを受け入れる必要はありません。最終的にあなたはより良い場所を見つけるでしょう:-)

PS私の給料は、スーパーのレジ係の給料よりも低くないとしても、ほぼ同じです。

ねえ、私はそれを読むまで交渉方法について何かを書きたかった。今、私が言えるのは去るだけです！それが学位を持つ開発者が通常稼ぐものの半分であると仮定します。そして、物事が改善され、すぐに10％増加すると仮定すると、そこに到達するのにどれくらい時間がかかるかを自分で理解することができます。また、仕事で何も学んでおらず、優秀なエンジニアに囲まれていないように見えるため、時間の無駄です。

私も同じような状況にありました。そして、そのトラックにとどまると、それは決して終わりません。経営者はあなたにそれをシャベルで続けます。なぜなら...彼らができるからです。

このトピックについては、いくつかの追加の考えがあります。

1. 好きなことをしてください。あなたがそれを愛していないなら、あなたが愛するかもしれないものが何であるかを見つける試みをする準備をしてください。

2. コミュニケーション。非現実的な期待に応えることができないことを明確に伝えてください。私の似たような経験で、建築家（最もシャベルを作った人）は、「他人の期待を管理する必要がある」と言った。

3. 燃え尽き。燃え尽きを経験していない場合、運命を誘惑しないでください。それはあなたの人生と魂をあなたの心から吸い込みます。あなたの最善の努力にもかかわらず、あなたの仕事の目的は灰色で退屈で無意味になります。どうしても燃え尽きないようにする必要があるため、このアドバイスを伝えます。

4. トレーニング。こちらがシルバーの裏地です。あなたのトレーニングと経験は、いらいらさせられ、おそらくは低賃金ですが、実際、あなたのキャリアにとって非常に貴重です。これは、できるだけ多くの学習を吸収し、避けられないガラスの天井を遅らせることができるため、これを実現するための節約の恵みです。

あなたが成長している才能とスキルに焦点を当ててください...これらはあなたのキャリアの次の機会を通してあなたを運びます。

ここで複数の問題に対処しています...明白なことから始めましょう...

これは正常ですか？

地獄いや しかし...それは一般的ですか？残念ながらそうです。

バグ修正フラストレーションについて

それはあなたが対処しなければならない混乱の残りとそれらがあなたをオーバーロードする複数のプロジェクトを言い訳にしませんが、開発者としてあなたをイライラさせながら、「バグ修正」アプローチのみであるという簡単なメモを作りたいです、会社とその経営者にとって完全に賢明なアプローチとなります。

より多くのバグとコストのためのSurface

より多くのコードに触れるほど、バグを改善することを意図している場合でも、バグを導入する可能性が高くなります。つまり、開発時間、テスト時間、コストが長くなります。そして、中程度から重度の欠陥を含むサービスリリースに移行する場合、それは彼らにとって大きな混乱です。

ログのノイズ/霧

SCMの観点からは、バグ修正に関連する変更を明確に表示したいので、サービスリリースのブランチから直接作業する場合にも少し意味があります。実際に1行のコード変更を必要とするバグ修正を取り巻く数千の変更を伴う15のコミットがある場合、それは少し面倒です。

したがって、新規採用者として、ソフトウェアのリファクタリングおよび/または拡張を控えるように依頼することはさらに賢明であり、バグ修正で可能な限り「外科的」であるという私の感覚ではまったく問題ありません。頭痛の種を寄せ付けません。

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

さて、それはコードの正気と関係する人々の心の正気の両方を達成する方法があるという意味ではありません。ジュニアなので、誰かに変更、特にバグ修正をレビューしてもらい、サービスリリースビルドを作成する前に承認されていることを確認する必要があります。それは根本的な変更を防止または制限し、より安全になります。

地獄からのプロジェクト

Crapコード、プログラマの群れ、複製、Crapアーキテクチャ

繰り返しますが、ここでは悪魔の擁護者ですが、最初のリクエストには重要でないビットがいくつか含まれていることを示しています。

私のポイントはこれです。この状態ではないコードベースを実際にめったに引き継いだことはありません。そして、私がやった偶然に、彼らは最近、かなり優れたプログラマーによってキックスタートされたプロジェクトまたはプロトタイプを始めました。しかし、それらの驚くほど大多数はがらくたのように見え、これらの恐ろしい数は実際のがらくたでした。優れたプログラマーや優れたプログラマーによって始められたものでさえ、最終的にはがらくた、締め切り、その他の支援になります...

実際の産業用ソフトウェアエンジニアリングへようこそ！

そして、あなたは楽しいものを知っていますか？これは、Web開発の世界ではしばしばひどく悪くなります。楽しい！:)

手と時間が足りないプロジェクトとリクエストが多すぎる

問題はおそらくここにあります：

• あなたの管理（おそらく無意識のうちに）あなたを虐待し、
• 同僚が（おそらく無意識に）あなたを虐待している、
• あなたの（おそらく知らないうちに）あなたのお尻をカバーせず、あなたの戦いを十分に戦っていません。

マネージャーは、管理するプロジェクトが多すぎることに注意する必要があります。そうでない場合は、できるだけ早く確認してください。また、公園内のすべてがピックニックではないこと、プレッシャーを感じていること、および停止する必要があることを確認してください。

周りを見て、同僚があなたのタスクやプロジェクトを直接（「Xがそれを大事にできる」と言って）または間接的に（「私は適任者ではない」と言って）偏向させないようにしてください。これ、他の誰かを見つける」->最終的にあなたになります）。

ここでの個人的な逸話：私は数年前にインターンシップをしましたが、ちょうど最後の日に、評価を得たとき、上司は私の仕事全体に非常に満足しているにもかかわらず、マネージャーの一人が私に彼らは私がそれらを拾うと期待していたときに別のインターンでいくつかの「あまり楽しくないタスク」を降ろしていた。私は彼らが落胆したと感じて失望し、私の意図が正反対だったとき、私は怠けているように見えるという考えで：私はより困難な仕事をつかみ、他の若いインターンがより少ない髪を扱うようにしました-プルの問題。私が彼の立場にいれば、挑戦の欠如に飽きて、おそらく彼のやり方を感じていたとは少しも気づきませんでした。重要なのは、非常に明確な3つのことについてだれも誤った仮定を立てないようにするために通信する必要があるということです。

• できること、
• あなたがしたいこと、
• そして、あなたがやろうとしていること。

そのため、このようにするのは部分的にあなたの責任でもあります。しかし、それは正常なことであり、誰もが学ぶ必要のある教訓です。N - Oの 2文字で保持されます。

あなたは通常、より長いが、それほど多くは請求されない答えの接頭辞としてそれを使用します：いいえ、私はこれをすることはできません。いいえ、これを行う方法がわかりません。いいえ、私がこれにふさわしい人物であるかどうかはわかりません。いいえ、私はそれをやったことがありません。

最初は、「はい、最終的にはやる」と言うだけで、たぶん余分な時間を費やすことで物事を積み重ねて成し遂げられると感じるのは非常に簡単です。それはすべて間違っています。あなたの時間は、あなたのスキルの後、あなたにとって、そしてあなたの会社にとって、あなたにとって最も価値のある資産であることを理解する必要があります。誤用された場合、プロジェクト、期限、予算に影響します。それと同じくらい簡単です。

また、報告する人が多すぎるのではないかと少し心配に見えます。複数の顧客に対応してもらい、複数のプロジェクト所有者や主要な利害関係者と連絡を取る必要があります。ただし、全体として、特に新入社員の場合は、ほとんどの場合、少数のマネージャーのみに報告する必要があります（ほとんどの場合、直属のマネージャーのみ、場合によってはリードまたはシニア開発者のみ）。どうやってこのようになったのですか？知りません。それはあなたの会社の組織的な問題かもしれませんし、あなたが好意を持ち、それから直接連絡を受け、「ノー」と言わなかった結果かもしれません。または、私が知っているすべてのために、タスクをディスパッチする際の問題としてあなたの直接のマネージャーであるかもしれません（私は本当に推測していますが、パターンは認識可能でよく知られています）。

直ぐに直属のマネージャーと話をするか、他のマネージャーは少々強引かもしれないことを説明するか、（多分あまり気にしない）あまりにも多くの人からたくさんのものが山積みになっていることを説明し、どの入力に優先順位を付けるかを知るために、彼の入力（および場合によってはその入力も）が必要です。

180度の変更リクエスト

これらは別の大きな問題です。それらはおそらくあなたのせいではありませんが、あなたは彼らがそれに対処するのを助けることができます。

「180段階の変更要求」は、美しく正確にそれらを呼び出すことから、要件が出てから曖昧であり、時間の経過とともにそれらを削ってクリアするのに十分な努力をしていないという明確な兆候です。

それは通常、誰かが電話に（またはより良く、彼らの足で）着手し、利害関係者を手でつかんではっきりと言う必要があるときです：「それは私たちがいるところです、あなたが私たちが行きたい場所です正しい方向に向かっていますか？」最初は明確な回答を得られなくてもかまいませんが、時間が経過するほど明確になるはずです。そうでないと、このプロジェクトは起こるのを待っている災害です。

通常、すべての利害関係者を手に入れ、部屋に入れ、訴訟の問題を解決し、段階的にこれらの問題を解決しようとします。しかし、あなたの場合、これはあなたがすでに電話をかけることではないかもしれません。しかし、あなたは彼らが本当にあなたにプロジェクトの責任を与えたと言います。本当にそうなのであれば、責任を持ってそれをしてください。そして、敬遠しないでくださいと言ってから、「私たちはそれを行うことができない」、あるいは「私たちがすることをしないだろう」。プロジェクトの範囲を制限することは本当に重要です。

範囲がない場合、議論の最後に明確な要件はありません。

電子メールの過負荷

人々は、使用する通信媒体に基づいて異なる動作をする傾向があります。個人的には、私はかなり口数が少ない人ですが（主に外国で仕事をしているので、電話で話すことをあまり望まないことになります）、生産性に基づいて優先順位を優先します。

• 対面の人に話し、
• 電話で人々と話している
• IMを介して人と話す、
• メールで人と話す。

電子メールは、追跡、確認の取得、メモの送信に適しています。

問題のあるポイントのスケジューリング、計画、議論については、ほとんど役に立たない。男がドアを開けるまでドアをノックし、メモ帳とドキュメントのコピーを持って座って物事を明確にします。完了したら、メールを送信して確認を求めます。否定的な答えが返されたり、封筒に何か他のものを忍び込ませようとするわずかに隠された試みで戻ってきた場合は、対談者のオフィスを再び包囲してください。

これはソフトウェアエンジニアリングです。多くの場合、キーボードで入力しなくても生産性が向上し、実際に対処する必要があるがらくたを事前に削減できます。

チームの価値ある仕事をする

チームの仕事に相当する仕事をしていますか？多分。

チームの仕事に相当する仕事をしていますか？おそらくない。

私の言いたいことは、あなたのチームはおそらく忙しく働いており、あなたは過労しているということです。そして、それが問題です。現在のプロジェクトのタイムラインから押し出されるべきものや、時間のある人に与えられるべきものでいっぱいになります。

最初は物事が違うと思っていたとき、私はばかでしたか？

番号; パーティーは初めてです。最初の二日酔いや関係のようなものです。あなたはそれを乗り越えます。

この投稿は大暴れになったと思いますが、これはすべての開発者にとって同じではないことを教えてください。

これは混startupとした組織のすべての開発者、つまりスタートアップであれ老舗の巨人であっても同じであり、経験を積んだり、物事を少し動かして規模の右側に生き残るチャンスを与えたりする自信はありません。

PS私の給料は、スーパーのレジ係の給料よりも低くないとしても、ほぼ同じです。

私はくだらないように見える仕事にまともな給料をしました。カウントするのはチェックの数ではなく、コンテキストです。あなたがしていること、あなたの年齢、あなたが住んでいる場所、職場など

そうは言っても、もしあなたがひどく低賃金で、働きすぎで、完全に後輩でないなら、その昇給を頼むか、新しい仕事に就いてください！

それは簡単です：

• 彼らがあなたのしていることを大切にしているなら、彼らは喜んで昇給に同意します。
• そうでない場合、この会社の未来はあまりバラ色に見えません（少なくとも、あなたにとっては重要です）。

昇給を要求するのは良いことです。最初はそう思うように励まされることはありませんが。これは、自分が何をしているかを追跡していることを証明し、機内にとどまることを望んでいる間、他のオプションに目を向けることを示唆します。そして、彼らは一般的に就職の面接や交渉のようなものであるため、彼らを要求するのに慣れることは良いことです：それは練習を必要とするものであり、あなたが彼らに手を差し伸べなければ空から落ちません。一部の企業は、要求されることなく定期的にレイズを配布しますが、それは彼らがあなたを半幸福に保ち、変化する意欲を失わないことを知っているだけで、彼らはあなたの足の下の草を刈りたいと思っているからです（ほとんどの人は感じるでしょう直接オファーされたレイズオファーを上げることに少し不安があります）。

このリクエストの処理方法は、このプロジェクトの範囲外であるため、ここでは詳しく説明しません。ただし、SCMコミットID、修正されたバグと実績の記録を作成し、チームの全体的な努力と比較するレポートも作成することをお勧めします。こちらです：

• 同僚よりもはるかに多くのことを効果的に行ったかどうかを自分で測定できます。
• あなたの要求が正当化されていないと彼らが言うなら、あなたはあなたの立場を立てることができます。

他の人のコメントに加えて：

1. はい、エントリーレベルの従業員に他の誰もやりたくない仕事が与えられるのは普通です。

2. これはあなたの将来のキャリアのためのビルディングブロックとして見るべきです。

それで、あなたは何をすべきですか？プロの開発者であることを証明するためには、作業が構造化され計画されていることを確認する必要があります。あなたはまだではありません）。

1. プロジェクトごとに作業内容を正確に記録します。したがって、プロジェクトAのバグ修正に1時間かかる場合は、この時間を記録してください。これは、ワークロードについて議論したい場合に上司に示すのに役立ちます。

2. 単体テストを作成します。あなたが維持しているプロジェクトのいくつかはバグだらけだと言っているので、私の推測では、ユニットテストは（もしあれば）ほとんどないでしょう。バグレポートごとに、バグを再現する単体テストを作成し、バグを修正します。これにより、リグレッションが発生しないようになり、コードの品質が向上し、機会が与えられた場合にコードをリファクタリングするプラットフォームとして機能します（たとえば、一部の部分を書き換えることで改善できることを関係者に納得させることができます）ユニットテストスイートにより、新しいバグを導入せずに品質を向上させます）。

3. 新しい仕事を探してください-あなたは一度に多くのプロジェクトに取り組み、コードをゼロから書き、おそらくプロジェクトのライフサイクル全体を経験しているでしょう-これらはすべて他の場所に適用するのに良い経験です。

あなたの状況は少し鋭利ですが、まだ正常です。しかし、それを扱う方法は非常に悪いです。ここにあなたがする必要があるものがあります：

• 上司に立ち向かおうとしてください。悪いコードベースが実際にどれくらいの時間かかるかを示す証拠（数字）が必要です。彼が技術的負債などを理解していない場合は、言及しないでください。それはあなたの頭を破壊し、あなたは「悪い態度」の人としてマークされる可能性があります。上司に仕事をすることを教えるのはあなたの仕事ではありません。

• 独自のバックログ（かんばん）を維持します。新しいタスクが来たら、それを最後に置き、完了の推定時間を知らせます。

• 応答時間を増やし、1日2回だけメールをチェックしてください。通常、昼食前と出発直前。（メールをチェックした後、頭を台無しにする可能性があるため、コーディングは行わないでください）。

• 各タスクの一部として、コードを少し改善します。使用しているコード、スキル、ツールを改善するのは、単にあなたの仕事です。また、長期的にあなたの道徳を高めるでしょう。

• 日中はプロジェクトの切り替えはありません。今日、あなたは単にプロジェクトXに取り組んでおり、明日はYのために他のタスクを開始します。

• ゲートを維持するために1日1時間を割り当てます。これは、実行するのが簡単な小さなタスクを意味します。このタスクに10分以上かかる場合（理由は関係ありません）、バックログに記録され、マネージャーに遅延が通知されます。

ここで難しい部分があります。現在、マネージャーはお互いにコミュニケーションを取り合っておらず、あなたが自分のプロジェクトを最大限の優先度で終了すると仮定しています。あなたは議論の最中にいるので、これはあなたの頭に多くのストレスをもたらします。管理者に作業の調整を開始させる必要があります。最後に、素敵でシンプルなバックログを用意し、マネージャーはあなたなしでお互いをいじめるべきです。

それでは、簡単なロールプレイをしてみましょう。3つのマネージャーとプロジェクトがあります（プロジェクトXのXavier、プロジェクトYのYvonne、プロジェクトZのZed）。2週間、Xで5日間、Yで5日間のバックログがあります。

• Zは、タスクを実行するように求めます（1日）
• あなたはそれが11日で完了すると答えます。
• Zは単純なタスクであり、1日以上かかることはないと回答します（Zは小さな圧力をかけることに注意してください）。
• あなたは現在Xで働いていて、後者でZで働いていると答えます。その後彼女の仕事をすることができます。
• Zは、とにかくすぐに自分のタスクを実行する必要があると応答します（圧力の増加、XおよびY領域の直接違反）。
• あなたは、彼女の仕事をするとXとYの仕事が遅れると答えます。最初に彼に尋ねるべきです。また、CC XおよびY。

現在、2つの目的があります。

• マネージャーはお互いにbarえ始め、多くの電子メール、おそらくいくつかの会議...離れて、勝者にタスクを割り当てさせるべきです。

• 何も起こらないので、Zは2日後に彼の仕事の場所を尋ねます。あなたは現在Xで働いていると答えますが、彼はプロジェクトZについては何も言及しませんでした。再びCCX。

今、このタイプの行動はあなたを解雇することができます。しかし、あなたの状況は持続不可能であり、おそらくとにかくすぐに辞めるでしょう。このソリューションは、マネージャーが互いに競合している場合にのみ機能します（非常に通常）。また、誰かが不平を言う場合に備えて、あなたが怠けていると作業の記録（バックログ）を保持する必要があります。

7年前、私はしばらくの間、ほぼ100％のメンテナンス作業を行っていましたが、それについての記事を書きました：The Art of Maintenance Programming。役に立つかもしれない部分：

1. 好きになる

メンテナンスプログラミングが好きな人はいますか？開発者は、チームのチーフアーキテクトになることを夢見ており、既存のソフトウェアを維持することになったとき、それはほとんど罰のように感じられます。メンテナンスプログラミングには独自の課題があり、多くの創造性、適応性、忍耐、規律、および優れたコミュニケーションが必要です。履歴書にも「Architected n-tier 24/7 enterprise application」のような大げさなエントリがありますが、雇用主は問題を解決する人々を大切にしています。メンテナンスプログラミングは、問題解決のスキルを示す良いチャンスです。

あなたの問題は、あなたがよく耳にすることのように聞こえます。これは、The Daily WTFに簡単に適合する仕事のようです。

多くの組織は、品質よりも販売や機能プッシュに重点を置いています。それらの企業が見逃しているのは、ソフトウェアの外部品質以上のものがあるということです。ワードカニンガムは技術的負債という用語を作り出しました。

また、技術的な負債についてSteve McConnellを読むこともできます。彼にはいくつかの興味深い点があります。Google Tech TalkでKen Swaberがアジャイルソフトウェア開発について語っています。良い部分は、あなたに似た物語についてです。彼は、リファクタリングを一切行うことなく、さまざまなプログラマーによる10年間のプログラミングの後に「頭脳」になったソフトウェアプロジェクトについて語っています。このビデオを見れば、あなたが説明しているものと多くの類似点があると思います。

ソフトウェアシステムは、拡張されると品質が低下します。実際、サービスを提供するためには、それが必要になります。リーマン法律は非常によく、この原理を説明します。最終的には、次の質問に要約されます。「上司にリファクタリングを行うよう説得するにはどうすればよいですか？」。

同様の問題にどのようにアプローチしたか：

• 私は上司と対決し、開発を続けるとコードの品質が低下することを説明しました（Lehman Laws）。
• 上司に技術的負債の概念を説明しようとしました。そして、彼があなたに仕事をさせる方法は、長い目で見れば彼にお金がかかるということです。
• 問題がどれほど深刻かを実際に彼に示すために、私は（自分の時間で）静的コード分析を行いました。ボスはソフトウェアを理解していませんが、数字は理解しています。コードメトリクスには欠陥がありますが、話せる測定可能なものがあると便利です。これらのメトリックの通常の測定値を調べてみてください。これを自分のコードベースと比較すると驚くでしょう。
• 何も役に立たず、何も変わらない場合、できることは、特定の新機能がコードベースの他の部分のいくつかの再作業を必要とすることを説明することだけです。コードが重複していて、変更のコストが重複するような何かを変更したい場合に説明します。
• 前のポイントに対する一般的な答えは、誰もこのリワークを要求しておらず、したがってこのリワークに対して支払われていないということです。「おそらく」このやり直しは不要です。ソフトウェアは常に変更する必要があることを説明する必要があります。同様リーマン法律と言います。使用し続けるには変更する必要があります。そうでない場合、変更した他のプログラムは常に存続します。変化を期待し、変化に適応できるのは生き残ることです。これがアジャイルソフトウェア開発のすべてです。（ウィキペディア）

私の上司は最近、技術的負債の概念を使用して、構築するソフトウェアの一部を時々修正する必要があることをお客様に説明しています。ただそれを証明するために-合理的な上司がいれば、物事をより良く変えることができます。

あなたが直面している状況は、（完全ではないにしても）ほとんどの新入生にとってほぼ同じです。

これは、キャリアの初期段階で起こります。キャッチは次のとおりです。この問題を克服し、会社にとっての価値を証明する必要があります（中規模であろうとMNCであろうと）。状況が私たちに何を要求するかについて決定を下せるはずです。したがって、あなたがそれに気づき、あなたの仕事の個人として立つことを条件に、仕事に努力を注ぐことに何の害もありません。あなたが価値があるなら、会社は気づくでしょう！Adiosと幸運を祈ります。

私の意見では、リファクタリングを禁止している会社は働く価値はありません。リファクタリングは必要不可欠なソフトウェア開発スキルであり、バージョン管理ツールは、（場合にリファクタリングが実際に「トランク」を破壊することなく分離の変化を開発することが非常に簡単になりますし、何かを破ります）。以下のようアンクルボブは言う（言い換え）：「あなたはプロになると、あなたの仕事の権利を行うように依頼していないはずです。」

メンテナンスプログラミングは、不良コードの永続化を意味するものではありません。

5年前に友人からこのメールを受け取りました。

Email body:    

新しく参加した研修生エンジニアが上司に「評価の意味は何ですか？」

ボス：「辞任の意味を知っていますか？」

研修生：「はい、します」

ボス：「だから、評価を辞職と比較することで評価について理解させてください」

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

研修生：「はい、上司です。今、私の将来を理解しました。評価のために辞任しなければなりません... !!!」

私があなただったら、無料でアプリケーションを再構築する作業の後、数時間遅れて過ごすことになります。たぶん楽しい仕事でしょう。完成したら、上司に見せてください。それが機能し、メンテナンスを行っている場合、彼は心配する必要はありません。これはあなたの仕事をより簡単にし、会社でのあなたの可能性に高いレベルの目を開くでしょう。

私はフルタイムの大学生で、1時間10ドルでパートタイムインターンシップをしています。退屈で反復的で簡単なQAを行います。いつかこれがより大きくてより良い場所への扉を開くことを知っているからです。

はい、あなたと他の人の両方が書いたアプリケーションを常に維持する必要があります。唯一の例外は、メンテナンスを一切必要としないプログラムを作成する場合です。したがって、メンテナンスが得意です。

あなたのアプローチの欠陥についてのあなたの質問には微妙なヒントがあると思います。つまり、バグの修正にはコードの改善は含まれません。

しかし、その後、既存のコードを改善することは許されず、バグが報告された場合にのみバグ修正に集中することができないと聞いた。

「コードを改善せずにバグを修正する必要がある」と誰かが言ったとは信じられません。これは困難であり不可能です。できないのは、既存のコードベースで使用されているアプローチが気に入らない、または理解しにくいという理由だけでアプリケーションを書き直すことです。

私のアドバイスは、リファクタリングを学ぶことです。バグを修正するときはいつでも、少なくともコードの一部を改善する機会があります。どのくらいのコードベースがリファクタリングされるかは、バグの種類とコードの良し悪しに依存します。しかし、バグを修正し、コードを故意に残しているのであれば、仕事をしておらず、技術的な負債を積み上げていることになります。

いくつかのバグは実際には単にリファクタリングによって修正されますが、コードを理解するのに役立つようにリファクタリングすることが役立つ場合があります。これは、リファクタリングが保守性とコードの一貫性を改善する必要があるためです。

バグ修正を見積もるとき、通常、メジャーリファクタリングがそれを行うための最良の方法であるかどうかを判断し、それを考慮します。単体テストでも同じです。これらは両方とも、コードを記述する方法の一部であり、余分な時間を伴うオプションのものではありません。

したがって、「バグを修正するときにコードを改善できますか？」と尋ねるべきではありません。とにかくする必要がありますので。「バグを修正するためにリファクタリングを使用できますか？」と尋ねるべきではありません。アプリケーションのバグを引き起こしているコードがリファクタリングを急ぐ必要がある場合、とにかくそれを行う必要があるためです。「このバグを修正するときにユニットテストを書くことはできますか？」と尋ねるべきではありません。バグの修正を試みる前に、回帰テストを作成する必要があるためです。

NB：私は彼の記事の3つをリンクしたように、この答えの帰属はジェフ・アトウッドに行くべきだと思います。

これはお金がすべてです。私の推測では、スターターとして、あなたはすでに彼らが支払ったよりも多くを得ている顧客にはおそらくあまりにも親切だと思います。

新規リクエストの価格の見積もりをご覧ください。これは決して簡単なことではなく、顧客は頻繁に試してみます。可能であれば、経験豊富なプロジェクト/製品マネージャーの助けを借りてください。

お金の観点から考えると、経営陣とのコミュニケーションが非常に簡単になります。現在の顧客がフルタイムのお金を提供している場合、新しいプロジェクトを選択しないでください。しかし、あなたは、経営陣があなたをいじめようとしていることを理解するでしょう。

会社にとって本当に価値があるなら、交渉力が得られます。より多くの人を雇う、新しいプロジェクトを減らす、メンテナンスの負荷を軽減する、または給与を増やすよう依頼することができます。

あなたが既存のコードを改善することを禁止されているという程度まであなたをマイクロ管理することはあなたの雇用主の決定であってはなりません。あなた自身の専門的な判断を使用してください。仕事を見積もるとき、将来の生産性が向上する場合、リファクタリングを許可するために追加の時間を考慮します。

とにかく、雇用主と効果的にコミュニケーションをとっていないようです。

1. リファクタリングでお金を節約できるという証拠があります。リファクタリングプロジェクトの提案を作成し、ビジネスがどれだけの時間とお金を節約できるかを示します。コードにどのような変更を加え、どのくらいの時間がかかるかを正確に説明してください。

2. 正確なログを保存して、コーディング、会議、電子メールの返信に費やした時間を記録します。これにより、スケジュールに遅れが生じた場合でも保護されます。

3. 速度を落とす。これは直感に反するように思えるかもしれませんが、すべてを迅速に行う場合にのみ時間を乱用します。あなたが少なければ、人々はあなたの時間をもっと尊重します。たとえば、メールを1日に1〜2回しかチェックしません。そうしないと、燃え尽きる危険があります。

4. あなたの賃金率を考えると、頭痛を解消する価値はありません。毎日定刻に出発するようにしてください。追加の補償なしで余分な時間を費やさないでください。例外は、優れた昇進オプションがある場合、または会社の評判が履歴書を大幅に後押しする場合は、単にそれを吸い上げる必要があります。

もっと知ることなく、私はあなたがあなたのマネージャーともっとオープンになろうとすることをお勧めします。おそらくタスクの見積もりを増やし始めてください。ワークロードがどれほど忙しいかを常に思い出させます。また、上司と会い、今後6か月以内に昇給を希望することを説明し、この昇給を達成するためにパフォーマンスを改善する方法を尋ねる必要があります。

幸運を。

私の経験では、アカデミックな世界、またはハイテク志向のスタートアップの最初の6〜12か月は、真の白紙に遭遇する唯一の信頼できる分野です。どちらも独自のコストを負担しますが、コーディングが大好きで、実際にコードの品質に驚かされることが多い場合は、これらの方向のいずれかにキャリアを向けるべきです。

雇用主と話してみて、これを解決できるかどうかを確認してください。あなたはこれについてあなたの頭上で道を進んでいるように聞こえます、そしてそれは悪いプログラマーであることとは何の関係もありません。

小規模なWeb企業では、同時に多くのプロジェクトが進行する傾向があり、多くの点で、あなたは抜け穴に追い込まれます。状況を最大限に活用するか、可能だと思われる場合は新しい仕事を見つけてください。より良いコーディングの仕事があることを約束しますので、この最初の仕事であなたを怖がらせないでください。

幸運を祈ります。あなたと同僚の両方が、重力やあなたの努力を理解してくれることを願っています！

個人的体験

ここの多くの人と同様に、私もあなたの状況を認識しています。私は基本的に低給で初めてのコーディングの仕事を得て、貧弱な構造で多くのビルドされたコードを維持しなければなりませんでした。最初は新しいことを学ぶのが面白かったのですが、最終的には維持すべきプロジェクトが多く、新しいプロジェクトを作成し、ホワイトボードが毎日増え続けていたので、それで終わりではありませんでしたうまくいきませんでした。

2年間それを我慢した後、私は辞め、数ヶ月後に私にぴったりの別のコーディングの仕事を見つけました。

とにかく、問題になるのはあなたのプロジェクトだけではありません。自分の仕事に対して認められ、尊敬されるようになると、職場でより快適になります。あなたがいる状況の問題は、雇用主が作成されたプロジェクトから生じるバグにのみ気づき、他のすべてのバグを削除する時間ではないことに気付くかもしれないということです。

給料

もっとお金が欲しいなら、しばしば手に入れることができます。私は2年未満で33％の昇給を目指して給与を交渉しました。

基本的に、あなたの仕事の価値と、会社があなたにどれだけ必要かを考えてください。彼らがあなたが稼いだ給料をあなたに与える余裕がないなら、会社は彼らの経費を見るか、彼らのビジネスが機能していないことに気付く必要があります。

そして、ここで多くの人が言及しているように、そして私も同意しますが、あなたは会社のパズルの非常に価値のあるピースです。地獄、あなたはおそらくそのパズルを解くことができる唯一の人です。:)

このStack Exchangeサイトに潜んでいるのでまだコメントできないので、ここに情報を追加します。

1. 始めたばかりなので、Microsoft、Amazon、またはそれに類するもののような大企業で働きに行かない限り、給料は素晴らしいものにはなりません。しかし、それは食料品店の従業員のものであってはなりません！長い間それを我慢しないでください、あなたがしていることをやって経験を積んで、より良い機会が生じたときに進みます。

2. エントリーレベルのギグでは、これは一種の正常です。ワークロードが高すぎますが、作業のタイプが予想されます。より良い開発者になるためには、他人の過ちから学ぶ必要があります。見れば見るほど良くなります。しかし、それはあなたが悪い習慣を学ぶのではなく、学ぶことを探していることを意味します...

3. プロジェクト作業に対するメンテナンスの比率は、時間の経過とともに変化するはずです。そうでなければ、それはあなたが働いている会社が優れた開発者を維持する方法を理解していないことを意味します。彼らはあなたに毎日同じことをさせるつもりです。あなたがどこに行きたいか、給与と仕事の期待を賢明に自分自身のために年間目標を立て、それに応じて移動します。

4）あなたが幸せでないなら、去ってください！人生は愚かな人々に対処するには短すぎます。

ではごきげんよう。

課題リストを使用して、ToDoリストを追跡し始めます。

これは、重要なものを追跡するのに役立つだけでなく、ユーザーと上司が現在のワークロードを確認するのに役立ちます。

また、2人目の開発者を雇った場合（または辞めて代わりにワークロードを使用するようになった場合）、ワークロードの管理に役立ちます。

この連鎖を断ち切る唯一の方法は、柔軟性のために設計され、完全なユニット+統合テスト済みの新しいインフラストラクチャを開発することです。

これを管理者に販売する（他の開発者と管理者を1対1のミーティングでコンセプトに署名する）ことで、アプリケーションのコードのほとんどがインフラストラクチャにあり、簡単に状態に到達できます。実際のアプリケーションは軽量であり、非常に迅速に記述できます。

インフラストラクチャの開発により、最初は既存のアプリケーションの一部を交換し、しばらくすると（数年かかる場合があります）アプリケーション全体を交換できるようになります。

長期的には、新しいアプリケーションの開発時間と将来の既存のアプリケーションのメンテナンス時間を大幅に削減できます。

新しい開発には、少なくとも80％（できればそれ以上）のチームが1人以上の開発者を必要とします（少数の人は1人よりも優れています）。すべての開発者は、創造的に考え、既存の先入観を破る必要があります。

このような新しいインフラストラクチャを定義して高度な設計を試み、その定義を同僚や管理者に提示してください。

労働条件に関しては、これらの問題に対処する新しいインフラストラクチャチームを率いて（定義と設計に基づいて）、必要に応じて支援しながら、新しい開発者を雇って古いものを維持してください（最大10-20％時間）。経営陣がアイデアに同意する場合、条件の再交渉を依頼できます。彼らが拒否した場合、別の仕事を見つける準備をしてください。（あなたの仕事にはスキル、知識、経験が必要であり、あなたが信じるためにお金を払っているのと同じくらい簡単に置き換えることはできないことを覚えておいてください。）

上司は、これらのすべての変更要求（保守要求）を認識していますか？彼/彼女は、あなたが制裁の権限を持たないような要求を通してあなたの時間がふるいにかけられることを理解していますか？または、マネージャーがあなたに尋ねるたびに変更を加えるだけですか？

あなたの最初の寄港地はすべてあなたのマネージャーの机の上に置くことだと私には思えます。誰もあなたに直接来るべきではありません。問題は、通常はサポートチームなど、誰の分野でも発生します。通常、短いハンドオーバー期間（通常は1週間程度）でコードをサポートします。「中規模」と分類される会社では、変更に費用がかかり、請求（振替請求）される必要があり、これはバイパスされているようです（彼らがあなたに殺到しているのも不思議ではありません-あなたはプロムの女のようです）。

問題の提起と変更要求の両方に対して適切な要求手順が必要です。サポート/メンテナンスとは、バグや問題の修正に関するものです（元の仕様には適合しますが、コードのバグや、電源切断や上流システムの破損などの外部イベントのために失敗します）。

あなたの会社がこれのどれも提供せず、あなたがこの無数のランダムなリクエストに対処し責任を負うことを期待しているなら、真剣に先に進むことを検討する必要があります。一番下の給料は常に貧弱です-最初のプログラミングの仕事（ほぼ25年前）で同じ会社に8年を費やし、給料は少し上がりました（常にキャッシャーよりもずっと高かった！）。退職してから2年以内に2倍になり、その2年後には、当初の10倍以上を家に持ち帰りました（ただし、独立した請負業者でした）。いつものように、拍車を稼ぎ、貿易を学び、より暖かい環境に船をジャンプします。

多分あなたはマネージャーに行ってこう言う立場にあるでしょう：「見てください、私はあなたと率直になります。私の給料はひどいです、私はこれをXでエントリーレベルのプログラマーとしてN倍得ることができます。

私は、A、B、およびCを使いすぎています。これを維持することはできません。正直に言って、攻撃は意図されていません。これを修正するか、辞表を残してこの部屋から出ます。これがすべて空中になったので、どうやって一緒にこれを正しくすることができますか？」

答えは、理解できる用語で試して説明することです。

• オイル交換のようなものです。緊急ではありません...しかし、それでもなお定期的に行わなければなりません
• さびの上に塗ると見栄えが良くなります。出血するまで
• サポートを強化せずに新しいルーフパティオルーフデスクを構築します。しばらくは動作するでしょう。その後、それは崩壊し、人々を傷つけ、あなたは責任を負います。
• エアコンは素晴らしいです。窓ユニットは、1〜2部屋に最適です。146の窓ユニットエアコンをアパートに置こうとすると、問題が発生します。
• 5人の子供を教えるのは問題ありません。10はそれほど悪くはありません。ただし、制限があります。75人の子供に非公式に教えてみてください。これが表示されます。

これらが共鳴しない場合。出発-次の日ではなく、執筆のオファーを得る日！新しい仕事に就いたら、ゼロ通知を残してください。文字通り、その日は来ないでください。ただし、自分が何をしたかを知っている同僚が1人か2人いることを確認してください。これは、会社を支援することができれば、彼らの無礼とar慢が犠牲になることを示すことで、実際に会社を助けます。最後の会社は、6か月以内に4つのTechの左にあり、仕事はありませんでした。それは少なくとも声明を出して、去る人に一度言って良い機会を与えました。

最後に、20年前にアジャイル、tdd、bdd、リファクタリングが標準よりも多くなるようになる前に、この状況がNORMおよび標準であったことを知ってください。あなたはすぐに「私はこれを自分でやったし、それはうまくいきました、なんと、何とか、何とか」と答える高齢者と話しているかもしれません。まあ、確かに馬と馬車は150年前にうまく機能しました。技術分野では、20年前の技術は150年前の輸送と同じくらい時代遅れです。彼らがこの罰金を拒否した場合。ただ、彼らがまともな現在の技術開発者を雇うことは決してないことを知っておいてください。彼らは最悪の最悪の事態に陥り、ビジネスをひどく傷つけます。彼らがテクノロジーに依存しており、適応できない場合、彼らは失敗し、最終的にそれはあなたにとって最高の報酬になるかもしれません。それ'

経営陣は基本的にあなたを尊重したり、仕事の負荷を理解したりしないようです。

通過するすべての機能要求を実装するべきではありません。あなたのマネージャーは、あなたと入ってくるリクエストの間のバッファとして振る舞うべきです（おそらく最も単純なブレーク/フィックスリクエストを除く）。その後、彼または彼女はあなたと一緒に座って、承認されたリクエストの実行可能性と優先順位を決定する必要があります。

また、あなたはおそらく彼らがあなたに払っているものを（少なくとも）2倍にする必要があります。

彼らはおそらくあなたと一緒に仕事をするために少なくとももう1人の開発者を本当に必要としているように聞こえますが、彼らがあなたに払っているもので、それはかなりありそうにないように聞こえます。

彼らがあなたに十分な賃金を払わないか、あなたがあなたの仕事量を管理するのを手伝おうとしないなら、私は新しい仕事を探しています。チームの一員であり、経営陣があなたと協力してプロジェクトを完了する場所で働きたいと思っています。沈没船をできるだけ早く降ろしてください。

一人のチームでヒーローになることは、あなたを燃え尽きさせるだけです。

私はまだ学生ですが（それでも）、それはかなり普通です（私のインターンシップの経験から）。これは、サポートおよびWebアプリケーションで作業しているときに得られるものです。

コーディングを始める前に、クライアント（マネージャー）が何を望んでいるかを理解することをお勧めします。時々彼らはそれを自分自身で知らないので、彼らが何かに同意するまで彼らと協力するので、それは難しいかもしれません。コーディングする前に、最終的なソリューションについて両者が同意していることを確認してください。

また、あなたがメンテナーである場合、コードのほとんどすべてを変更できます-動作を変更したりバグを導入したりしないようにしてください。マネージャーは今の状態に慣れていて満足しており、新しい変更にお金を払いたくないので、マネージャーがあなたに何かを「許可」しないことを期待します。

最後に、何か他のことをしているために何かを処理できない場合でも心配しないでください。あなたが仕事に圧倒されており、彼らの要求には時間がかかることを人々に知らせることをお勧めします。あなたがマネージャーでなければ、あなたは怠け者だと思うでしょう。すでに仕事があり、より多くの人を雇うかもしれないことを彼らに知らせてください。仕事が一人の人間にとっては多すぎることを彼らが知る他の方法はありません。

これはプロジェクト管理の問題です。ある種のプロジェクト管理を使用して、取り組むべき最優先事項を決定します。

a）作業するにはアイテムのバックログが必要です。バックログにコードを改善するための計画を入れます。

b）すべてのバグがバックログに記録されます

c）バックログが優先されます。

d）すべてを優先順に実行します。

バグは非常に優先順位が高いかもしれませんが、すべてを修正したら、新しい機能やリファクタリングデザインに費やすサイクルがあります。

リファクタリングの改善を段階的に行うだけで、修正する問題/バグがあるセクションを通過する場合に最も簡単です。その後、管理者に「Aを修正しなければならなかったが、Bは根本的に壊れていたので、Dが将来より簡単/安価になるようにすべて解決するためにソリューションCを行わなければなりませんでした」アンチパターン、C =ソリューション、D =将来のゲイン

行う価値のある投資として仕事を正当化できない場合、ビジネスマンはそれを決して受け入れません。

これはいつものようにビジネスです。そこで働き続ける限り、あなたは悪用されるでしょう。自分がやっていることに満足感を与えるよりも、このモデルを使い続けることが会社の最大の関心事です。結局のところ、彼らはあまり気にしません。それは彼らのために信頼できるコードを作成することであり、もしあなたがワンマンバンドなら、彼らは確かにあなたの銀行を作っています。なぜ変わるのですか？

これらすべての良いニュースは、たとえ彼らがそれを知らなくても、あなたは彼らにとってVIPであるということです。私がすることをお勧めするのは、船をジャンプする前にいくつかの機会を揃えて、ボールをつかんでより高い給料を要求することです。より良い機会に移動しない場合。私の意見では、あなたはすぐにもっとエキサイティングな作品を見つけるはずです。できるだけ高く目指してください。開発者ショップに着くと、Googleや楽しいスタートアップのように、共同開発者の文化があり、本当に幸せな気分になるでしょう。

私が個人的にやったことは、ヘッドハンターの請負業者組織を使用して、請負業者からの安定した雇用を維持しながら、すぐに多くの素晴らしい経験を得ました。それはあなたが退屈するのを防ぎ、あなたに挑戦します。最終的には、空き時間に実際のビジネスに開花した小さなビジネスをいくつか構築し、その後、契約作業から船を飛び出しました。