重要なのは、ゾロフトを大量に摂ることだね。

時々、お金を最優先にして、$ENTERPRISEで給料の高い仕事を得て、十分貯金ができたら長期の休暇を取ることを考えることがある。でも、面接の儀式を乗り越えることを考えるだけで、すぐに気が萎えちゃう。今は$MIDSIZENOLONGERSTARTUPにいるけど、ここもまた自分を壊すような狂ったことがたくさんあるんだよね。

報酬は、実際にやらなければならない仕事の量に反比例します。

オープニングの「楽しさと金銭的利益」についての文も当てはまらない気がする。

「キャリア開発」って結局「もっとお金」ってこと？大企業だと大きなプロジェクトをリードするチャンスが増えるよね。大企業では、スタートアップの製品がそのまま社内で作られることも珍しくないし、環境によっては数年の間にいくつかのプロジェクトに関わることもある。もっと大きなチームをリードしたいなら、大企業の方が見つけやすいよね。 > でも、そのソフトウェアが悪かったり、多くの人に害を与える場合でも満足できるの？スタートアップや小さな会社に本質的に良いことはないよ。良いか悪いかはケースバイケースだね。

「キャリア開発」って結局「もっとお金」ってこと？そうなら「もっとお金を稼ぐチャンスがある」って言えばいいじゃん。そうじゃないなら、他の部分で述べられている様々な機能不全に埋もれていくこと以外の「キャリア開発」って何なの？人生では、よく考える人はみんな、私たちがもっと大きなシステムの中の小さなプレイヤーに過ぎない現実に直面することになる。これを考えると、「不公正な社会の中でどうやって公正でいられるか？」とか、「個人としてコミュニティに良い影響を与えるための最良の方法は何か？」とか、「自分の小さな役割の中でシステムを変えようとする意味はあるのか？」みたいな深い質問が出てくる。こういう質問には様々な反応や結果がある。ある人は、変化を促すために地元の政治や草の根運動、活動家として積極的に関わる。逆に、システムの重みに圧倒されて完全に disengage する人もいる。さて、君の質問に答えると、私たちがやっている仕事を信じてる（そうじゃなければ、たぶん参加してない）。会社でのキャリア開発は、単にお金が増えるだけじゃなくて（もちろんそれも一部だけど）、より多くの責任を与えられ、どんどん変化を実現できるようになることだよ。機能不全の組織にいるとき、君はどうする？私が考える選択肢は大体こんな感じ： - 会社を変える、そしてその機能不全が克服できないことを認める。 - 自分の仕事をして、今のポジションに留まる。 - 機能不全の組織にさらに深く埋もれ、ポジティブな変化のエージェントになれると考える。 > そのソフトウェアが悪かったり、多くの人に害を与える場合でも満足できるの？そういう人もいるよ。害を与えることに満足を感じる人もいる。でも、私はそうじゃないし、自分の仕事が害を与えているとは思わない。「社会にとってプラスになるソフトウェアを書くのは満足だ」って言わなきゃいけないほど細かく考える必要はないと思ってた。

「キャリア開発」って結局「もっとお金」ってこと？データサイエンスの研究者になりたいとか、開発者エバンジェリストになりたいなら、君の仕事を支えられる組織が必要だよね。マイクロサービスアーキテクトになりたいなら、小規模な会社ではブーイングされるけど、3000人の会社では歓迎されるよ。同じことがエンジニアリングマネージャーの道にも言える。人員がいないと意味がない。 > ソフトウェアが悪かったり、害を与える場合でも、君が取り組むものは必ずしもエンタープライズソフトウェアである必要はない。そうならないことを願ってる。

もしソフトウェアが「エンタープライズ」と表現されるなら、それはゴミだよ。安全基準が血で書かれているなら、エンタープライズソフトウェアは訴訟で書かれている。

... レミーの企業ソフトウェアの法則 ... 投稿の最後にある良い点のリスト。ブログ記事の投稿者と同じように、私も非常に大きな企業で働いていました。従業員20万人、サーバー1万台とかね…。幸運にも、CTOのサポートをして、数億ドルの企業ソフトウェアの購入決定に関わる機会がありました。ベンダーを次々とインタビューして、「大企業」に適合するかどうかを厳しくチェックしましたが、ほとんどはダメでした。彼らが盲目的に燃えながらジャンプしなきゃいけないカフカ的なハードルの話ではなく、要件はシンプルで、しっかりしたアーキテクチャの原則でした。彼らがそれを満たさなければ、彼らのソフトウェアは「小さなクライアントには十分良い」かもしれませんが、スケールでは絶対に機能しませんでした。メモから作ったリストはこんな感じでした：

