私のネガティブなインターンシップの経験は現実の世界を代表していますか？[閉まっている]

インターンとしての私の現在の経験が実際の業界の代表であるかどうか、私は興味があります。

背景として、私は2つのコンピューティング専攻と主要な大学の数学専攻の大部分を経験しています。私はすべてのクラスをエースし、それらすべてを崇拝してきたので、私はプログラミングがひどくないと思いたいです。私は大手ソフトウェア会社の1つとインターンシップを取得しましたが、途中でコードの品質が非常に低いことにショックを受けました。コメントは存在せず、すべてスパゲッティコードであり、間違っている可能性のあるものはすべてさらに悪いものです。私はたくさんの個別指導/テイニングを行ったので、悪いコードを読むことに非常に慣れていますが、私が見ている主要な業界製品はそれのすべてに勝っています。私は1日10〜12時間働いていますが、どこにでも行くような気がしません。文書化されていないAPIを見つけようとしたり、（完全に文書化されていない）製品のその他の部分の動作を決定しようとする無限の時間。私はこれまで毎日仕事を嫌う仕事を辞めてきましたが、これが私の人生の残りの部分であるかどうかを必死に知りたいです。

インターンシップに短いストローを描いたのか（馬鹿げた大きな給料は、それが低品質のポジションではないことを意味します）、またはこれは現実の世界のようなものですか？

彼らはそれをReal World™と呼んでいます。

あなたが実際の企業の世界で遭遇するものの99％はがらくたと考えられます、そして私が説明する正当な理由のために。がらくたと見なされない1％は、最終的にはがらくたになります。

＃1コードを書く、＃2 ????、＃3利益！

利益を得るためにまずビジネスが存在しますが、完璧な黄金のリポジトリに収められた完全に理論的にきれいに設計された原始的な学術コードの山を生成するためには存在しません。近いものではなく、彼らが作ったソースコードを販売するビジネスの人たちでさえありません。

ビジネスの世界では、コードは終わりへの手段です。一部のコードがビジネス上の問題を解決し、作成と保守にかかる費用よりも多くのお金を稼ぐ場合、ビジネスにとって望ましいことです。コードを書くためにあなたを雇うことは、ビジネスがコードを取得するための1つの方法にすぎません。

理論0-練習∞

理想的には、メンテナンスはより懸念されるべきですが、短期的には経済的に勝てないため、通常はそうではありません。長期的には、ソフトウェアのライフサイクルは通常比較的短く、特にWebベースのアプリケーションは、すぐに廃止され、より頻繁に書き換えられます。

社内の基幹業務アプリケーションは、勢いに基づく多くの理由により、無限のゾンビプロジェクトとして認識されているものとして変化し続けています。これらのプロジェクトは、ビジネスの利益を上げ続けているため、実際に成功しています。

理論的には、理論と実践に違いはありません。実際にはあります。-ヨギベラ

理論的には、100％のコードカバレッジを備えた完全にクリーンな原始的なコードベースを完全に設計すると、企業のお金を節約できます。実際には、有効な投資収益率に近いものを提供することさえできません。

ソフトウェアライフサイクルの物理

ソフトウェアの世界では、非常に強力なエントロピー力も働いています。それはすべてのソフトウェアが泥のビッグボールに退化することを非難する不可避のブラックホールです。

BBMから開始するほど良いですが、すべてのソフトウェアシステムは十分な時間を与えられて最終的にそこに到達します。エントロピーを100％に近づける速さは、どこから始めて、どのくらいの速さで技術的負債を積み上げ、それに対する関心がどれだけ高いかによって決まります。

ソフトウェアシステムは、メンテナンスが原因で劣化したり腐敗したりします。定義によりコードを変更せずに何年も使用されているシステムは、そのすべての要件と目標を満たし、成功しています。

エントロピーが最大エントロピーに近づき始めたために絶えず変化が必要なのはシステムであり、常に突かれて突進し、負の変化を加速するのはメンテナンスです。

Good Enough is Good Enough

絶えず変化するWebサイトのような短いライフサイクルシステムは、費用を回収するには償却時間が短すぎるため、ユニットテストで100％のコードをカバーする高価な巨大な先行設計の恩恵を受けません。

