専用のメンテナンス作業はプログラマのキャリアを妨げますか?[閉まっている]


52

過去3年間の私の仕事の大部分は、再販売する前にパッチの適用や時折の改良が必要なレガシーシステムの維持に主に取り組んできました。

多数のプロジェクトを抱え、開発者が限られている企業では、専任のメンテナンスプログラマが果たすべき重要な役割を理解しています。

しかし、私が現在のキャリアの進歩を判断し、仲間を見ると、請負業者と企業開発者の両方; 私が触れた領域の面でかなりの幅を獲得したので、私ははるかに遅れているように感じますが、深さはあまりありません。ブログを始め、自分の小さなgit-hubプロジェクトに取り組み、仕事の後に定期的に個人的なコーディングを行う時間があるように私の人生を再スケジュールすることで、これに対処し始めました。

メンテナンス作業から逃れるために他の会社に面接したのは、特定のことに焦点を当てた3年の経験を持つ人に必要な深い知識レベルがないので、スキルレベルがかなり後輩であると自分自身を表さなければならないだろうと思う機能開発のパスは。ですから、私の現在の仕事の経験の半分は、長期的には無駄になります。

しかし、これは私の個人的なジレンマにあまりにも集中していると感じたら謝罪する私の主な質問につながります:

専用のメンテナンスプログラミングの役割は、初期のキャリアにとって不利になりますか?他のプログラマは、このような役割を避ける権利がありますか?この作業を行うと、後輩としてやり直す準備ができていない限り、同様のタスクを実行できなくなりますか?


キャリアの初期に使用する技術は、メンテナンス作業を行うのか、新しい開発を行うのかよりも(はるかに)重要だと思います。社内言語または古い言語で需要がほとんどない新しい開発を行った場合、需要の高い言語で新しい開発を行わないよりもはるかに悪いでしょう。
stoj

6
それは確かにキャラクターを構築します。
quant_dev

回答:


70

専用のメンテナンスプログラミングの役割は、初期のキャリアに有害になりますか?他のプログラマーは、このような役割を避ける権利がありますか?この作業を行うと、後輩としてやり直す準備ができていない限り、同様のタスクを実行できなくなりますか?

最初に、あなたはかなり長い間後輩と見なされていることを知っておく必要があります。あなたは優秀であり、これがあなたにまともな給料を与える唯一の方法であるので、あなたはarbitrary意的な昇進を得るかもしれませんが、あなたは次の仕事に向かうとき、あなたはまだ後輩とみなされます。

第二に、2〜4年の経験を持つ人を雇う場合、彼らの仕事が純粋にメンテナンスであるかどうかはあまり気にしません。あなたがメンテナンスに10年を費やし、私がグリーンフィールドプロジェクトのために雇っているなら、私は質問をするかもしれませんが、最初の数年間は、正直にそれを期待しています。

一方で、メンテナンスで働いたことのない人を雇うとしたら、もっと疑わしくなります。私は、最初の4年間を「良い」仕事から別の仕事に飛ばしてきた仕事の候補者をたくさん抱えてきました。そして、間違いなく、私が固執する予定のグリーンフィールドプロジェクトに雇用する場合、あなたがコードを維持するかどうかは気にしません。将来の開発者がそれを維持できるようにする方法を知っていることを気にかけます。

あなたが言及するこれらの他のプログラマーは、これらのような仕事を避けますが、一般的には、彼らがキャリアを妨げるためではなく、あまり面白くないのでそれらを避けます。

最後に、ソフトウェア開発ジョブの非常に大きな割合(保守的に約80%と推測します)が50%を超えるメンテナンスであることを知っておく必要があります。

それで、すべてを切り抜けてあなたの質問に答えるために:いいえ、あなたのキャリアを妨げるとは思いません。あまり長く滞在しない限り。一般的な経験則は、「毎年同じ年の経験を積んでいるように感じたら、次は行く時間です」です。毎年、あなたが昨年よりも優れた開発者であると感じているなら、あなたは大丈夫です(そして、それはあなたと同じように、私のキャリアの20年に私のために行きます)。