1. LDAPやOAuthなどの外部ソースからのシングルサインオンをサポートすること。（私たちのディレクトリやユーザーパスワードをあなたの不安定なゴミソフトウェアに同期させるつもりはありません。）
2. 何らかの監査ログを持つこと。特に管理や設定の変更について。（ある場所では数百人の管理者がいて、全員が完全に信頼できるわけではありません。）
3. 無人インストールプロセスを持つこと。たとえそれがVMクローンでも。（日曜の午前3時にGUIウィザードを500回クリックするつもりはありません。）
4. 増分マイグレーション/アップグレードを許可すること。つまり、「簡単な」プロセスであるストップ・ザ・ワールド、一方向のビッグバン、スタート・ザ・ワールドは、10,000のテナントを持つ企業では実行不可能です。アップグレードが最初の試行で全員にうまくいくかどうかはわかりませんから。
5. スケール。これは「ユーザー」と「テナント」テーブルにインデックスを持つことのようにシンプルですが、通常の開発者は1ユーザー1テナントのスケールで作業しているため、見落とされがちです。同様に、コンボボックスやドロップダウンは、セキュリティグループなどのほとんどのフィールドでは使えません。（私たちは70万のセキュリティグループがあります。OOMエラーであなたのGUIがクラッシュしないように699,900を削除することはできません。）
6. アクセシビリティは必須です。最大20万人の常勤ユーザーと100万人の臨時ユーザーがいるため、すべての障害が表れます。視覚や聴覚の問題だけでなく、運動神経の問題や切断者なども…（あなたが名前を挙げれば、私たちのスタッフにはその障害を持つ人がいます。） などなど… そういう視点で見ると、企業ソフトウェアは理解できるようになります。バロック的でも悪意があるわけでもなく、目的に合わせた特定の形を取っているだけです。たとえば、なぜActive Directoryがすべての「ピッカー」GUIコントロールに検索ダイアログボックスを使用するのか、もっとシンプルなドロップダウンなどにしないのか理解できませんでしたが、ディレクトリに200万のオブジェクトがある環境で働くまでわかりませんでした。

企業ソフトウェアが定義上悪いとは思わない。良い企業ソフトウェアを作ることは絶対に可能だけど、そのためには多くの要件に従うスキルが必要なんだ。それに、企業のほとんどの人は、提供するソフトウェアがどれだけ使いやすいかについて評価されることはないから、あまり興味を持っていない。実際、彼らはソフトウェアを使っているユーザーを見たことがない。私は$ENTERPRISEに7年いて、ユーザーを訪れたのはたった1回だけだ。

• グループ名が何度目かの変更で、何年も経ってる。人は同じ仕事を続けるけど、部門名に「イノベーション」や「ディスカバリー」、「リーダーシップ」が追加されてる。時々、チーム名を「ピカチュウ」にしてそのまま働き続けたいって思う。そうすれば、他の人も名前なんてどうでもいいって分かって、名前変更をやめるだろうし。ドキュメントを変更したり、チーム名が変わったことを知らせるのにかかる手間が、本当に無駄な仕事を生んでるんだよね。

「エクセレンス」って名前のイニシアチブを見るたびに、これはクソだなって思う。

私たちは、Terraform CDKを使って構築した内部のインフラストラクチャ・アズ・コードライブラリを持っていて、DatadogやPagerDutyで監視リソースを自動的にプロビジョニングしています。ある日、必要な引数「team」を削除したら、それが7ヶ月の半減期を持つことに気づきました。

• 新しいリーダーシップが古いガードを追い出し、友人で置き換えるだろう。 私の宿敵は、新しいビジネスを始めるたびに、彼のヘルプデスクと開発チーム全体をゆっくりと連れてきます。これはクレイジーです。なぜなら、彼にとっての利点は単に忠誠心だからです。彼が成果を出せなかったとき、彼らは文句を言ったり、彼の上司に行ったりしません。彼が他のビジネスで働いていたスタッフからの証拠がありますが、彼は常に同じパターンを繰り返しています。

1. 問題を特定する（問題は大手マイクロソフトパートナーからの新しいCRMがないこと。）
2. 問題を解決するために多くのお金を使う（CRMパートナーとマイクロソフトのおかげで、年に3回の無料のラスベガス旅行。）
3. CRMを提供できない（問題の範囲が大きすぎなかった。）
4. プロジェクトの範囲を再設定する。（もっと特典がもらえる。）
5. もう一度提供できなかっただろうが、私は別のビジネスを変革する新しい仕事を得たので、あなたのクソみたいなものを楽しんでください。