卒業予想と現実[終了]

私たちが勉強したいものを選択し、私たちのキャリアと人生をどうするかを選択するとき、私たちは皆、それがどのようになるかについていくつかの期待を持っています。ほぼ10年間業界に携わってきた今、私は（コンピューターサイエンスを勉強していた頃の）プログラミングワーキングライフがどのようなものになるのか、実際にどうなるのかについて少し考えてきました。あります。

私の2つの最大のショック（または、期待を裏切る）は、ソフトウェアに関わるメンテナンス作業の量が非常に多いことと、プロフェッショナリズムの全体的な欠如です。

1. メンテナンス：uniでは、ソフトウェア作業の大半は既存のシステムのメンテナンスであると言われました。だから私は抽象的にこれを期待することを知っていた。しかし、これがどれほど圧倒的であるかを正確に想像することはできませんでした。おそらくそれは私が精神的にmentalめたものであり、私はもっと多くのクールな新しいものをゼロから構築することを望んでいました。しかし、実際には、ほとんどのジョブは、圧倒的にメンテナンス、バグ修正、およびサポート指向です。

2. プロフェッショナリズムの欠如：大学では、商用ソフトウェアの仕事は非常にプロセス指向であり、厳密に設計されているという印象が常にありました。ISOプロセスのイメージ、一連の技術文書、すべての機能とバグが厳密に文書化され、一般的にプロフェッショナルな環境がありました。ほとんどのソフトウェア企業が、学期規模の大規模なプロジェクトに取り組んでいる学生チームと同じように運営されていることに気づいたのは、大きな衝撃でした。そして、私は小さなアジャイルハックショップと中規模の企業の両方で働いてきました。私はそれが常にあからさまな「非専門的」だとは言いませんが、ソフトウェア産業は（全体として）私が期待していた強力なエンジニアリングの規律とはかけ離れているように感じます。

他の誰かがこれに似た経験をしましたか？私たちの職業がどのようになるかについてのあなたの期待が現実と異なっていた方法は何ですか？

私はあなたを感じます。実際、1年ほど前に卒業したばかりで、最初の求人に飛びついて、私の人生で最大の衝撃を受けました。

私が期待していなかったもの：

学校のストレスと仕事のストレスは同じではありません -迫っている論文の締め切りや特別なプロジェクトの防衛であっても、学校のプロジェクトで友人と仕事をしたり、単独で働いたりするストレスは、一見不合理な仕事の締め切り、コミュニケーションの問題のストレスとは異なります、（少しの政治）とクランチタイム。

ベストプラクティスの欠如 -プロ意識に関する経験と同じ。最初の仕事に就く前に、そしてトレーニング期間中に、プログラミングとソフトウェアエンジニアリングの両方のベストプラクティスについて確認し、読むことを急ぎました。これらは、非現実的で、公平を期すために、現実的な理由で従うべきではありません。そして、時々、あなたの知識は、単に未知を恐れて、軽withをもってこれらの慣行を扱う他の人たちに対して非常に重要ではありません。

彼らが学校で教えたのは氷山の一角にすぎませんでした -自己学習と授業で学んだことは私をやり遂げるのに十分だと思い、最初のコードをd然と見つめながら控えめに言ってもショックを受けました維持することになっています。現在使用している多くのスキルは、仕事中または仕事中に学んだもので、大学の学位を取得しなくてもそれを達成できるかどうか疑問に思っています。XD

コミュニケーションの重要性 -これらの英語の授業がすべての目的であることに気づきました。現実の世界の前に、私たちが1年生だったので教えられたとき、大学で3〜4つの異なる英語のクラスを持つことの関連性を見ることができませんでした。コンピューターとは話せるが、人とは話せないときは、仕事で役に立たない。

あなたが行う仕事のほとんどは画期的なものではありません

Uniで、サッカーロボットを制御するAIルーチンに取り組み、コンパイラを構築し、オペレーティングシステムカーネルをハッキングしました。

しかし、現実の世界では、ソフトウェア開発の99％^*は実際にはかなり退屈です。「生計のために何をしますか」と尋ねられたとき、私は常に建築家や建築家を賞賛してきました。建物などを指して、「私はそれをやった」と言うことができます。しかし、ほとんどのソフトウェア開発者はそれを行うことができません。「生計のために何をしますか？」ラジオ局などのSMSメッセージを処理するソフトウェアを開発した会社で働いていたとき、私が今まで来たことのあるものに最も近いのは...歌に投票するためのラジオ局、よく私はそれらの投票やものを処理するソフトウェアを書きました。」ビルを指すことができて、「私はそれを建てた」と言うほどクールな場所はまだありません。

もちろん、そこにある「私はWindows上で働いていた」または何でも言うことができる人は、私は、彼らは実際には非常に次の質問の中「の恐怖のために、私は仕事に私のプリンタを得ることができないことを誰にも教えていないと確信しています、私のためにそれを修正できますか？」

^*およびすべての統計の62％がその場で作成されます