25
+1メンテナンスを行うと、誰かがより良い開発になります。

8
+1自分で、または他の誰かのプロジェクトでメンテナンスを行うと、プロジェクトの早い段階で下された決定の結果に感謝し、学ぶことができます。
オフィディアン

メンテナンスの経験があれば理想的ですが、私の意見では、成功するプロジェクトの開発から学んだこと>他のプロジェクトのメンテナンスを学べることです。メンテナンスはあなたにすべきでないことを教えてくれるかもしれませんが、ジェイソン・フリードによって最もよく言われるように:失敗から学ぶことは次回はすべきでないことをあなたに伝えるかもしれませんが、それは次に何をすべきかをあなたに教えません
コレイヒントン

@KoreyHinton:成功した起業家であるジェイソン・フリードは、起業家であることに関して、彼が言っていることを信じていると確信しています。私は、a)彼が何がうまくできるかを実際には知らない、と主張します。b)DHHとRailsを支援することは37signalsの成功の90%であり、それは支払わないギャンブルですc)Jasonでさえも、起業家であるというアドバイスは、必ずしも不適切に作成されたソフトウェアをつなぎ合わせる必要から学ぶことにつながるとは主張しないでしょう。
pdr

@pdrそのとおりです。2つのことは正確には翻訳されません。私はまだ学生なので、経験よりも意見から話をしていました。個人的には、他の人が書いたコードを維持するのではなく、新しいコードを書くことを好むと思いますが、メンテナンスはこの分野で多くやろうとしていることのように思えます。
コレイヒントン

13

どんな仕事においても、あなたが得る経験はあなたがしていることに固有のものであり、その経験に基づいて他の仕事に応募する際の可能性の範囲を制限します。メンテナンスに固有のものではありません。他の質問は、何かがメンテナンスであるか新しいソフトウェア開発であるかよりも関連性が高いと思います。

  • 使用している特定の技術はどの程度普及していますか? 時代遅れで他ではめったに使用されないものを維持している場合、将来のキャリアの機会が制限されます(ただし、広く使用されていないシステム/プラットフォーム/テクノロジー用の新しいソフトウェアを開発します)。
  • 現在の仕事は、将来やりたい仕事をどのように整えますか? あなたが指摘したように、メンテナンス作業は重要であり、常に行われます。この種のプログラミングに焦点を当てたキャリアを持つことには何の問題もありません。システム管理者には常に多くの可能性があります。しかし、それはあなたがやりたいことではないかもしれません。あなたの現在の仕事があなたが興味を持っていることにあなたを準備していないなら、それは心配です。

しかし、私はあまり心配しません。あなたが言うことの一つは:

触れた分野に関してはかなりの幅がありましたが、深さはあまりありませんでした。

これを問題として考えないでください。あなたの利益のために使用できるからです。幅広い経験を持つということは、「はい、私はそれをやった」と言うことができるものが幅広いことを意味します。多くの仕事は、いくつかの異なる技術とタスクの経験を求めています。1つのテクノロジーに非常に深い経験を持っている開発者よりも有利になる可能性があります。

さらに、多くの仕事には、メンテナンスと新規開発が混在しています。さらに新しい開発を行いたい場合は、既存のメンテナンスエクスペリエンスを使用して、より多くの開発エクスペリエンスを提供する混合ロールに移行できます。

結論として、履歴書はおそらくあなたが思っているよりも良いでしょう。その多くは、あなたの経験の長所をどれだけうまく分析し、申請と面接プロセスでそれらの長所を伝えるかにかかっています。


