シニアエンジニアとして学んだこと（2021年）
(luminousmen.substack.com)- 長期キャリアでは、頻繁な転職が報酬アップに有利なこともあるが、長く残って自分のコードが本番環境で生き残るのを見る経験は、別種の深いフィードバックループを与える
- ドキュメント化とテストは、コードそのもの以上に、なぜその選択をしたのか、なぜ別の選択をしなかったのか、リファクタリング後も維持されるべき振る舞いは何かを残す手段として重要である
- 言語と型システムの選択では、動的言語の柔軟性と静的型の tooling・リファクタリング上の利点が常に衝突しており、良い設計は言語そのものよりも、境界と契約をどれだけ明確に置くかに大きく左右される
- コラボレーションと働き方では、共同ホワイトボードのような即興的な相互作用の価値、コードの寿命が短いものと長いものが共存する現実、職場文化と報酬構造が働く姿勢に及ぼす影響があわせて見えてくる
- 貯蓄と退職戦略は、米国式の税制優遇口座を活用した早期リタイアの可能性とともに、所得・家族状況・居住地域・国家制度の違いによって現実性が大きく変わる
キャリア成長と技術市場
-
転職、報酬、長期的なフィードバックループ
- 別の会社へ移るやり方は、収入増加にはしばしば有利で、18〜24か月程度が報酬改善の sweet spot のように見えた
- 4年後にベストされる equity、社内昇進、インフレを反映した昇給が、実際の期待に届かない場合が多かった
- 一方で、5年以上経った自分のコードを本番環境で見る経験は、深みのあるフィードバックループを与える
- 1年以下の短期在籍の繰り返しは印象がよくないこともあるが、2〜3年周期の移動はその境界線に近かった
-
ゼネラリストと市場報酬の問題
- generalist は、狭い専門性を持つ人より全体として過小評価されやすい
- 15年間にわたり、グローバルネットワーク、VLAN 体系、Entra と Okta ベースの IAM、JAMF と InTune MDM、Windows サーバー、VMware VCF データセンター、AWS/GCP/Azure テナント、CapEx と OpEx の予算計画、物理セキュリティとインフラ、サイバーセキュリティ、ハードウェア、ソフトウェア、ライセンス、アーキテクチャ、サポート、オンコールまで担当することもあった
- その経歴があっても、現在の市場価値は $130k 程度で、2019年と同額であるうえ、その間に生活費は2倍になっていた
- メトロ地域の中央値家賃は約 $3500 で、税引き後の 50/30/20 予算基準でも負担が難しい
-
2021年の求職市場と現在との距離感
- 「2週間で新しい仕事を見つける」という文は、今の基準では aged like milk に近い
- その文はリンクされた Reddit 投稿から取られたもので、5 years ago のまったく異なる求職市場を反映していた
- 2021〜22年は少なくともヨーロッパでは雇用市場の頂点で、「息をしているだけで」仕事が見つかるほどだった
- 今のように、AI を理由に大規模解雇をした後、より低い給与で再雇用するような経済環境では、長期投資の助言は現実的でない可能性がある
-
年収 100k の新卒前提の妥当性をめぐる議論
- 23歳で $100k/yr を稼ぐ米国の状況は、ヨーロッパの開発者には驚きをもって受け止められた
- 39歳、業界歴17年、リード職、銀行・フィンテック・メドテック・コンサルティングの経験があっても、年 €76k/yr 程度にとどまることもあった
- 私的な時間まで使って最新技術を学び、サイドプロジェクトをしても、年収はその水準にとどまっていた
- 米国テック業界の報酬が世界の他地域の水準へ正常化すれば、衝撃は大きいかもしれない
- 一方で、Indeed の求人公告ベースでも、米国の23歳新卒で 100k は outlier である可能性があった
- 別の反論として、2010年代半ばの HCOL 都市基準では Microsoft は新卒開発者に 100-120K を支払い、Amazon や Apple はそれより良いオファーを出すこともあった
- 23歳で $100k/yr を稼ぐ米国の状況は、ヨーロッパの開発者には驚きをもって受け止められた
ドキュメント化、テスト、知識の保存
-
なぜを残すドキュメント化
- コードそのものを読むことはできるが、なぜ
invert_parametersのような 200行の関数 が存在するのか、どんな問題を解決したのか、その問題がなぜ生じたのかのほうが重要である - コードの想定寿命、時間的なプレッシャーやマネージャーからの圧力、上流・下流システムの奇妙な挙動のような背景を残しておくと、将来の読者が作成当時の 思考の文脈 を理解する助けになる
- なぜそうしたのかだけでなく、なぜ しなかったのか もあわせて残すことが重要である
- すぐ動くが最適ではない解法を実装しつつ残したコメントが、15年後に製品が成長した時点で読み返され、活用されたこともあった
- こうした shadow knowledge は、担当者が会社を去ると一緒に失われやすく、残った人たちを混乱させる
- 将来の自分も忘れることを前提に、comments、commit messages、そのほかの文書にできるだけ多くの clues を残すこともあった
- コードそのものを読むことはできるが、なぜ
-
テストのドキュメントとしての役割
- ドキュメント化は ADR、システム図、specs、JIRA チケット、commit message、PR description、code comments、直感的なコードなど、さまざまな形を取りうるが、最新状態に保たれていなければならない
- テスト もドキュメントの役割を果たし、TDD や BDD のような流行語とは別に、実際にテストを書く能力は明示的に訓練されないことが多い
- 実装詳細に過度に結びついたり、mocks や stubs だらけだったりするテストよりも、リファクタリングに耐えるテストセットを作れば、よく説明された assertions を通じて複雑なルーチンの振る舞いを文書化できる
- こうしたやり方は、コードコメントで how や what を繰り返す必要を減らし、コードから commits、issue tracker へと上がるにつれて複数の層の why を残していく構造につながる
-
意図、理論上の動作、新規開発者の視点
- 異常系の失敗補償、明確でないビジネス要件への対応、後で直すための暫定措置のような明白でない意図は、読者やレビュアーが必ず知る必要がある
- 電気設計文書が schematic、parts list、board layout だけでなく theory of operation まで含むべきであるように、ソフトウェアもコードや UML だけでは不十分である
- 主要コンポーネント、相互作用の理由、一般的な動作フロー、新しい開発者が最も可能性の高い変更をどう実施するかもあわせて記すべきである
-
AI とドキュメント化をめぐる議論
- AI はコード片を読んで説明することには長けているが、なぜそのように実装したのかを簡単にリバースエンジニアリングできるわけではない
- 逆に、それが技術的理由であるなら test suite や type system の中に表現されているべきであり、重要でない恣意的な選択まで文書化しても読まれないかもしれない
- さらに逆に、実行可能な3つのアルゴリズムのうち1つを「数学的に美しく見えたから」選んだというメモは、数年後に最適化担当者が残り2つも試してみるきっかけになる実用的なヒントとなる
- benchmark tests で意図を捉えられるのではないかという反問もあり、premature optimization のほうがより一般的なのだから、追加コードは dead weight になりうるという見方もあった
- 重要な性質がすべてテストされた完全なシステムを前提にするのは、現実の 99.9% のシステムには合わず、AI がコードをリバースエンジニアリングするときも文脈知識が核心だった
- 反対側では、重要な性質はすべてテストすべきであり、残されなかった文脈は人間にも LLM にも復元できないと考えられていた
-
良いドキュメントの基準と LLM 活用
- 良いドキュメントとは、次の機能を簡単に実装できるようにするドキュメントだというシンプルな基準があった
- LLM は、ドキュメントが乏しいコードでも内部的に推論を組み立てて意味を復元する傾向があり、実際にコードとともに残すべき文書は、その推論過程で到達しそうな内容に近いかもしれない
- こうしたドキュメント基準をモデルに学習させる方向が望ましいと考えられており、
doc-stewardという GitHub パスを実験中で、まだ手を入れるべき部分は多いが、何もないよりは良かった
言語、型システム、設計思考
-
動的言語と静的型に関する相反する経験
- 年齢を重ねるほど dynamic languages をより好むようになる、という一文に共感する流れがある一方で、Python式の gradual typing は良いが、RubyのRBSやSorbetの方式はあまり満足できないと感じられていた
- 逆に最もつらかったコードベースはPythonで、リファクタリングが非常に難しく、静的型で防げたはずのバグが多く、性能問題も事業に影響していた
- 別の側面では最悪のコードベースはGoであり、十分にやる気のある開発者はどんな言語でも混沌としたものを作れてしまい、型もそれを大きくは防げないという見方もあった
- Pythonに basedpyright と意図的な type hinting を組み合わせた最近の経験は久しぶりに最も満足度が高く、実際の生産性の面ではAIよりも大きな効果を感じさせた
- 静的型言語の利点は、バグ予防よりも tooling の面でより大きく感じられることもあった
- 入力Aの形が出力Bが要求する形と一致しているかを、タイピング段階で把握できることは大きな利点になる
-
動的言語の役割と限界
- PHPでキャリアを始め、インフラチームで多くのリファクタリングを経験した場合、動的言語は見た目には良く見えても、Goのような弱い静的型言語のほうがよりバランスが取れていると感じられていた
- HN自体が 動的言語 で作られた重要なウェブサイトであることを挙げ、重要なものは動的言語で作るべきではないという主張には同意しなかった
- PythonはAIで orchestration や glue に多く使われるが、実際のAIの重い計算はPythonではなくGPUや他の言語スタックが担っており、核心的な推論・学習ロジックがPythonで書かれていたなら、現在レベルのAIは存在しなかっただろうという反論も出た
- 自動車の ABS のようなシステムは、Pythonよりもさらにエラーが起きやすいCやマイクロコントローラのアセンブリで書かれていた可能性が高く、実際に意図しないABS作動を経験したという話もあった
-
TDD、契約、境界の明示
- TDD を初めてきちんと学んだとき、目が開かれるような経験になったという声もあり、同じプログラムを2つの方法で書いて出力が一致するかを見ながら要件理解を検証する方法が実際によく機能していた
- 「TDD is a cult」という文に一部共感しつつも、コードの個々の部分に対する pre-conditions と post-conditions を把握することは重要だとされた
- Design-by-Contract はその概念を形式化したものであり、pre/post conditions だけでなく class invariants も扱う
- AIによるコード生成も、このような契約的な境界が明確であるほど、よりうまく機能しうる
-
言語選択のたとえとJava、Go、Rustの比較
- 「何をすべきかわからなければJavaをやれ。ほとんどすべてに対してそこそこ使える、平凡な言語だ」という文には強い共感が集まった
- RustをKotlin、Scala、Clojureではなく Javaの進化形 と見る視点もあった
- これに対して、GoがJavaに近い役割を果たしており inheritance や過度な関数型要素がないという見方、RustはC++の後継により近いという見方、Javaの核心は ease of use でありRustはそうではないという反論もあわせて出た
- Javaの context dependency injection と JSON、JAX-RS の組み合わせは、シンプルで直接的なバックエンド体験を与え、throughput は良いがメモリ使用量はやや高かった
-
制約が設計をシンプルにした事例
- 共用ホスティング環境で SSHなし、FTP-only deploys、background workers なし、Redis なしという制約のため、proper な job queue、WebSocket、cache layer を作れなかった
- 結局、1時間に1回PHP endpoint を呼び出す cron job で click notifications を送る単純な構造を選び、queue、retry logic、worker process がなくても6か月間うまく動作した
- 最初からVPSがあったなら、今も保守中のより複雑な構造を作っていた可能性が高く、ホスティングが「cronとdatabaseだけを提供する」と言っただけでも、結果的には十分だった
協業、コミュニティ、働く姿勢
-
HNコメントの価値をめぐる分かれる評価
- HNとr/programmingはアイデアを得たり最新動向を把握したりするのには良いが、コメントはほとんど価値がないという一文が繰り返し引用され、一部の共感を集めていた
- "full effect as per usual"、"LOL can't disagree" のような短い同意表現も続いた
- 一方で、HNモデレーターのrate limitのせいで1日に数回しかコメントできなくなるとコメントを読む量も減り、その習慣を断つことがむしろ悪くないと感じたという話もあった
- ある利用者は、ほとんどの日はコメントを1つも書かず、書いても1日2件以下だとして、参加の仕方の違いを示していた
- Lobstersには招待を受けたことがなくても、定期的に読むに値する興味深いリンクやコメントがあり、招待の申し出、HNとの議論の違いの比較、小さなコミュニティ特有の見慣れたユーザー同士の関係についての話も続いた
- 過去のbad behaviorによるdown-voteの集中のため制限がかかっていたが、その後は問題がなかったため制限が解除された、という返信をHNからメールで受け取ったという話もあった
-
リモートワークと共同ホワイトボード
- 在宅勤務は良いが、whiteboarding が足りない点は「唯一恋しいもの」として挙げられることもあった
- 個人用ホワイトボードやTeams系ツールの共有ホワイトボードアプリでも同じ問題を解決できる
- ただし核心は個人ボードではなく 共同ホワイトボード であり、ソフトウェアの代替手段があっても、実際に一緒に立って即興でスケッチする体験とは違っていた
- drawing tabletが全員に普及するまでは、オンラインホワイトボーディングは十分に自由ではないという認識もあった
- 四半期ごとに1週間ずつチームが直接集まるやり方はかなり良いバランスで、人々が部屋に集まってアイデアをブレインストーミングし、ボードに落書きしていた体験は良い記憶として残っていた
-
コードの寿命と重要性についての相反する回顧
- キャリア全体を振り返ると、自分が書いたコードのうち significance があったものはほぼ0%に近いと感じることもあった
- 30年以上コードを書いてきたが、5年以上運用に残っているコードはほとんどなく、90年代にOOPを学びながら書いたひどいコードのほうがむしろ長く生き残り、2018〜2021年のスタートアップで書いた素晴らしいコードは会社とともに消えたこともあった
- その一方で、10年後も動き続け、10億AUD超 を処理し、保守がほとんど不要だったPHPマイクロフレームワークベースのプロジェクトを誇らしく思い出す人もいた
- 10年あまり働いてきたが自分の書いたコードの大半がまだ本番稼働中だと感じる人もおり、数百万人または数千人のユーザーが使うコードの品質と性能が重要だと見る人もいて、評価は分かれていた
- 場合によってはコードの平均 half-life が3〜4年ほどで、15年間に同じサービスのバックエンドがGroovy on Grails → Java → Java → Pythonと4回書き直されたこともあった
- 2026年のPythonコードも、1996年にPerlとJavaScriptでやっていたことと本質的には大差ないCRUDアプリだという皮肉もあった
-
職場文化と姿勢
- 非技術職で得た教訓として、賢い人と同じくらい賢くなれなくても構わないこと、無能な人たちと働くことに慣れるべきこと、職場は友人を作るのに良い場所であること、神話のようなjob satisfactionより給与最大化と産出最小化のほうがましなこと、最も重要な要素は luck だという5項目の一覧があった
- 職場を9-to-5の仕事としてしか見ず、文書化や長期的な品質を気にしない態度には批判があった一方で、健康保険と生活のために歪んだインセンティブのゲームをせざるを得ない労働者を責めることはできないという見方もあった
- "bring your authentic self" という文化の中でも、職場では結局 professional であるべきだ
- テック業界には女性が十分におらず、女性や黒人エンジニアをもっと励まし助けたいが、何をさらにすべきかわからないというくだりもあった
- 現在のテック業界のthought leadersが公然と信じ、語っていることを見ると、こうした現実をよりよく理解できるというコメントも続いた
-
形式とトーン
- 一人でワインを飲みながら文章を書く場面は奇妙に受け取られ、ウイスキー・ウォッカ・ビールのほうが普通だという冗談へとつながった
- 誤字や乱れた文の構造が alcohol induced unordered thoughts をよりよく表しているという評価もあった
- 酒はとても個人的なもので、ほとんどいつも一人で飲むほうであり、ピアノを人前で弾くことのほうがむしろ奇妙に感じられるかもしれない
- Sonomaの大手ワイン会社で働いていたときは、一人でワインを飲む人が多いこともあった
- 酒を飲んで人生を振り返ることは珍しいことではなく、Bukowski、Faulkner、Kerouacといった名前もあわせて思い浮かべられる
- 逆に、実際の酔った文章というより、意図的に誤字と "pour another drink"、"take a sip" を混ぜた literary device のように見えて奇妙だという批判もあった
- 「HRが専門職としての義務を定めるわけではない」という前提に立てば、酒に酔わなければここまで率直になれない人はseniorやmentorではなく、初期のアルコール依存症者であり臆病者に近く、engineerという肩書きも偽りで、ただのdata scienceにすぎないという攻撃的な解釈すら可能だった
-
その他の比喩と反論
- 薬剤師の面接では有機化学のクイズは出ないという比喩には、薬剤師は面接前に特別な学位と何年もの勉強、試験を経ており、実際に有機化学の比重も高いという訂正が続いた
- HNコメントは役に立たないことが多いが、Apple CEO changeのような記事ではコメントのほうが本文より良い場合もある
貯蓄、引退、税制戦略をめぐる議論
-
初期の節税・貯蓄戦略
- 20代で 6 figures を稼ぐ人に対して、401kの最大拠出、HSAの最大拠出、IRAの最大拠出、生活費6〜12か月分を高金利の貯蓄口座で確保するよう勧める具体的な助言があった
- 401kとHSA、IRAの資金は target date retirement fund に投資すべきだという提案も含まれていた
- 一部の会社では401kが自社株中心に配分されることがあるため、資産配分を確認すべきだった
- HSAは医療費を現金で支払い、領収書を保管しておいて、引退時に払い戻しを受ける戦略が提示されていた
- 23歳で始めて年収 $100k/yr なら45歳で引退可能だという試算もあった
-
現実性と生活条件に対する反論
- この戦略が成り立つには、質素さ、安価な趣味、子どもがいないこと、無職の配偶者がいないこと、家族扶養の負担がないこと、高コスト地域を避けることといった前提が必要だった
- Ohioで片働きで子どもを育てながら 45~50歳 引退の軌道に乗っており、毎月 $1,000 以上寄付もしているが、大きく何かを我慢して暮らしている感覚はないという返答もあった
- そのケースは米国上位 15% の所得層に近い特権的な条件であり、$80k 以下を稼ぐ多くのプログラマーには当てはめにくいという反発もあった
- これに対しては、収入の範囲内で生活し、可能なら所得の 15% を貯蓄せよという返答があった
- 米国のプログラマーが $80k、あるいは $100k にすら届かないなら、引退計画の第一段階は新しい仕事を探すことだが、今はそこまで簡単ではなく、仕事があること自体に感謝すべき状況に近い
- 家族や子どもがいても完全に不可能ではない点が強調され、両親が同程度の給与を得ていれば45歳引退も可能だが、大学資金のためにさらに多くの tax-advantaged 制度が必要であり、高コスト都市にはあまり向かないかもしれないとされた
-
早期引退に必要な資金規模と生活費の計算
- 45歳で引退するには約 $1M では不足だという見方があった
- 逆に $1.8M-$2.2M、年 6%-7.5% の利回り、employer contribution を除く前提なら年 $72k-$88k を引き出せ、67歳で social security を受け取り始めれば資産は維持され続けるという試算もあった
- 45歳引退は social security に大きな影響を与えないのかという質問に対しては、月約 $3800 の代わりに $2500 程度を受け取ることになり、年 $77k が $107k/yr 水準になり、さらに重要なのは引退口座が成長し続けるのを助けることだという計算が続いた
- 年 $40,000 でも暮らせそうに思えても、property tax や救急外来で数針縫うだけで $40k かかるような状況まで考慮すべきだった
- 英国のユーザーは病院代は £0 だと応じていた
-
早期引き出しの仕組みと口座運用
- 45歳で引退しようとしても、資金を 59.5歳 まで引き出せない引退口座に縛られていると難しいという指摘があった
- これに対して、SEPP 72t disbursements、Roth conversion ladders、早期引き出しペナルティの支払いといった方法で、もっと早く使えるという説明があった
- 年間支出額にバッファや屋根の葺き替え、老朽化した車、健康問題のような既知の liabilities を加えて計画すべきであり、ProjectionLab のようなツールや専門家の助けを勧める声もあった
- SEPP 72T は最低 5年 または 59.5歳 まで同様の引き出しを続ける必要があり、5年間はSEPPと非優遇口座を併用しつつ、同時に Traditional 口座から Roth への転換を進め、5年後に転換分を引き出す方法が紹介されていた
- この計画を説明した人は20代で遅れてテック業界に入り、45歳ではなく 50ish での引退を目標にしていた
- rule of 55、Roth contributions の年齢制限なし・ペナルティなしの引き出し、HSAに保存した医療領収書を通じた払い戻しも早期引き出し戦略に含まれていた
- HSAと FSA は別物であり、65歳以降のHSA引き出しにはペナルティがなく、通常所得として課税される
-
401k、Roth、課税口座の相対的価値をめぐる論争
- RRSP/401kは資金を縛り、税金を最も少なく払いたい時点まで先送りし、将来の税率がより高くなる可能性があるため、employer match の上限までだけ入れて、それ以上は拠出しないほうがよいという主張があった
- 一方で米国では歴史的に税率は上がるより下がってきており、引退時には401kとRothを組み合わせて引き出して課税区分を抑えられ、税引前資金が先に複利で成長する効果が非優遇口座より有利だという試算が示された
- broker 口座は給与時点で税を払い、引き出し時に cost basis に対してまた税金を払う構造として比較されていた
- 米国の例では、夫婦が401kを最大拠出して約 50k の課税を繰り延べ、世帯所得 300k でその金額が 24% marginal rate だったと仮定すると、引退後に2倍になった50kの引き出しへ 12% の税率を適用して 88k を手元に残せる
- 逆に非優遇口座では最初に24%を払い、38k を投資して2倍になると 76k になる
- カナダの視点では、RRSP/401k の引き出し時には投資収益全体が通常所得として課税される一方、非登録の投資口座は capital gains として marginal tax rateの50% だけ課税されるため、より有利になりうるという反論があった
- カナダ側では $50k をS&P500に30年間投資すると約 $872k になり、RRSPでは全額が所得として課税されるという試算もあった
- これに対しては、カナダ特化の計算機を使ってみるよう勧める声があり、米国では401k、Roth、非優遇口座を混ぜる方法が実際の早期引退計画で有利だったという経験談もあった
- 401kからRothへ転換し、5年 後にペナルティなしで引き出す 401k/Roth conversion ladder を理解してから考えが変わったというケースもあった
- カナダのユーザーはRRSP、TFSA、FHSA、非登録投資口座の税制上の違いを整理し、RRSPは引退前には引き出せないと書いていた
- TFSAはRothに似ており、RRSPからTFSAへ似た形の転換が可能なら、より早い時点で資金にアクセスできる
- 政府の仕事経験をやや否定的に書いた元文とは違い、457(b) は常にありがたい制度でもあった
- 「これはひどい金融アドバイスだ」という断固とした批判もあった
-
米国と欧州の制度の違い
- ドイツのユーザーは米国の tax-advantaged retirement funds を非常にうらやましがっており、ドイツの政府義務年金は崩壊寸前の詐欺のように感じられ、平均的な労働者は 65/67歳 より前に引退するのは事実上不可能だと見ていた
- 早期引退すると生涯年金が毎月 0.5% 減額され、401k、Roth、IRA のような制度もないとされていた
- 「これはいったい何を意味するのか」という質問への答えは、引退を前もって計画し、政府・雇用主支援の貯蓄手段を活用せよというもので、欧州にもこうした制度は多かった
- スイスでは、国家の第1の柱、雇用主が同額を負担することが多い義務的な民間第2の柱、任意の第3aの柱があり、第2・第3の柱は居住用不動産の購入や起業にも使え、60歳での引退計画、年 10週 の有給休暇、90%勤務体制の例も挙がっていた
- 別の欧州ユーザーは、国家年金の受給年齢が平均寿命の延びに合わせてどんどん後ろ倒しになっており、70代になってやっと引退できるのかもしれず、この制度は信頼しづらいと述べていた
- ドイツ・フランスでは賃金の 20% を義務的に納めても年金を受け取れないかもしれないという悲観論もあった
- Poland には IKE と IKZE があり、IKEは60歳まで維持すれば税金を払わずに stocks や bonds に投資できる
- Germany や一部の国では、実質的に役に立たない保険・元本保証オプション以外の選択肢がほとんどなく、投資するには税引後資金を入れ、引き出し時に capital gains を払わなければならない
-
英国では、National Insurance に基づく state pension、2012〜2018年に導入された auto-enrollment private pension、基本の 従業員5% + 雇用主3% の拠出、salary sacrifice、SIPP、ISA、LISA などにより、老後資金の貯蓄の仕組みが分かれている
- オランダでは、私的年金や退職前には引き出せない銀行口座に追加で貯蓄すると、wealth tax を支払わず、引き出し時にのみ課税されたり、拠出額が tax deductible になる場合もあった
- ヨーロッパ全体では six figures は不可能だといった一般化は成り立たず、国ごとに制度は異なっていた
4件のコメント
本文の内容が少しおかしいですね？ 本来は Hacker News の意見として別にまとまって表示されるべき内容が本文に入っているのですが……方針が変わったのでしょうか。
ここ数日プロンプト改善中だったので、少し不安定でしたね。すぐに修正しておきました（泣）
generalist についての内容には共感します。私も新人の頃はジェネラリストにならなきゃ〜と思っていましたが、
Hacker News の意見
ソフトウェアエンジニアをやっていると似た考え方の人たちに出会えるという話は、自分の経験とは少し違っていた。自分が会った50人のうち1人くらいしか職人気質でこの仕事をしている感じはなく、ほとんどはただ9-to-5と可視性、インパクトのあるプロジェクトを求めているだけで、自分の問題や意見を深く共有することはなかった
「2週間で新しい仕事を見つける」みたいな話は、いかにもあの時代っぽい。当時は労働者側が市場を握っていて、みんな専門家ぶっていた雰囲気があった
「英雄に直接会うな、5,000ドルの講義を受けてみたら、その人も自分たちと同じように即興でやっているだけだった」という話には完全に共感した
エンジニアにとって最も過小評価されている能力はドキュメンテーションだという話に付け加えるなら、ドキュメントには何よりなぜを残すべきだ。コードは読めるが、200行もある
invert_parametersのような関数がなぜ生まれたのか、どんな問題を解いたのか、なぜそんな問題があったのか、このコードがどれくらい生き残る想定なのかが知りたい。自分はときどき、時間的プレッシャーや奇妙なupstreamの問題のせいでこう書いたという謝罪的なコメントまで残す。特に自明でないコードほど、書いた当時の思考を描いておかないと、コードだけでは見えない文脈が残らない。ジュニアでもシニアでも、職場でこういうことをもっとやってほしい20代で年収10万ドル以上稼いでいる人がいるなら、まず401kとHSAをできるだけ満額まで入れ、そのあとIRAも満額まで埋めろという助言は本当に重要だと思う。全部target date retirement fundに入れ、生活費6か月から12か月分はhigh yield savings accountに置けという基本原則も悪くなさそうだった。23歳から始めれば45歳での引退も可能だという趣旨で、あとに延ばすと45歳になってもまだ20年働く現実に向き合うことになるかもしれないという警告だった
自分が学んだ最も有用な教訓は、自分がわざと作った制約よりも、自分で選んでいない制約のほうがむしろ良いプロダクト判断につながるということだった。自分は共有ホスティング上でリンク短縮サービスを動かしているが、SSHもなく、FTPデプロイしかできず、バックグラウンドワーカーもRedisもない。ちゃんとしたキューやWebSocket、キャッシュレイヤーを入れようとするたびにホスティング側が対応していないので、結局やらなかった。だからクリック通知は1時間に1回PHP endpointを叩くcronで送っている。キューもリトライロジックもワーカーもなく、送れるか失敗するかのどちらかで、結果だけログに残す。6か月使ってみたが、問題なく動いていた。最初からVPSがあったら、今まで面倒を見るべき何かをもっと大きく作っていたはずだが、共有ホスティングが「cronとDBしか出しません」と線を引いてくれたおかげで、それで十分だと学べた
元記事にはかなりいろいろな問題点が見えた。ひとりでワインを飲むのは少し変わっていて、普通はウイスキーやウォッカやビールのほうが典型的だと思う。
ever thingのような綴りは、酒が入った状態のまとまりのない思考っぽくて、むしろその雰囲気には合っていた。そしてwebdevを専門家の代表格と見るのは難しいし、dark modeはブラウザ拡張で解決することも多いと感じる。薬剤師は学位と長い勉強、試験、有機化学が必要な職業で、HNコメントが無価値だという話も言いすぎだと思う。ひどい記事でもコメントのほうが本文より良いことはかなり多かった関連記事として、2021年5月の Drunk Post: Things I've Learned as a Sr Engineer を思い出した。コメントが494件も付いた投稿だった
これが2021年の文章だというのが驚きだった。SQLの話や2週間で転職できるという空気感があまりにも2014年っぽい感覚に思えた
「HNとr/programmingは大まかなアイデアや最新動向の把握には良いが、コメントはほとんど無価値だ」という話に関連して、自分はHN運営からrate limitをかけられてからコメントをあまり読まなくなった。1日に数回しか返信できず、参加そのものができないので、読む動機が減った。露骨にbanするのではなく速度を落とすやり方なので、より微妙に招かれざる客になった気分もあった。何か大事なものを見逃しているのではと心配したが、コメントを確認したくなるあの習慣的な引力を断つのも、思ったほど悪くないかもしれないと思った