優秀なエンジニアが伸び悩むのを見てきた。
コーディングは得意。設計レビューでも賢い。でもなぜか、大きなプロジェクトを任されない。スタッフに昇進しない。
違いは何か？他のエンジニアが一緒に働きたいと思わなかったのだ。
成長する人は、必ずしも一番声の大きい人ではない。彼らが理解していること：
採用されるために必要なもの： 技術力、面接パフォーマンス、履歴書の資格、LeetCodeスコア。
昇進するために必要なもの： 人があなたに重要なシステムを任せる。人があなたとチームになりたがる。人が会議であなたの話を聞く。人があなたがいないところであなたを推薦する。
これを築くには時間がかかる。何年も。でも利息のように複利で効く。
パーソナルブランディングは忘れろ。Twitterのフォロワーも忘れろ。これに集中しろ：
サプライズなしで時間通りに納品する。
第1週、月曜日: 「金曜までにやります」
第1週、金曜日: 「完了、PRです」
vs.
第1週、月曜日: 「金曜までにやります」
第1週、木曜日: 「実は、もう少し時間が必要です」
第1週、金曜日: 「まだ作業中です」
第2週、火曜日: 「スコープが増えました」
第2週、金曜日: 「もう少しです...」
金曜と言ったら金曜だ。遅れるなら、木曜の夜ではなく月曜に言え。
自分のシステムを知れ。
深夜2時の本番障害:
エンジニアA:
「ログはどこ？」
「これ何のサービス？」
「誰がオーナー？」
「ダッシュボード見つけるの手伝って？」
エンジニアB:
「auth-serviceを見て、IDプロバイダーのレート制限に
引っかかってる。クォータ上げる。
ランブックはこれ: [リンク]」
どっちにオンコールして欲しい？
深夜2時に本番が壊れたとき、何が起きているか理解している人になれ。「ログはどこ？」と聞く人ではなく。
クレジットを分かち合え。
悪い例: 「新しいチェックアウトフローを私がリリースした」
良い例: 「みんなでリリースした。サラがレースコンディションを
見つけて、マイクが負荷テストを担当して、私が繋げた。」
チームの仕事のクレジットを取ることほど評判を壊すものはない。それを譲ることほど評判を築くものはない。
フィードバックをうまく受け止めろ。
「それはバグじゃない」の代わりに — 「いい指摘、直します」
「理解してないね」の代わりに — 「考えを説明させて」
「私の環境では動く」の代わりに — 「一緒にデバッグしよう」
「そういう設計なんだ」の代わりに — 「なるほど、再考しよう」
防御的にならずに聞け。感謝しろ。理にかなったことは行動に移せ。
信頼を築くもの:
信頼を壊すもの:
一度評判が確立されると、機会が向こうからやってくる：
1-3年目: 面白いプロジェクトに応募する
3-5年目: 面白いプロジェクトに誘われる
5年目+: あなたがいない部屋であなたの昇進が推薦される
7年目+: 人があなたについて新しい会社に来る
マネージャーの意見は重要だ。でも10人のエンジニアが「この人と働きたい」と言う方がもっと重要だ。
築くのに何年もかかる: 一貫した納品。チームメイトを助ける。技術的信頼性。協調的な姿勢。プレッシャー下でも冷静。
壊すのに数週間: 1つの重要な締め切りミス。1回のバス下に投げ込む瞬間。1回の傲慢な設計レビュー。1回の政治的駆け引き。1回の公開メルトダウン。
築くのに何年。壊すのに1四半期。
コードは一度リリースする。評判はどこへでもついてくる。
— blanho