今日のソフトウェアを見ると、エンジニアリングの歴史のレンズを通して、それは確かに一種のエンジニアリングですが、それはアーチの概念を持たない人々がしたエンジニアリングの一種です。今日のほとんどのソフトウェアは、何百万ものレンガが積み重なったエジプトのピラミッドに非常に似ており、構造的な整合性はありませんが、総当たりと数千の奴隷によって行われています。-アランケイ、2004

完全なインタビュー：http : //queue.acm.org/detail.cfm?id=1039523

私は業界の獣医ではありません。まったく逆に、私は最近卒業しましたが、米国のトップCSスクールから来ましたが、私の直感的な感覚は、ソフトウェアの構築方法が間違っているということです。一時停止ボタンを押してプログラミングの基本を再検討するのではなく、50年代、60年代の時代遅れのモデルを使い続けて、小さな砂糖を絶えず追加していきました。このように続けると、私たちは今いる場所を決して通り抜けることはできません。人間は、MS Windowsコードベースのサイズの複雑さを管理することはできません。新しい方法が必要です。それが何なのか分かりません。

これは、大小のソフトウェアショップが基本的な原理を深く理解せずに一緒にハッキングすることでソフトウェアを作成しているように思われる根本的な理由だと思います。

学位は取得しませんでしたが、大学や大学の図書館や研究室で少し学びました。

• Big Iron-彼らが教えていた技術は、主にメインフレームとミニコンピューターでした。ある大学の学部長は、私はマスターファイルが何であるかさえ知らなかったので、私は仕事を得ることができないと私に言った。メインフレームを購入する余裕がなかったので、メインフレームで作業するつもりはありませんでしたが、少し準備ができているほど愚かなことはしませんでした。VAXenはクールで、キュービクルで自分のMicro VAXのコードにお金を払うのを楽しみにしていました。市場が完全に崩壊したなんて残念なことだ。（判明したように、メインフレームで作業しているIBMの請負業者としてのポジションが2つありました。）

• ソフトウェアエンジニアリング -構造化プログラミング、SASD、およびその他の設計方法論に続いて、あなたは私たちが本物のエンジニアになると思っていたかもしれません。やった。しかし、教師は私が図書館で読んだデザイン手法についてほとんど指導をしていませんでした。学生たちは自分でやらなければならないままであり、マイクロスは満足のいく答えが得られるまでコードを簡単に手放すことができませんでした。雇用市場がどれほど悪いのか気づかなかった。どういうわけか私はかなり新しいコードをやることになったので、それほど退屈ではなかった。しかし、私も多くを引き継ぎました。そして、彼らは私が多くのコードを修正しなければならなかったので、それが新しいプロジェクトのように十分に悪かったです。これは、既存の機能を調査し、新しいコードを作成する（その代替）組み合わせでした。プロセスを簡素化するツールを作成し、プロジェクト管理を改善します。

• ハイテクキャリア -学校に古い建物や設備がある場合（1984年にパンチカードの設備が学期に取って代わられました... 1984年に）サポートラインに電話をかける顧客については、5メガワットのレーザーでポップコーンを調理することが仕事の説明に含まれていない可能性が高いことに気付き始めます。

• 開発は主にチームワークです。つまり、コミュニケーション（話したり読んだり）、他人のコードを読んだり、以前のモジュール（社内と社外の両方）を再利用したりすることは、ほぼ毎日直面することです。私の大学では、少なくとも私は非常に少ない機会でより多くの人々とコーディングしなければならなかったので、仕事の主な部分は荒野で一人でコーディングすることだと思いました。そうではない。
• 開発者でない人に物事を説明するのは難しく（最初のポイントもカバーしています）、あなたのポイントを作るのはあなたの責任です（世界の他の99％の責任ではありません）。
• 良いテストは失敗するテストです。（少なくとも初めて）そして、もちろん、バグのないコードというものはありません。バグがあれば悪いプログラマーではありません。バグはあなたの仕事のほんの一部（非常に重要で時間のかかる）です。
• 特効薬はありません。各テクノロジーには長所と短所があります。
• 大学はあなたに最先端の技術を教えません。しかし、作品の90％はかなり古い技術を使用しています。ところで、これは時々必要なものです。
• 非技術者は、主にメンテナンス、パートナーシップ、労働者の空室状況などの難解な理由により、技術ソリューションについて決定を下します...
• あなたはまだ始まったばかりの若いパダワン。

それ以来、コーディングはより多くの人々と連携して行う作業であり、特に今ではオープンソースがより顕著になっているという事実に気付き始めました。しかし、私が大学（90年代後半）にいたとき、私は他のコードを調べたり、他の人と調整したりすることなく、ゼロから物事をやろうとしていると確信していました...

振り返ってみると、私にとって最高の部分の1つは、他人を学び、教えることです。