上記の内部ビジネスアプリのような長いライフサイクルシステムは、100％コードカバレッジユニットテストの大規模な投資の恩恵も受けません。これは、プロジェクトの存続期間にわたる変化率が、非線形ファッション。

そのため、寿命末期計画がより重要であり、交換システムは何かがリリースされたときに計画する必要があります。数年前にプライムを通過してサポート不能であったため、新しいシステムを急いで設置する必要があります。

私が知っている限り、彼らはBBMについて教えていません。最近のCSの卒業生に出会ったことはありません。

だからこそ、Good EnoughはGood Enoughであり、多かれ少なかれそうではないのです。

ソフトウェアスラムロード

不動産スラム街の大家がいるのには理由があります。彼らは自分たちが所有する貧民街の建物で利益を上げています。彼らは荒廃した財産の増分維持に費やすよりも多くの利益を上げます。そうでなければ、建物を取り壊して交換します。しかし、増分コストは建物全体のオーバーホールまたは交換よりはるかに少ないため、そうではありません。荒廃した不動産に対して喜んで支払いをする顧客（テナント）もいます。

建物の所有者、スラム街の主人、またはそうでない人は、関連する費用を上回る実質的な利益に変換されない完璧さの学問的概念のために、財産にお金を使うつもりはありません。

顧客が許容できる範囲で機能しているソフトウェアシステムのアップグレードに料金を支払うことはありません。目に見える実質的な利益なしに、コードを書いたり書き直したりするだけでお金を使うビジネスはありません。

マイクロソフトが最も支配的で成功したソフトウェアスラムロードです。Windowsはごく最近まで、主要な基礎的な書き換えを取得していませんでした。そして、彼らはまだすべてのレガシーコードをカーネルから落としていません。彼らにとってビジネスに意味はありません。人々は過去10年間に設定した期待の低い水準を喜んで受け入れるでしょう。

予後

これは、私がソフトウェア開発に携わってきた20年以上のパターンです。すぐに変更されることはありません。これは人々が何らかの信念体系から抜け出すことを望んでいる方法ではなく、ビジネスに対する外力の現実です。ビジネスは意思決定を後押しし、利益はあなたの給料を支払う悪ではありません。短期的または長期的なビジョンは無関係です。これは定義によって絶えず変化する短期的な業界です。利益を上げるのに十分な善に反対する人は、ビジネスを理解しません。

コンサルティングに15年を費やし、それだけで十分だということをすぐに学びました。完璧なものにしたかったのですが、ソリューションを販売している時間の99.99999％をコードベースで販売している場合を除き、きれいで整理されたエレガントなコードはすべて失われ、あなたは払い戻しを受けることのない時間を無駄にしているだけです。

進歩と希望

アジャイル手法は、少なくとも哲学的には正しい方向への良い一歩です。彼らは一流市民としての混乱と絶え間ない変化に対処し、それを受け入れます。彼らは、方法論と実践が要件と技術だけでなく変更されるべきであることを認め、独断的な実践を拒否します。

彼らは、時間の不足や要件の変更、スタッフの変更、技術的負債の概念を備えたソフトウェアシステムの活性化によってもたらされるエントロピーを受け入れます。

しかし、アジャイルは万能薬ではなく、物理学の基本的な法則を変更するものではなく、コードベースは関係なく腐敗します。腐敗が完全に手に負えなくなり、管理不能になる前に、腐敗への対処を計画するのは管理者の責任です。

アジャイルは正しく実行されると、エントロピーの管理、スローダウン、追跡、測定、計画的な方法での対処に役立ちます。止まらない！

キャリア決定

これがあなたにとって本当の哲学的な問題であるなら、おそらく他のキャリアの選択肢を考慮する必要があります。オープンソースプロジェクトにはこれ以上の実績はなく、多くの場合、コードは私が見たほとんどの企業コードよりもさらにひどいものです。

インターンとしての私の現在の経験が実際の業界の代表であるかどうか、私は興味があります。