+1 幅広い経験について。15年間の開発と昨年のメンテナンスを終えて、個人的な経験から、開発にとどまるよりも多くの言語とプラットフォームに触れたことがわかります。フリーランスとして、幅広い知識(ジェネラリスト)を持っていると、すぐに仕事がなくなる可能性が低いという安心感が得られます。おそらくこれは、スペシャリスト(専門家)がより多くのお金を稼ぐ可能性を犠牲にしているのかもしれませんが、私はむしろリスクを減らしたいと思います。
リーベンキースマッカーズ

2

専用のメンテナンスプログラミングの役割は、初期のキャリアに有害になりますか?

多くの場合-はい、仮定:

  • ここでのキャリアとは、さまざまな技術スキルの専門知識を意味します。
  • そこにX年以上を費やします。Xはあなたの考え方を「設定」するのに十分です。
  • 脇に何もしないこと。
  • その「専用メンテナー」(下記のEDITを参照)は、新しいものコーディングするだけでなく、メンテナンスするためのコードも作成しないことを意味しますが、ほとんどの場合、メンテナンスモードでプロジェクトを維持するか、プロジェクトで作業するためのコードです-新しい機能は必要ありません。バグを修正するためのコードの変更。

これは、常にそうであるという意味ではありません。

ソフトウェアをメンテナンスしている人は、研究を行うことはめったに奨励されません(下記のEDITを参照)。これは(通常)安定した仕事であり、既存のコードベースへの最小限の変更を必要とするため、後で問題にアプローチする方法を「形成」します。「コードの変更が少ないほうが良い」と明示的に述べているソフトウェアを保守するポリシーを持っている会社はかなり多くありますが、それがもたらす悪いこともあります。

他のプログラマーは、このような役割を避ける権利がありますか?

自分の仕事が好きで、どこにいても快適だからこそ、他の何かに応募したくないという非常に優れたメンテナーを知っています。誰もが時々新しいことを学ぶのが好きというわけではありません。だから-あなたの好みに応じてそれを避けるか、探します。

この作業を行うと、後輩としてやり直す準備ができていない限り、同様のタスクを実行できなくなりますか?

多くの場合-はい。すでに「ロープを知っている」などの理由で、すでにそれを行った経験があるためです。しかし、シフトは間違いなく可能であり、ジュニアポジションを申請せずに発生する可能性があります。あなたはすでに物事を脇に始めました、それを続けてください!それは実際に非常に価値があり、気づいた「スキルギャップ」を縮めることができます。


編集:ダンは(非常に正確に)指摘しましたが、メンテナンス作業はしばしば研究で行うことができます。それは本当です。これに対処するために、上記の答えを2か所で変更しました。

このようなタスクは、確実にこの方法で行うことができます。しかし、私の知る限り、レガシーシステムの最もDEDICATEDメンテナがいることをポリシーや管理の期待と期限を持っている-再び、少なからず -強制それらを可能に少なくとも変更の問題を解決するに。多くの場合、プレッシャーは十分に高いため、この方法でそれを行うことができたとしても、そうしたくない場合があります。特に、それがあなたのコードではない場合:理論がなければ(RyleとNaurによると)その背後にあるのは、あなたが修正する以上の損害を与えるリスクがあります。

それにもかかわらず、注意する必要があります:私はハードなグローバルデータを持っていません、私自身の経験から話します-私はOPとしての状況で働いた、私はメンテナーとして4-10年の経験を持つ人々を募集し、私は多くのメンテナーと話しました熱心なメンテナーとして働いている人々を知っています。新しいものをコーディングする人だけでなく、プロジェクトを維持するためのコードもあります-専任のメンテナー、唯一の仕事はバグとパッチを行うことであり、新しい機能は1つでもありません。古いプロジェクトであり、現在は「メンテナンスモード」にあるためです。


@ dan1111、そうではない部分は?これが重複しているにもかかわらず、私は喜んで答えを改善します。
LAFKによると、モニカを復活させる

ダンありがとう。コメントへの回答が含まれていると思われる部分を強調するために、回答をいくらか拡大します。
LAFKによると、モニカの復職は