• コンピュータプログラミングは非物理的で直感的ではありません。
  • 住宅建設業者が仕事を終えると、歩き回って、何か問題があればすぐに見たり感じたりすることができます。コンピュータープログラミングのバグは同じ方法で発見することはできず、システムに数か月、あるいは数十年も潜んでいる可能性があります。
  • プログラマはコードレビューを通じてソースコードの一部を見て/感じるかもしれませんが、コードに含まれるすべてのエラーを見つけることは保証されていません。ただし、コンピューターは、特定の入力でプログラムを実行することにより、毎回エラーを正確に再現できます。したがって、ソースコードを人間が理解することは、それがコンピューターへの指示であることの本質の常に不完全なモデルです。
• 最も一般的なケースを処理するプログラムをコーディングするのは非常に簡単ですが、エッジケースを完全に処理することはできません。
  • 他の分野では、事後的な修復アクションを適用するのは比較的簡単です。是正措置に特化した知識体系もあります。ソフトウェア開発にはそのようなことはありません。
  • 幸いなことに、テスト駆動開発は、コードが処理するはずのエッジケースを体系化するのに役立ちます。
  • 追加しました一方で、特定のソフトウェア開発方法論は、私たちが意識的にハンドルエッジケースにない選択することで、ビジネス価値（市場化までの時間短縮など）を抽出することができ、顧客にその決定を通信することを示唆しているように見えます。
• 顧客は、最も一般的なケースのみを処理するソフトウェアにビジネス上の価値を見いだす可能性があります。そのため、ソフトウェアプロバイダーは、まれなケースの処理についてあまり心配しません。
  • 顧客は、荒れたエッジを避けることを学ぶだけです。

追加しました

• ソースコードの優雅さは評価されていません。
  • 顧客にはソースコードの優雅さが見えません。彼らはユーザーインターフェースとインタラクションの優雅さだけを見る。
  • 一方、プログラマーは通常、ユーザーインターフェースの優雅さを重視せず、通常、エレガントなソフトウェアデザインの評価を開始するのに十分な時間、単一のプロジェクトにとどまりません。
  • 顧客もプログラマーもソースコードの優雅さを評価しないため、企業からも評価されません。

追加しました

私の2セント：ただそれに慣れてください。

ISOプロセスのイメージ、一連の技術文書、すべての機能とバグが厳密に文書化されており、一般的にプロフェッショナルな環境が私の会社をかなりよく説明しています。ただし、重要なインフラストラクチャソフトウェア/ハードウェア製品を提供しているため、品質に対するプレッシャーがかかっています（たとえば、ISO 9001の認証を受けています）。

卒業後、担当者は悪い仕事から良い仕事を認識できると思いました。「私たちのトップコーダーが組み立てた本当に素晴らしいコード」の百万番目のコピーを渡された後、それは次のようになります：

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

先のとがった髪のボスの耳の間で何が起こっているのかを理解しようとして、私はほとんどあきらめました。「素晴らしい」とは保守の悪夢を意味し、「良い」とは穏やかな風にクラッシュすることを意味します。

コードの最初の行以降のすべてのソフトウェアエンジニアリングは保守であると主張したと聞いています。そして、それは確かに私の経験と一致するようです。私が書いた唯一のコードは、そのコストの大部分が維持費にならないものでしたが、コードが非常に失敗したため、決して使用されなかった、または短時間しか使用されませんでした。

私はあなたがチームが高いレベルの自信を持つことができる堅牢なコードのリリースにつながる強力なプロセスを開発し、従う規律のあるエンジニアリングチームを見つけることができると思います（私はそれを大量のドキュメントで畳み込みません）。私は今そのようなチームで働いていると信じています。私は確かに他の種類の開発を経験しましたが。

しかし、私が感謝するようになったのは、課題は常に完璧なアルゴリズムまたは問題の最もクリーンな解決策を見つけることではないということです。ただし、多くの場合、あらゆる種類の制約（リソース、知識、お金、時間、スキル、リスク、既存のユーザートレーニングなど）をトレードオフして、利用可能な投資の最高の収益を達成します。それは、技術的な影響だけでなく、これらすべての要因に最適なシステムを構築しています。

多くのソフトウェアは、十分に使用/購入されるほどにはなりません。人がそれを作るとき、それは固執する傾向があり、メンテナンスでのみ「めちゃくちゃ」になります。

機能に対するユーザーの期待は日々高まっていますが、多くの分野では、エンジニアリングの分野では低くなっています。銀行取引ソフトウェアが、現代の自動車と同じくらい堅固で専門的に設計されていると仮定しましょう。ボリュームの処理は現代の驚異ですが、各トランザクションの信頼性はどうですか？そんなにない。子犬の敷物の最初のがらくたについての投稿は削除されました。食料品店の小さなビニール袋のようなものです。彼らは何十億もそれらを作り、裂き裂き、捨てられます。ほとんどの人は、より良いバッグを要求するほど気にしません。

最終的には高品質のソフトウェアが作られると思います。その一部は、ほとんどの商用製品よりも早く市場に出回っています。ベータで車を運転できるのは誰ですか？