いいえそうではありません。それはあなたのキャリアレベルと経験の代表です。それはすべて、社内の品質管理の観点からビジネスがどのように機能するかについて学ぶことの一部です。

背景として、私は2つのコンピューティング専攻と主要な大学の数学専攻の大部分を経験しています。私はすべてのクラスをこなし、すべてのクラスを崇拝してきたので、プログラミングはひどくないと思いたいです。私は大手ソフトウェア会社の1つとインターンシップを取得しましたが、途中でコードの品質が非常に低いことにショックを受けました。

あなたのスキル、経験、教育は、他の人が行う仕事の質に影響を与えません。単にあなたがそれらの慣行を変更する権限を持っていないからです。あなたが大学で良いか悪いかは関係ありません。それはあなたが現在働いている会社の運営方法を変えるものではありません。素晴らしいことですが、この背景はすべて揃っています。それは本当にあなた自身の利益のためであり、彼らの利益のためではありません。だからこそ、あなたが愛するものを勉強することが重要です。

私は大手ソフトウェア会社の1つとインターンシップを取得しましたが、途中でコードの品質が非常に低いことにショックを受けました。コメントは存在せず、すべてスパゲッティコードであり、間違っている可能性のあるものはすべてさらに悪いものです。私はたくさんの個別指導/テイニングを行ったので、悪いコードを読むことに非常に慣れていますが、私が見ている主要な業界製品はそれのすべてに勝っています。

私が長年のプログラミングで学んだことは、「コードの品質」と「許容されるコード」には違いがあるということです。真実は、権限を持つ誰かが許容できる状態のソースコードを見つけるか、許容できないが必要なソースコードを見つけることです。関与するプロジェクトをすべてクリーンアップできればいいと思います。多くの場合、その作業を行うためのリソースを割り当てることは企業の利益や予算に影響しません。論理的には、翌日太陽が昇るまでこれを修正するのは良いことですが、経営陣が現在の状態が「許容できる」と判断した場合、ほとんど何もできません。それは、誰が物事を実行するかに直接関係しています。彼らは良い内部品質を重視するかしないかのどちらかです。あなたはそれを明確に評価しているため、この現在の状態はあなたを悩ます。

内部品質管理に依存している業界では、このタイプの問題の例があります。ソフトウェア開発から製造まで。これを問題としてではなく、単にソースコードの現在の状態として見ることを学ぶ必要があります。これがその方法です。何かを見つけるのにX分かかり、何かを修正するのにX分かかります。

ビジネスはこの余分な時間を気にしないか、許容できると判断します。

文書化されていないAPIを見つけ出したり、（完全に文書化されていない）製品の他の部分の動作を決定しようとするのは無限の時間だからです。これまで毎日仕事を嫌う仕事を辞めてきましたが、これが私の人生の残りの部分であるかどうかを必死に知りたいです。

なぜ大学で長時間勉強して科目を勉強するのが受け入れられたのに、今ではソースコードを勉強するのに長時間を置くことは受け入れられないのですか？雇用主があなたを雇ったのは、あなたがそれを処理できると思ったからだと思います。

いくつかアドバイスをさせてください。優秀な開発者は、フォローしているチームメイトにいつ助けを求めるべきかを知っています。答えが常にコードにあるとは思わないでください。人々にいくつか質問をするだけで時間を節約できました。速度を上げるためにいくつかの助けが必要なようです。

第二に、労働条件がわからない。長時間労働することは、非常に多くの産業での現実です。あなたは自分で解決する必要があるが、私はあなたに伝えることができます。あなたの仕事を憎むことは良い兆候ではありません。あなたはその気持ちに対処し、その根源に到達する必要があります。この体験がネガティブだと思ってすみません。

インターンシップに短いストローを描いたのか（馬鹿げた大きな給料は、それが低品質のポジションではないことを意味します）、またはこれは現実の世界のようなものですか？

あなたは学校で非常にうまくいっていましたが、今ではインターンシップを持っているので、あなたはそれほどうまくいっていません。すでに現実の世界にいるように聞こえます。それは人生の一部です。問題は、あなたはそれについて何をするつもりですか？私の友人が重要なことだけです。どうしたらいいかわかりません。あなたは自分で決めなければなりません。