回答の追加作業に対して+1。特に、自分の経験の範囲を説明することは、答えの信頼性を確立するのに役立ちます。

「人々がソフトウェアを保守しています...新しいライブラリやDBをプラグインすることはほとんどなく、その動作方法を見つけるのに数日費やすことができます。」それは本当に私の経験ではありません。メンテナンスプログラマは、なじみのないものに飛び込み、その本質(プログラムまたはライブラリ)をすばやく理解する必要があります。少なくとも、異なるものを維持している場合はそうです。何年も同じものを常に維持している場合、それに付随するネガは「メンテナンス」によって引き起こされるのではなく、同じものを長時間作業することによって引き起こされます(どこにあるかに関係なく)ライフサイクル)。
user1172763 14

こんにちは@ user1172763。メンテナンスの定義は非常に並外れていると言わざるを得ません。私がダンのために追加した部分は、あなたのような、より興味深いメンテナンスのケースに対応していると思います。しかし、私はそれが標準的なメンテナンスであるとは思わない。ただ確認するために-ダウン投票の理由は、あなたの経験が私の答えと一致しないためです?次に、他の人が読んで判断できるように、私が述べたように、あなたの情報源を述べてください。
LAFKによると、モニカを復活させる14

1

機能開発の特定の道に焦点を当てた3年の経験を持つ人に必要な知識のレベルの深さがないため、私はスキルレベルがかなり後輩であることを表明しなければなりません

正しい。「X、Y、Zを使用してゼロからシステムを設計した3年の経験」と言うことはできませんが、「X、Y、Z を使用してゼロからシステムを維持した 3年の経験」と言う必要はありません。あなたの履歴書に正しい嘘。

メンテナンス作業から逃れるために他の会社に面接したのは、特定のことに焦点を当てた3年の経験を持つ人に必要なレベルの知識の深さがないため、スキルレベルがかなり後輩であると表明しなければならないからです機能開発のパスは

「システムをゼロから設計および構築します」と言いたい場合は、はい、自分をジュニアとして分類する必要があります。

ITでよくあることは(そして、これがあなたがしていることだと言っているわけではありません)、人々はX年間働いていて、X年の経験があり、{不定年数}後、シニア{ウィジェット}開発者と見なされる必要があります。

誤解しないでください、メンテナンス作業には何の問題もありません。誰もがいつかそれをしなければなりませんが、あなたが気づいたのは、それをあまりにも長く続けることはあなたにとって難しいことです将来その役割から脱却してください。これは、多くの場合、新しいテクノロジー/ツール/メソッドを学習せずに「スタック」することと関連しています。

理想的には、「新しい」システム作業とレガシー作業の両方が必要です。

前向きな注意として、あなたはおそらく、多くの異なるアーキテクチャ(良い面と悪い面)、異なるアプローチ、悪い決定がレガシープログラマを後々までずっと難しくすることができる方法を見てきました。これらはすべて、強調できるよりも肯定的なものです。

幸運を!


0

これを別の角度から見ると、メンテナンスの専門家として自分自身を売ることは市場性のある機会だと思います。

外出先で複数のプロジェクトを持つソフトウェア会社のオーナーとして、私が最小化する必要がある最大のリスクの1つは、出荷を急ぐ開発者と、その後のコードのメンテナンスです。

メンテナンス作業に情熱を傾けることができると仮定すると(あなたの経験についてブログを書く準備ができているので、そうなると思います)、メンテナンスの第一人者としてサービスを提供してくれたなら、コードのリファクタリング、最適化、およびドキュメント化による開発者のさまざまなプロジェクトの長期的な保守性-保証をバックアップする実績があった場合は、すぐに採用します。

私のアドバイスは、これを適切に試すことです。自分をメンテナンスの専門家として位置づけ、ブログを開拓してください。あなたは何かをしているかもしれません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.