卒業生の期待と現実
私たちが勉強したいことを選択するとき、そして私たちのキャリアと生活をどうするか、私たちは皆、それがどのようになるかについていくつかの期待を持っています。私はこの業界に10年近くいるので、プログラミングワーキングライフはどのようになるのか（コンピュータサイエンスを勉強していたときのこと）とはどういうことか、そして実際にはあります。
私の最大の2つのショック（つまり、期待が満たされていません）は、ソフトウェアに関わるメンテナンス作業の膨大な量と、専門性の欠如です。
メンテナンス：ユニでは、ソフトウェア作業の大部分は既存のシステムのメンテナンスであると私たちはみな言われました。だから私はこれを抽象的に期待することを知っていました。しかし、これがどれほど圧倒的なものになるかは正確には想像もできませんでした。多分それは私が精神的に艶をかけられたものであり、そして私がもっと最初からクールな新しいものを構築することを望んだ。しかし、実際には、ほとんどのジョブが圧倒的にメンテナンス、バグ修正、およびサポート指向であることが事実です。
プロフェッショナリズムの欠如：ユニでは、商用ソフトウェアの作業は非常にプロセス指向で厳格に設計されているという印象を常に持っていました。 ISOプロセスの画像、一連の技術文書、厳密に文書化されているすべての機能とバグ、そして一般的にプロフェッショナルな環境がありました。ほとんどのソフトウェア会社は、大規模な学期の長いプロジェクトに取り組んでいる学生のチームと同じように活動していることを理解することは大きなショックでした。そして、私は小さなアジャイルハックショップと中規模の企業の両方で働いています。常に「専門的でない」とは言えませんが、ソフトウェア業界（全体として）は、私が期待していた強力なエンジニアリング分野とはかけ離れているように感じられます。
他の誰かがこれに似た経験をしましたか？私たちの職業についてのあなたの期待は、現実とどのように異なっていましたか？
私はあなたの男を感じます。実際、私は1年ほど前に卒業したばかりで、私の最初の求人に飛びついて、私の人生で最も大きな衝撃を受けました。
期待していなかったこと：
学校のストレスと仕事のストレスは同じではありません-迫り来る論文の締め切りや特別なプロジェクトの防御であっても、友達と一緒に学校のプロジェクトに取り組む、または一人で仕事をするストレスは、一見無理な作業の締め切り、コミュニケーションの問題（オフィスの政治のほんの一部）、そして慌ただしい時間。
ベストプラクティスの欠如-プロフェッショナリズムの経験と同じです。私は最初の仕事に就く前とトレーニング期間中に、プログラミングとソフトウェアエンジニアリングの両方のベストプラクティスのレビューと読書を急いで行いました。これらは、非現実的であり、公平に言うと、実用的な理由のために必要なだけではありません。そして、時には、あなたの知識は、未知のものを単に恐れてこれらの慣行を軽蔑して扱う他の人に対してほとんど数えません。
彼らが学校で教えたことは氷山の一角にすぎませんでした-自習やクラスで学んだことで十分だと思っていたので、私はじっと見つめていたので、最低限言ってショックを受けました私が維持することになっていた最初のコード。私が現在使用しているスキルの多くは、仕事で、または仕事中に学んだので、大学の学位がなくてもそれを成し遂げることができるのかどうか疑問に思っています。 XD
コミュニケーションの重要性-これらの英語のクラスが何のためにあるのかを理解させられました。実世界の前は、1年生の時から教えられていた大学で3〜4つの異なる英語のクラスを持つことの妥当性を理解できませんでした。コンピュータと話すことができるが、人と話すことができないとき、あなたは仕事で無駄です。
あなたがする仕事のほとんどは画期的なものではありません
ユニでは、AIルーチンでサッカーロボットを制御したり、コンパイラを作成したり、オペレーティングシステムカーネルにハッキングしたりしました。
しかし、現実の世界では、99％* ソフトウェア開発の実際にはかなり退屈です。私は、「生活のために何をしますか？」と尋ねられた建築家や建築家を常に賞賛してきました。建物などを指し示して、「私がしたthat "と言うことができます。しかし、ほとんどのソフトウェア開発者はそれを行うことができません。 「生計を立てるために何をしますか？」私が今までこれまでにできたことに最も近いのは、SMSラジオ局などのメッセージを処理するソフトウェアを構築した会社で働いていたときです... 、「あなたがラジオ局にテキストで投票して曲に投票するとき、私はそれらの投票やその他のものを処理するソフトウェアを書いた。」建物を指し示すことができて、「私が作ったそれ。"
もちろんある「私はWindowsで作業した」などと言える人もいますが、次の質問が「私にはできる」と恐れて、実際には誰にも言わないでしょう。 tプリンターを動作させるには、それを修正してくれませんか？」
* すべての統計の62％がその場で構成されています
今日のソフトウェアをエンジニアリングの歴史のレンズを通して見ると、それは確かに一種のエンジニアリングですが、Archの概念を持たない人々が行ったようなエンジニアリングです。今日のほとんどのソフトウェアは、何百万ものレンガが積み重ねられたエジプトのピラミッドに非常によく似ており、構造的な完全性はありませんが、力ずくで何千もの奴隷によって作られています。 -アラン・ケイ、2004
完全なインタビュー： http://queue.acm.org/detail.cfm?id=103952
私は業界の獣医ではありません。正反対のことですが、私は最近の卒業生ですが、米国でトップのCSスクールを卒業していますが、ソフトウェアを構築する方法が間違っているという本能的な感覚があります。一時停止ボタンをクリックしてプログラムの基本を再検討するのではなく、50年代、60年代の古いモデルを使用して、前から少しずつ砂糖を追加し続けました。私たちがこのように続ければ、私たちは今いるところを通り抜けることは決してないでしょう。人間は、MS Windowsコードベースのサイズであるものの複雑さを管理できません。新しい方法が必要です。それが何かわかりません。
これが、大小のソフトウェアショップが、基本的な原理を深く理解せずにソフトウェアをハッキングして一緒にソフトウェアを作っているように見えるという根本的な理由だと思います。
- 開発は主にチームワークです。つまり、コミュニケーション（口頭で読む）、他の人のコードを読む、以前のモジュール（社内と社外の両方）を再利用することは、ほとんど毎日直面することです。私の大学では、少なくとも、ごく少数の場合に、より多くの人とコーディングする必要があったので、作業の主な部分は、荒野で一人でコーディングすることだと思いました。そうではない。
- 開発者以外に説明するのは難しい（最初のポイントについてもカバーされています）、そしてあなたのポイントを作る責任があります（他の99％の世界ではありません）。
- 良いテストは失敗したテストです。（少なくとも、初めて）そしてもちろん、バグのないコードなどはありません。バグがあれば、あなたは悪いプログラマではありません。バグはあなたの仕事の（非常に重要で時間がかかる）部分にすぎません。
- 特効薬はありません。各テクノロジーには、それぞれ長所と短所があります。
- カレッジは最先端のテクノロジーを教えていません。また、作品の90％はかなり古いテクノロジーを使用しています。ちなみに、これが必要な場合もあります。
- 非技術者が技術的な解決策について決定を下す、主に保守、パートナーシップ、労働者の可用性などの難解な理由で...
- あなたは始まったばかりです、若いパダワン。
それ以来、コーディングはより多くの人々と協力して行う作業であるという事実について、特にオープンソースがより目立つようになったことに気づき始めました。しかし、私が大学（90年代後半）にいたとき、私は物事をゼロから行うつもりで、他の人のコードを調べたり、他の人と調整したりする必要はないと確信していました...
振り返ってみると、私にとって最良の部分の1つは学習および他の人に教えるです。
学位は取れませんでしたが、大学の図書館や研究室で少しピックアップしました。
Big Iron-彼らが教えていたテクノロジーは、主にメインフレームとミニコンピューターでした。ある大学の学部長から、マスターファイルが何なのかさえわからなかったので、就職できないと言われました。メインフレームを買う余裕がなかったので、メインフレームに取り組むつもりはありませんでしたが、少し準備ができないほど愚かになることはありませんでした。 VAXenはクールで、自分のキュービクルにある自分のMicro VAXのコードに支払われるのを楽しみにしていました。市場が完全に破綻したのはなんて残念なことでしょう。 （結局のところ、IBMの請負業者として、メインフレームを扱う2つのポジションがありました。）
ソフトウェアエンジニアリング-構造化プログラミング、SASD、およびその他の設計方法論に続いて、私たちが実際のエンジニアになると思っていたかもしれません。やった。しかし、先生たちが私が図書館で読んだデザイン手法についてはほとんど指導をしていませんでした。学生たちは自分で対処することを余儀なくされ、マイクロは、彼らが満足する答えを得るまで、コードで簡単に失敗することができました。それが求人市場でどれほど悪いかは知りませんでした。どういうわけか、私はかなりの量の新しいコードを実行する必要があったので、それほど退屈ではありませんでした。しかし、私もたくさん引き継ぎましたが、それらは多くのコードを修正しなければならなかったので、それは新しいプロジェクトのようでした。これは、既存の機能の調査と新しいコードの作成（その置き換え）の組み合わせでした。プロセスを簡素化し、より良いプロジェクト管理を導入するためのツールの作成。
ハイテクキャリア-学校に古い建物と設備がある場合（パンチカード設備は、開始前に1984年に交換されました...）が、薄暗い倉庫で作業している場合または、サポートラインに電話をかける顧客に電話を切る上司にとって、あなたの仕事の説明には5メガワットのレーザーを備えたポップコーンの調理は含まれそうにないことに気づき始めます。
- コンピュータプログラミングは、物理的でなく、直感的ではありません。
- 家を建てる人が仕事を終えたら、歩き回ってすぐに何か問題があるかどうかを見て、感じます。コンピュータプログラミングのバグは同じ方法で発見することはできず、システムに数か月、場合によっては数十年も潜んでいる可能性があります。
- プログラマーはコードレビューを通じてソースコードの一部を見て/感じるかもしれませんが、コードに含まれるすべてのエラーを特定することは保証されていません。ただし、コンピュータは、特定の入力でプログラムを実行することにより、毎回正確にエラーを再現できます。したがって、ソースコードの一部に対する人間の理解は、常にそれがコンピュータへの命令であるという本質の不完全なモデルです。
- 最も一般的なケースを処理するプログラムをコーディングするのは非常に簡単ですが、エッジのケースを完全に処理することはできません。
- 他の分野では、事後的に是正措置を適用することは比較的簡単です。是正措置に特化した知識が含まれている場合もあります。ソフトウェア開発にはそのようなことはありません。
- さいわい、テスト駆動開発は、コードが処理するはずのEdgeケースを体系化するのに役立ちます。
- 追加一方、特定のソフトウェア開発方法論は、エッジケースを処理しないことを意識的に選択することでビジネス価値（市場投入までの時間の短縮など）を抽出し、それらの決定をお客様。
- お客様は、最も一般的なケースのみを処理するソフトウェアにビジネス価値を見出している可能性があります。したがって、ソフトウェアプロバイダーは、まれなケースの処理についてそれほど心配していません。
- 顧客は、荒削りな部分を避けることを学ぶだけです。
追加
- ソースコードの優雅さは評価されていません。
- 顧客はソースコードの優雅さを見ることはありません。ユーザーインターフェースとインタラクションの優雅さだけを目にします。
- 一方、プログラマーは通常、ユーザーインターフェースの優雅さを重視せず、通常、エレガントなソフトウェアデザインの評価を開始するのに十分な時間、単一のプロジェクトにとどまることはありません。
- 顧客もプログラマーもソースコードの優雅さを高く評価していないため、企業もそれを高く評価していません。
追加
私の2セント：慣れるだけです。
ISOプロセスの画像、一連の技術文書、厳密に文書化されているすべての機能とバグ、および一般的にプロフェッショナルな環境私の会社をかなりよく説明しています。ただし、重要なインフラストラクチャソフトウェア/ハードウェア製品を扱っているため、品質への圧力はonです（たとえば、ISO 9001の認定を受けています）。
卒業後、担当者は良い仕事と悪い仕事を区別できると思いました。 「私たちのトップコーダーがまとめた本当に素晴らしいコード」の100万部目を手渡した後、次のようになります。
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
.
.
.
先のとがった髪のボスの耳の間で何が起こっているのかを理解しようとするのをほとんどあきらめました。 「素晴らしい」は維持の悪夢を意味し、「良い」は穏やかなそよ風でのクラッシュを意味し、「恐ろしい混乱」とは、その健全性を維持するためにエンジニアがわいせつな期限を守ることを明らかに拒否している、よく構造化されたコードベースのいずれかを意味します。
多くのソフトウェアは、十分に使用/購入できるようになりません。それを作るとき、それは固執する傾向があり、メンテナンスでのみ「混乱」します。
機能に対するユーザーの期待は日々高まっていますが、多くの分野でエンジニアリングの分野ではそれよりも低くなっています。銀行取引ソフトウェアが、現代の自動車と同じくらい堅固で専門的に設計されているとしましょう。ボリュームの処理は現代の驚異ですが、各トランザクションの信頼性についてはどうでしょうか。それほどではありません。あなたの子犬が敷物の上で最初のがらくたについてのあなたの投稿は落とされました、それで何ですか。それは、食料品店の小さなビニール袋のようなものです。彼らは何十億もの彼らを作り、引き裂き、引き裂かれ、捨てられます。ほとんどの人はより良いバッグを要求するのに十分気にしていない。
最終的には高品質なソフトウェアが作られると思います。その一部は、ほとんどの市販製品よりも早く市場に出回っています。ベータで車を運転するのは誰ですか？
コードの最初の行の後のすべてのソフトウェアエンジニアリングは保守であると主張したと聞いています。そして、それは確かに私の経験と一致しているようです。私が書いた唯一のコードは、コストのほとんどを維持できなかったため、失敗したために使用されなかった、または一時的にしか使用されなかったコードでした。
強力なプロセスを開発および実行して、チームが高い信頼を得られる強力なコードをリリースする、規律のとれたエンジニアリングチームを見つけることができると思います（ただし、大量のドキュメントでそれについては説明しません）。今はそのようなチームで働いていると思います。私は確かに他の種類の開発を経験しましたが。
しかし、私が高く評価するようになったのは、課題は必ずしも完璧なアルゴリズムや問題に対する最もクリーンなソリューションを見つけることではないということです。しかし、あらゆる種類の制約（リソース、知識、お金、時間、スキル、リスク、既存のユーザートレーニングなど）をトレードオフして、利用可能な投資の最高のリターンを達成することがよくあります。それは、技術的な影響だけでなく、それらすべての要因に最も適したシステムを構築することです。