私はあなたの年齢でのあなたの経験が私が持っていたどんな機会よりもはるかに良かったように聞こえます。90年代の私にとっての生活は、家賃を払って次の契約を見つけるのに苦労しました。自分自身を幸運だと考えてください。

25年とさまざまな企業や業界の後、私は言うことができます：
はい、それはかなり一般的です。
これがエンジニアが通常十分に支払われている理由ですやっています。私はそこにあなたのために感情を投げ込みました-あなたが遭遇するコードについてそのように感じるのは普通です！

表示されるコードは、さまざまなアプローチや標準、さまざまな命名規則などを備えたさまざまなプログラマーによって無限に繰り返されることがよくあります。

しかし何が起こるかというと、$のプレッシャーは常にかかっています。長期的には、より良いコードが唯一の方法である理由と理由を説明することは常に魅力的ですが、多くの仕事では、短期的なクイックフィックスソリューションに時間がかかっています。プロジェクトの標準を破壊するのにわずか1人のエンジニアが必要です。これを実際に解決するには、これを防ぎ、適切なアプローチ（合理的に可能な場合）を守る方法を知っている非常に優れたマネージャーが必要です。

確かなことは、「良いコード」という用語は主観的すぎて役に立たないということです。もちろん、あなたにとって主観的ではありません。具体的な理由/アイテムをリストできます。しかし、他の人々は、彼らが重要だと考える、技術的でさえないさまざまな項目と優先順位を列挙しているため、主観的です。

ドレッカのように、これは憂鬱に聞こえ始めているので、それが確かに真実であるので、私はもう少しポジティブに変えてみてください：-

• 団体、最大の技術的な要素を持つことが多いものがありますされている右のことをやっては。
• 新しい会社...とコード...それはきれい傾向があることを。スパゲッティは時間と人によって成長します。
• 一部の人はTDDとBDDを実行しますが、他の人は実行しません。範囲は広大です。
• 約10年後、現在、テクノロジーベース全体が変化しているため、業界にとどまる人は、初心者と同じくらいの時間を過ごすことができます。

最後に、アンソニーブレイクが指摘するように、時間、コスト、品質という3つの要素が常にあります。
関連する表現が好きです： "pick 2"！

皆の経験が異なるため、これについて多くの意見があります。

私が遭遇する開発者の約半数は、十分に意図されていますが、平均的な能力を持っています。最上部には優秀な人々の小さなグループがあり、最下部には小さなグループがありますが、実際にはそれを取得できないため、基本的に他のことを行う必要があります。残念ながら、彼らは他の誰よりも賢く、通常どのように彼らに従うべきかについてかなりあなたの顔をしていると思う無能な愚か者の別の小さなグループもあります。

プロジェクトに関しては、私は多くの仕事に就き、確立されたプロジェクトをすぐに「面倒に見る」ように頼まれました。私は通常、あなたが上で概説したものを正確に見つけます-文書化されていない、過剰に設計された、バギースパゲッティ。時々私はそれを修正することができます、時々私はちょうど再び始めます。古いコードである必要はありません。これは、「助けて」と頼まれた新しいプロジェクトでも見つかりました。

ほとんどの企業がインターンに安っぽい仕事を与えようとしているという事実から心をとらなければなりません。楽しいものは、次の2つのことを行った後に表示されます。1-自分自身を証明し、2-他の人の間違いを修正する以外のことに取り組む時間を作りました。言い換えれば、あなたは能力とイニシアチブを示さなければなりません。

不正なコードを処理するための本当のトリックは、何が回収可能か、何が回収不可能かを把握することです。これは経験と研究から来ています。

あなたが持っている他のキャリアオプションは、確立された企業での仕事をやめ、スタートアップで働くことを検討することです。そうすれば、維持するためのくだらないレガシーコードがなくなるので、より良いものを構築するのに役立つ機会が得られます。欠点は、多くの場合、スタートアッププロジェクトに配置するというプレッシャーにより、ショートカットとハックが使用されるべきではないときに使用されることです。

