最初の十年で誰も教えてくれなかったことについて、新しいソフトウェアエンジニア 全員への手紙だ。一般論ではない — 複利で効いてくる具体的な習慣で、これに至る 十五年の出荷経験というレシートがある。アンマンのHAKEEM国家EHRプロジェクトで 22歳だった自分に渡せるなら、そうしたい。
その一：書く前にコードを読む
最初の十年における、最もレバレッジの高い習慣は書いていないコードを、本番 コードベースの中で、意図を持って読むことだ。流し読みではない。本当に読む — ファイルごと、関数ごと、すべての分岐で「なぜここにあるのか？」と問いながら。
私が尊敬するシニアエンジニアは皆、この習慣のそれぞれのバージョンを持っている。 当たり前に聞こえる。ジュニアが最初にスキップするのがこれで、書くことより読む ことの方が生産性が低く感じられるからだ。違う。読まずに書けばコードベースに すでに存在する関数を再発明し、既存の抽象と衝突する抽象を発明し、元の作者が コードの形に刻み込んだ制約に違反する設計を提案することになる。
新しいコードベースに入った最初の月の中で、読むだけに使う丸一週間を確保しろ。 マネージャーは成果物を出していないと思うだろう。三ヶ月後、このステップを スキップした同僚と比べてアウトプットは劇的に良くなっている。複利だ。
その二：学んだことを書き留める
どのコードベースにもドキュメント化されていない不変条件がある。どのチームにも 三人の頭の中にだけ生きている慣習がある。どの本番システムにも、インシデントの 中で痛い目に遭いながら学んだ奇妙なエッジがある。
見つけたら書き留めろ。 プライベートなファイルにではない — 共有の知識 ストア（リポジトリのdocs、チームのwiki、特定モジュールのREADME）に。書くこと で学んだことを言語化させられ、実は理解していなかったものが浮かび上がる。次の 人がさっき君が費やした一週間をスキップできるようにもなる。
虚栄心のある部分を言うと：ドキュメント化によって出荷するよりも速く、役に立つ エンジニアとしての評判を築ける。出荷してかつドキュメント化すればキャリアを 積んでいる。ドキュメントなしで出荷するだけならチケットを消化しているだけだ。
その三：質問のための一時間ルール
一時間詰まったら質問しろ。三時間ではなく。一時間。
シニアエンジニアなら誰でも経験がある：画面を半日見つめ、進捗ゼロで、それから 誰かが30秒で答えを出した。その半日は無駄だった。的を射た質問が教えてくれた こと以上には何も学ばなかった。その半日で何も生み出せなかったことで、チームは 君の沈黙の代金を払った。
反論は「もっと頑張りたい」というものだ。その本能は正しいが、キャリブレーション は大抵ずれている。一時間。それから質問する。聞くのが恥ずかしければ、それでも 聞け。その恥ずかしさは、半日ずつ消えるジュニアエンジニアの評判税と比べれば はるかに小さい。
その四：デバッグするときは実況する
厄介な何かをデバッグするとき、考えていることを声に出せ（あるいはターミナルの メモファイルに、あるいはSlackのスクラッチチャンネルに）。「XはYのせいで 起きていると思う。それが正しければZが観測できるはず。Zを確認しよう。ん、 Zが観測できない。ということはXの原因はYではない。Xの他の原因は何だろう？」
これはパフォーマンスではない。ループを回り続けることを避ける方法だ。実況 バージョンのデバッグは、黙ってやっていれば立てていた仮定を浮き上がらせる。 デバッグを、他の人に語れるインシデント後のストーリーに変えるという副作用も あり、これはチームにとって非常に価値がある。
その五：テストはそれが捕まえるバグより安い
私がメンタリングしてきたジュニアエンジニアは皆、一年目に同じ誘惑を持った： 「これは確実に動くから」とテストをスキップする。正直に言おう：確実なんてことは ない。誰も確実じゃない。テストは動くという証拠だ。テストがなければ「動く」は フィーリングであり、フィーリングはその関数を次のエンジニアが編集したときに 生き残らない。
テストを書け。特にエッジケースで。特に「明らかに動く」退屈なハッピーパスで。 スキップしたテストが、出荷するバグを捕まえるテストになる。
その六：地味な仕事を意図的にやる
どのチームにも誰もやりたがらない仕事がある：不安定なテストのアップグレード、 わかりにくいモジュールのドキュメント化、脆いスクリプトの書き直し、オンコール の引き継ぎテンプレートのオーナー。志願しろ。
三つの理由がある：
- フィーチャー作業では教えてくれない方法でシステムを学べる。
- エントロピーを減らす人、というシニアエンジニアとしての特定の評判を築ける。 それはどんな単一のフィーチャーよりも価値がある。
- シニアエンジニアは希少だ。どのチームも必要としている。そうであるという 目に見える証拠を積み上げることが、そう扱われる最速の道だ。
その七：最初のマネージャーはデータポイントであって、キャリブレーションではない
最初のマネージャーが素晴らしければ、大切にしろ — そして彼らが例外だと 認識しろ。最初のマネージャーが悪ければ、それはマネージャー全般のキャリブレーション ではない。私が知るほとんどのシニアエンジニアは、フルスペクトルを経験している。
実践的な結論：最初のマネージャーの君への評価に基づいて、長期的なキャリア の決断をするな。その評価は一人の見方であり、その人もおそらくマネージャーとして トレーニングされていない。
また：最初のマネージャーが間違って聞こえるアドバイスをくれたとき、それを 退けたり受け入れたりするのではなく「どう間違っているの？」と聞け。ほとんどの 最初のマネージャーのアドバイスは、本当に役に立つ何かが崩れたバージョンだ。 一緒にほどくと、彼らもほどく過程で何かを学ぶことが多い。
その八：オープンソースのポートフォリオはキャリアのチートコードだ
私が知る、好きな役割に就いたエンジニアは皆、目に見える実績を持っていた。 必ずしも人気のあるプロジェクトではなく — 目に見えるもの。いくつかのOSS コントリビューション、書いてドキュメント化した小さなツール、ブログ記事のシリーズ、 カンファレンストーク。採用マネージャーがGoogle検索したときに「このエンジニアの 思考の形はこういうものだ」という一貫した絵が返ってくる何か。
そういうものが何もなくても優れたエンジニアになれる。機会は少なくなる。あらゆる ステージで、ポートフォリオを持つことはないよりも安い。始めろ。大げさにしなくていい。 小さなツールを出荷しろ。三つ投稿しろ。使っているものに貢献しろ。
今ここでこのサイトを出荷している私は、ある意味でその同じアドバイスへの再コミット だ。数年間怠けていた。それを直している。
その九：複利で効くスキルは明確さだ
賢さではない。速度でもない。深さでもない。明確さだ。
決定を一文で説明する能力。なぜをdescribeするコミットメッセージを書く能力。 次のエンジニアが何が起きているかわかるコードベースを残す能力。この機能は 六週間ではなく三週間かかるとPMに伝え、なぜかを正確に見せる能力。
他のすべては道を歩みながら学べる。明確さは複利で効き、早くに築いたエンジニアは そうしなかったエンジニアに対して複利的な優位を持つ。
その十（静かなやつ）：自分の興奮を疑え
私が見てきた — そして犯してきた — 最もコストの高いミスは、問題が適切に理解 される前に解決策に興奮することから来る。「これを書き直そう。」「この新しい フレームワークを使おう。」「サービスに分けよう。」興奮はシグナルだが、決定の 関数ではない。技術的な選択への興奮に気づいたとき、一週間待て。計画を 書き下せ。寝かせろ。君よりも興奮していない誰かに穴を開けてもらえ。
興奮が一週間後も残っていれば、それは本物だった。
残っていなければ、数ヶ月を節約した。
以上だ。これが手紙だ。完全ではないが、正直で、22歳のときに誰かに渡してほしかった ものだ。初めての仕事を始めていて、誰かがこれを見せてくれたなら、嬉しい。 そしてこれが時間の節約になることを願っている。