プログラマーは、早期または期限内に納品するために、多くの場合、技術的負債を引き受けます。残念なことに、この技術的負債の影響は、手遅れになってトラブルに陥るまで、開発者と管理者によってしばしば無視、最小化、無視、または却下されます。

これが気のめいるようであればごめんなさい。他の誰かがもっとポジティブな作品を作れると確信しています。:-)

ここには素晴らしい答えがいくつかありますが、少しだけ追加します。

現実の世界へようこそ-残念ながら、これは非常に一般的です。

以下の図を参照してください。

企業用ソフトウェアでは、2つ以上を選択できますが、1つを犠牲にする必要があります。

あなたが発見したように、企業の世界の大部分はスピードと価格で行きます。

業界を完全に示すものではありませんが、5年以上の限られた経験からです。私はあなたのインターンシップを通して働き、経験からできる限り多くのレッスンを受けます。特徴とインジケータを探してください。たとえば、次のポジションでは、間違いなく一連のインタビューを受ける必要があります。このプロセスは双方向の道であり、会社の雰囲気をつかむ機会を与えてくれます。これは非常に重要であり、おそらくあなた自身の幸せと幸福につながります。

要約すると、物語の兆候を見つけてください。

• 会社を運営しているのは誰ですか？単一のマネージャー、マーケティングチーム（もしあれば）、開発チームなどです。この角度は、プロジェクト、プロジェクトに費やされる時間などに多かれ少なかれ活用できることを意味します。
• 技術的な評価はありますか？経営陣、監督者、チームのメンバーがお互いをどのように扱っているかを見てください。テクニカルリーダーが話し始めた後、マネージャーがあらゆる種類の眉の動きを行っているインタビューに参加しました。その後、彼らはソース管理を使用しなかったことを学びました-あなたは私に十分に速くドアを見せることができませんでした。
• ビジネス目標？会社は、毎日の財務目標のように毎日住んでいますか、それともあなたが所属している長期計画を持っていますか。ソフトウェア開発は一般に数か月にわたって行われるため、統合失調症の性質を持つ会社を持つことは通常、厄介なソフトウェアにつながります。
• 技術的な質問をし、人々がシャッフルするかどうかを確認するときは、深く掘り下げてください。ソース管理、ドキュメント管理、リリースプロセス、バグレポート、管理スタイル、T＆Cなど

生きて学び、次の役割について考えてください。あなたが仕事とビジネスの世界についてよりよく教育されるので、悪い経験をすることはそれほど悪いことではありません。

まあ、私はビジネスの中で二十年目を迎えていますが、完璧なクリーンなコードはめったに起こらないこと、そしてそれが起こったとき、それは長くは続かないことを伝えることができます。概して、過去の過ちを修復しようと絶えず努力している一方で、（残念ながら）時間の制約と貧弱なリーダーシップによって現在の過ちを犯すことを余儀なくされています。

特定の種類のソフトウェアビジネスに携わっていない限り、機能的な製品を世に出すというプレッシャーは他のすべての懸念事項を無効にし、特定のポイントを超える最適化は無意味と見なされます。プログラムが5分で実行され、5分で実行する必要がある場合、ランタイムを2分に短縮するために数週間を与える人はいません。

、いくつかの奇跡によって、あなたは有能な管理の完璧な合流、明確な目標、お金、才能、そして時間を持って、そしてあなたがきれい、superiour製品を製造する場合は、あなたがあれば...それはそのように滞在する唯一の方法はあるに触れたことがありませんもう一度。メンテナンスと延長はほとんど常に非常に低い優先度が与えられ、変更は事実上ゼロ通知で常に必要であり、最終的に不規則に整理されます。

昨日、このプロジェクトについて考えていました。それは私にとって非常に明白な夢想であり、本当に機能性の低い部分をドアから跳ね返しました。私はそれを時間と資源の無駄だと考えました。

まあ、驚き、驚き、誰もがそれを愛し、それはうまくいった。だから私は図面に戻って、それを正しくやった。そして、新しいバージョンは素晴らしかったです！しかし、その後、経営陣の離職があり、「新しいビジネスの方向性」を支持してすべてが廃棄されました。

2回目のイテレーションでは、会社内での展開が本当に中途半端であり、それについて別のことを聞いたことはありません。予定よりほぼ2年遅れています）、どうやら決して壊れることはありません。

これが私の最後のポイントです。奇跡的な何かを生み出したとしても、それが非常にうまく機能するという事実は、誰も少なくともそれに慣れていないことを意味し、それが壊れたとき（通常、彼らは愚かなことをしたから）、彼らはあなたの名前を彼らより悪く呪います火曜日の3分の1ごとに壊れるようなことを書いたバカを呪うことはありません。

あなたが恐ろしく低品質のコードだと考えることを伝えるのは難しいですが、ええ、非常に良いプログラマーは（定義により）ほとんどありません。ソフトウェアが進化するにつれて、人々は間違いを犯します。時間の経過とともにこれらが蓄積され、ビジネス上のプレッシャー（およびプログラマーの怠iness /無知）によりリファクタリングが行われます。

皆のために本当に話すことはできませんが、ここに私が言うことができるものがあります。

私はドメインで30年以上働いていませんが、いくつかのことを言うのに十分見ました。プロジェクトには、人間に似た生涯があります。初期設計は、20年の開発の後、1つのプロジェクトを言う現在のニーズに適合しない場合があります。そうは言っても、多くの人がそれを台無しにしたコードを変更し、最初は不可能だったものを追加しました。

レガシープロジェクトやかなり古いプロジェクトでcodeいコードを想像するのは、それほど難しくありません。誰もが初期設計を完全に理解することを期待することはできません。それは悲しいですが、それはそうです。

とはいえ、レガシープロジェクトのリファクタリングは常に可能とは限らず、時には望まれないこともあるということを覚えておく必要があります。私が働いていたプロジェクトの代替品を開発している会社で働いていました。新しいプロジェクトよりもうまく機能するのではないかと恐れて、プロジェクトのリファクタリングを許可しませんでした。このプロジェクトが新しい新鮮なプロジェクトよりもうまく機能する方法はないと確信しています。フレーズは、「改善しないで、機能させるだけ」のようなものでした。

最終的には、私がよく読んだり聞いたりするので、そのようなプロジェクトはあまりありません。大企業ではなく、スタートアップと仕事を見つけようとするべきです。スタートアップは非常に興味深いものであり、あなたが望むように進んでいないことがわかった場合、最終的には早く進むことができます。

また、できることの1つは、私は本当に何も約束しませんが、コードが本当にそんなに悪く、リファクタリングが必要だと感じたら。チームと共有してください。そのいコードを書いた人々があなたと一緒に働いているかもしれないことに留意してください。人々の気持ちを傷つけることではありませんが、あなたが取り組んでいるプロジェクトがしばらくして崩壊し、人々がそれを改善するのではなく、それが何をするかを理解するのにより多くの時間を費やすことに気づいたら。問題を自分で保持するよりも、問題を話し合って伝える方が良いでしょう。運がよければ、プロジェクトをリファクタリングすることになります。

プロジェクトをリファクタリングすることになった場合、悪いデザインの選択に対して指摘された人になるかもしれません！そして、リファクタリングがそれほど頻繁に行われない理由を理解するかもしれません。チーム全体がリファクタリングする必要がある場合、誰も指摘されないことを願っています。彼らは皆を解雇します=）

この質問に対する答えを簡単な引用で要約しようと思います。

All code turns to crap given enough time and hands.

残りは単なる物語です...

コード品質は主に2つの要因に依存します。

最初は常にお金です。高いサバイバルプレッシャーを持つ企業は、通常、低賃金を支払い、経験の浅い開発者を雇い、スケジュールが厳しく、開発者を活用する時間もお金もありません。

第二は人です。まず、予算を決定する人は、コード品質への支出を選択する必要があります。次に、彼らはそれを「生き」たい人を引き付けなければなりません。ご想像のとおり、50歳の有給のトップダウンDelphiプログラマー（ステレオタイプ化の意図はない、申し訳ありません）をCIビルドとプロデュースを行う最新のJava開発者に変えるのは難しいかもしれません疎結合コード。多くの開発者は、（おそらく若い）仲間によるレッスンを嫌い、池で釣りをしている人や、玉座をガラガラ鳴らしている人が嫌いです。

とはいえ、すべての会社の隣にレガシーコードがあるという事実を考慮すると、実生活でその多くを取得できると思います。あなたができることは、ボーイスカウトのように振る舞うことです。森に行き、ゴミを拾ってきれいにしてください。次回は、ステップスルーする混乱が少なくなります。

予算のあるコードへようこそ！管理が開発を早急に、計画せずに、そしてコーナーを切って行わなければならない場合、大きな違いがあります。大学で最初のプログラミングの仕事を辞めたとき、私は実世界の衝撃の同様の経験をしました。ドキュメントなし！時間が経つにつれて、私は多くの時間を学びましたが、正式なドキュメントを書いて最新の状態に保つのは時間の無駄です。幸運なことに、それは素晴らしいチームでした。それは彼が何をしているかを知っていた男が率いており、他のチームメンバーは正しい方法でコードを書くことに本当に関心がありました。それ以来、私の経験はあなたのものに似ています。多くの恐ろしいコード、多くの悪いコード、多くの無知な「開発者」。優れた開発者には、100人の悪い開発者がいるようです。

あなたは永遠にあなたの仕事を憎む運命にありません。あなたは、少し前もって投資することをいとわない長期的な利益を認識するのに十分賢い会社を見つける必要があります。私は、最速の方法ではなく正しい方法で物事を行うことが有益であると証明することができました。時間が経つにつれて、スパゲッティコードは修正されるか廃止され、コードが引き継がれます。妥協する準備をしてください。何かをプログラミングする最もクールな、または最も堅牢な方法は、単にやり過ぎである場合があり、迅速で汚い方法でそれを行うことは問題ありません。

大手ソフトウェア会社の1つでインターンシップを受けました

すべての企業が同じというわけではありません。ほとんどの企業には、安っぽいチームと安っぽいソフトウェアコードベースがあります。しかし、優れたチームと優れたコードベースも見つけることができます。

Solarisのスタッフは、大企業で見られるコードベースの種類について非常に素直で正直に説明したと思います。http：//hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

これまで毎日仕事を嫌う仕事を辞めてきましたが、これが私の人生の残りの部分であるかどうかを必死に知りたいです。

いいえ、私は15年以上コーディングしてきましたが、今でも気に入っています。

それはすべてが完璧だったと言っているわけではありません。私はいくつかの恐ろしいコードベースと素晴らしいものを見てきました。トリックはあなたにぴったりの場所を見つけることです。

大企業は小企業とは大きく異なります。同じ会社のチームAの中では、チームBとは非常に異なる場合があります。あなたにとって適切なバランスのとれたチームを見つけてください（例：やりがいのあるプロジェクト、楽しんでいる文化、良い給料など）

幸運を！

あなたと同じようなものを見てきました。それが発生した場合、私は2つの事例を経験しています。

1. 開発がプロジェクト主導型すぎる場合。重要なのは、機能を時間通りに提供してからサインオフすることだけです。次の変更は、新しい予算を持つ他のチーム/プロジェクトマネージャーによって行われます。
2. 長期間にわたって少数の人々がソフトウェアの一部を保守している場合、開発者はとにかくソフトウェアの一部を知っているため、怠け者になる傾向があります。学問の原則は遠く離れています。

それは悲しいですが、それはいくつかの場所でそれがそうである方法です。

少しでも良い変更を加えられるか、それに慣れるか、別の会社に変更して、インタビューでコードを選別するように依頼できるかどうかを確認してください:-)

これは簡単な答えになるでしょう。

教育は、資格と理想主義を感じるのに非常に役立ちます。これは良いことであり、理想主義を維持しようとする必要があります。

あなたがすべての目的であり、あなたが将来自分の仕事を振り返ることができるなら、それは非常に充実した経験にはなりません。自分に嘘をつくか、何も学ばない限り、あなたは自分がしたことを改善するための多くの方法を見ることになるでしょう。

一般に、全世界はあなたの周りでこれを行っています。したがって、過去の仕事を見ると、例外は別にして、劣っていて改善が必要なように見えます。あなたがこのように感じないなら、それはあなたが間違った仕事をしている、またはその支払いがあまりにも良いことを意味します。

良いニュースは、他人の間違いや過去との比較から利益を得ることができるということです。すべてのアプリケーションが正常に機能し、保守が容易であれば、新しい開発者は必要ありません。私の意見では、他のデベロッパークラフトをメンテナンスすることは有用な学習経験であり、すべての青空デベロッパーにとって必須のトレーニング要素となるはずです。

あなたのネガティブな経験は、あまりにも典型的な有名な有名ブランドの会社であり、多くの開発者は、彼らが最初に働く機会を得たときよりも多くの注意と不安を持ってアプローチすることを学びます。基本的に、管理の層が多ければ多いほど、平凡なものが支持されます。中間管理職は、コードの品質について上位管理職に報告しません。彼らはX時間で提供される機能について報告し、neato UI機能のパワーポイントプレゼンテーションを提供します。1か月後にすべてが崩壊した場合、それは通常他の誰かの問題であり、彼らはそれを知っています。

そう、そう、そのような場所の生命である開発者はあまり気にしない傾向があります。彼らが生き残ったなら、彼らはそこで生き残れませんでした。シリコンバレーの話を聞いたことがあります。もしあなたが怠け者になりたければ、有名人の一人のために働いてください。エキサイティングな仕事が必要な場合は、まだ一般的な名前ではない最近のスタートアップを探してください。私はシカゴで働いており、ここで同様の現象を保証できます。

一般的なルールとして（多くの例外はあると思いますが）、小規模であり、コードを書き続けている人々が管理または所有している企業では、品質の高いコードを高く評価しています。多くの場合、報酬は少なくなりますが、私の意見では、仕事のほうがはるかにやりがいがあります。

入門レベルの開発者として、最初は誰のために働くかをあまりコントロールすることはできませんが、履歴書に1年以上名前を付けると、リクルーターと人事担当者は間違いなく興奮します。また、最初の6か月かそこらで完全にひどい人のために働くことを学ぶのではないことをかなり学ぶことができます。また、実際にどのベストプラクティスが重要で、どのテクノロジーが単なる技術であるかを把握するのにも役立ちます。流行。

そしてもちろん、より多くのメインストリームの一般的な企業ツールを使用する場合、才能レベルの中央値はかなりぎこちないことに気付く傾向があります。主なスキルがJavaとC＃の組み合わせである場合は、視野を少し広げてください。Erlang、Python、または：o JavaScriptを作成している中間レベルで、より幸せなニッチを見つけることができます。

誰にも違うことを言わせないでください。続行する方法については選択肢がないかもしれませんが、がらくたのコードは高価です！@＃$ ing。

インターンシップに焦点を当てた質問。私はプログラミングをしたことがありませんでしたが、ラジオ局でインターンをしました。

また、インターンシップ中の経験についても質問がありました。あなたのインターンシップの経験とこれまでに受け取った答えはすべて、私の27年のソフトウェア作成（1985年6月中旬開始）後の私の経験をまとめたものです。

私たちのインストラクターが実際にコードを書くことよりも思考があると言ったとき、私は学校でそれを全く信じませんでした。彼らは正しかった。そして、あなたが誰か他の人のコードを見つけようとしているなら、コメントなしではさらに悪くなり、コメントでも同じくらい悪いです。コメント、ドキュメント、正式なビルド、およびソースコード管理のない、独自の地方税徴収システムを維持してみてください。

標準的な注文に直接違反することなく、あなたがうまくやれるときはいつでも、うまくやれ。許可を与えずに直接命令に反するよりも、許可を求めなかった何かをしたことを謝罪する方が簡単です。

学校で教えられた基準を忘れないでください。役に立たないわけではありませんが、これらの標準は微積分の制限の漸近線です。あなたはいつでも彼らにアプローチしようとすることができますが、彼らの価値に達することは決してないかもしれません。

幸運を。