これまで多くの開発者に出会ってきた。最近、自分にこう問いかけてみた。「一流になるには何が必要なのか？ 彼らに共通していることは何か？」

この記事が誰かの刺激になればと思い、私が出会った中でも特に優れたエンジニアたちに共通して見られた特徴を書き留めてみた。駆け出しの頃にこのリストが手元にあればよかったと思う。この道筋に従っていれば、多くの時間を節約できただろう。

リファレンスを読め

若いプログラマーだった頃の自分に、ひとつだけアドバイスできるとすれば、それは使っているもののリファレンスを読むことだ。たとえば、Apache Webserver DocumentationやPython Standard Library、あるいはTOML specを読むということだ。

Stack Overflowを見に行くのでも、LLMに聞くのでも、推測するのでもなく、とにかく直接一次情報にあたりに行く。意外なほど読みやすく、よく書かれていることが多い。

使うツールを徹底的に理解する

優れた開発者は、自分が使う技術を根本的なレベルで理解している。

ツールを使えることと、本当にgrokする（深く理解する）ことはまったく別物だ。ただ使っているだけの人は手探りで作業し、すぐに混乱し、使い方を間違え、設定も最適化できない。

エキスパートは（リファレンスを読んだ上で！）腰を据えてツールの設定を書く。その一行一行を理解し、同僚に説明できる。そこには曖昧さの入り込む余地がない。

ツールをよく知るとは、つまりこういうことを知っているということだ。

• その歴史：誰が、何のために、どんな問題を解決するために作ったのか
• その現在：誰がメンテナンスしているのか？ 彼らはどこで、何に取り組んでいるのか
• その限界：どんな時にそのツールは向かないのか？ どんな時に壊れるのか
• そのエコシステム：どんなライブラリがあるのか？ 誰が使っているのか？ どんなプラグインがあるのか

たとえば、バックエンドエンジニアとしてKafkaを多用しているなら、Kafkaについて深く知っていることを期待する。Redditで読んだ程度の知識ではなく。少なくとも、最高のエンジニアの一人になりたいのであれば、そうあるべきだ。

エラーメッセージを読め

つまり、本当にエラーメッセージを読み、そこに何が書かれているかを理解しようとするということだ。じっくり腰を据えてエラーメッセージと向き合ってみると、不思議とメッセージの方が語りかけてくる。優秀なエンジニアは、わずかなコンテキストから膨大な情報を読み取ることができる。エラーメッセージを読むだけで、ほとんどの問題は自分で解決できる。

そのスキルを持っていない人を助けると、まるで超能力のように感じられる。「カップの中を読む」ようなものだ。

問題を分解する

誰でも時には行き詰まる。優れた人は、そこから抜け出す方法を知っている。問題を消化できるサイズになるまで単純化するのだ。これは習得が難しく、多くの経験を要するスキルだ。あるいは、もともと問題解決能力がずば抜けていて、単純に頭が切れるという場合もある。そうでなければ鍛えるしかないが、いずれにせよ難しい問題を分解することを避けて通る道はない。この世には、誰にとっても一気に解くには難しすぎる問題がある。

プロの開発者として働くなら、それが報酬を得る仕事の大部分だ。すなわち、問題を分解することだ。うまくできれば、ずるをしているように感じるだろう。単純な問題を一つずつ解いていくだけで、いつのまにか終わっているのだから。

手を汚すことを恐れるな

私の知る最高の開発者たちは、たくさんのコードを読み、触れることを恐れない。「それは自分の領域じゃない」とか「ここは手伝えない」とは決して言わない。とにかく手を動かし、学び始める。コードは所詮ただのコードだ。必要なスキルは、時間と労力をかければいくらでも身につけられる。気づけば、彼らは触れた領域についてチームで頼られる存在になっている。そもそも触れることを恐れなかったのが彼らだけだったから、ということがほとんどだ。

常に他人を助ける

関連する話だが、優秀なエンジニアは引く手あまたで常に忙しい。それでも彼らはいつも助けようとする。そもそも好奇心が旺盛で、人を支えようとする姿勢こそが彼らを優れたエンジニアにしたのだから。彼らがチームにいることは純粋な喜びだ。なぜなら彼らは問題解決者だからだ。

書く

優れたエンジニアの多くは話が上手で、知識を共有することをいとわない。

最高の人たちは、自分の考えをアウトプットする場を持っている。ブログ、登壇、オープンソース、あるいはそれらの組み合わせだ。

文章を書くスキルとプログラミングには強い相関があると思う。私の知る最高のエンジニアは皆、少なくとも一つの自然言語を自在に操る。多くの場合はそれ以上だ。書き方を極めることは考え方を極めることであり、その逆もまた然りだ。人の文章スタイルは、その人の考え方を如実に物語る。文章が混乱していて構造を欠いていれば、コードもそうなる。文章が簡潔で、教育的で、よく構成され、時にウィットに富んでいれば、コードもまたそうなる。

優れたプログラマーは、言葉で遊ぶことに喜びを見出す。

学び続ける

私の知る最高の開発者の中には、60歳を超えている人もいる。彼らの足元にも及ばない。その理由の一つは、彼らが学び続けていることだ。試したことのない新しいツールや、気に入った言語があれば、すぐに学ぶ。そうすることで、彼らはいつも少ない労力で最前線に立ち続けている。

これは当たり前のことではない。多くの人は大学を卒業したり、最初の仕事に就いたりすると、すぐに学ぶことをやめてしまう。学校で教わったやり方が「正しい」やり方だと思い込んでしまう。新しいものはすべて悪いもので、時間をかける価値がないと考える。だから、25歳で「頭の中が引退」している人もいれば、68歳でも頭がみずみずしい人もいる。私はいつか後者になりたいと思っている。

少し関連する話だが、最高のエンジニアはトレンドを追いかけたりはしない。ただ、新しい技術の利点は常に慎重に評価する。もしそれを退けるのであれば、なぜ退けるのか、どんな時ならその技術が良い選択になるのか、そして代替案は何かを、的確に説明できる。

肩書きは関係ない

最高の開発者は、プリンシパルエンジニアともジュニア開発者とも分け隔てなく話す。そこにヒエラルキーはない。彼らは老若問わず、誰からでも学ぼうとする。新人はまだ社内政治に染まっておらず、頭が新鮮だ。物事がなぜ難しいのかを知らないからこそ、創造的な解決策を提案できる。かつての障害がもう存在しないのかもしれず、そういう意味で彼らは素晴らしいインスピレーションの源になる。

評判を築く

良い仕事をするだけでも堅実なエンジニアにはなれるが、良い仕事で知られるようになって初めて、最高のエンジニアの一人になれる。少なくとも（大きな）組織の中ではそうだ。

自分の評判を築く方法はたくさんある。

• （大きな）組織のためにクリティカルなサービスを構築し、リリースした
• 有名なツールを作った
• 人気のあるオープンソースツールにコントリビュートした
• よく言及される本を書いた

なぜ自分の仕事で知られることが重要だと思うのか。上記のすべては、コミュニティにおける自分の影響範囲を広げる手段だからだ。有名な開発者は、そうでない開発者よりもはるかに多くの人に影響を与える。自分一人で書けるコードの量には限りがある。影響力を「スケール」させたいなら、ソートリーダーにならなければならない。

評判を築くのは長期的な目標だ。一夜にして成し遂げられるものではないし、そうである必要もない。そして偶然に築けるものでもない。毎日現場に立ち、仕事を積み重ねる。やがて仕事自体がものを言うようになる。より多くの人があなたとあなたの仕事を信頼し、一緒に働きたいと思うようになる。より名誉あるプロジェクトに携わるようになり、その輪は広がっていく。

以前、最新の仕事はそれまでのすべての仕事を霞ませるべきだ、という考えを聞いたことがある。それができていれば、正しい道を進んでいる証拠だ。

忍耐強くある

コンピュータにも人間にも、忍耐が必要だ。とりわけ自分自身に対して。すべてがすぐにうまくいくわけではなく、人が学ぶには時間がかかる。周りの人が愚かなわけではない。ただ情報が不完全なだけだ。忍耐がなければ、世界中が敵に回ったように感じ、周りの誰もが無能に見えるだろう。そんな場所は惨めだ。自分の賢さが仇になっているのだ。

最高の一人になるには、並外れた忍耐、集中力、そして献身が必要だ。難しい問題を解きたいなら、簡単に気を散らしている暇はない。乗り越えるためにキーボードに向かい直さなければならない。プロジェクトを最後までやり遂げるために、地道な作業を積み重ねなければならない。そして、それを傲慢な嫌な奴にならずにできれば、なお素晴らしい。それが最高の人たちとそれ以外の人を分けるものだ。

コンピュータのせいにしない

ほとんどの開発者は、不安定で一見「ランダム」に見えるバグについて、ソフトウェアや他人、飼い犬、果ては天気のせいにする。

最高の開発者はそうしない。

コンピュータの挙動がどれほど不規則で意地悪に見えようとも、そこには必ず論理的な説明がある。ただ、まだ見つけられていないだけだ。

優れた人たちは、理由が見つかるまで掘り下げ続ける。すぐに見つかることもあれば、ついに見つからないこともあるが、決して外部のせいにはしない。

この姿勢があるからこそ、彼らは驚くほどの進歩を遂げ、他の人が学べないことを学べる。バグを不可解な魔法と決めつければ、それはいつまでも魔法のままだ。

「わからない」と言うことを恐れるな

面接では、候補者が少なくとも一度は「わからない」と言うまで厳しく突っ込んだ。優位に立ちたかったからではない（そう思った人も確かにいただろうが）。そうではなく、彼らの知識の境界に到達したかったのだ。彼らが知っていると思っていることの端っこに、一緒に立ちたかった。多くの場合、私自身も答えを知らなかった。正直なところ、答え自体はどうでもよかった。私が気にしていたのは、候補者がでたらめを言ってごまかすかどうかだった。

最高の候補者は「あ、わからないですね。でも面白い質問です。あえて推測するなら……」と言って、そこから答えを推論していった。それは優れたエンジニアになる素質がある証だ。

「わからない」と言うことを恐れているなら、それは傲慢か、あるいは防衛的な態度から来ている。私はチームにごまかす人間を置きたくない。すべてを知ることはできないと認める方がよい。それを受け入れれば、学ぶ余地が生まれる。「大切なのは、問い続けることをやめないことだ」とアルバート・アインシュタインは言った。

推測するな

「曖昧さに直面したら、推測したい誘惑を断て」。これはPEP 20 – The Zen of Pythonの中でも私のお気に入りのルールの一つだ。

そして、推測したくなる誘惑は本当に、本当に強い。

私自身、何度もその誘惑に負け、自らの野心に足をすくわれた。

推測すると、二つのことが起こりうる。

• 最も良い場合でも、あなたは間違っていて、誤った思い込みがバグを生む。
• 最悪の場合、あなたはたまたま正しい……そして自分を疑うことを二度としなくなる。誤った前提の上にメンタルモデルを築き上げてしまうのだ。これは長い間あなたを苦しめることになる。

繰り返すが、推測したい衝動に抗え。質問し、リファレンスを読み、デバッガを使い、徹底的にやれ。答えを得るために必要なことをやるのだ。

シンプルに保つ

賢いエンジニアは賢いコードを書く。卓越したエンジニアはシンプルなコードを書く。

なぜなら、ほとんどの場合シンプルで十分だからだ。そしてシンプルな方が複雑なものより保守しやすい。もちろん、細部にこだわるべき時も確かにあるが、その違いを見極められるかどうかが、最高の人たちとそれ以外を分ける。

シンプルに保つことで、多くのことを成し遂げられる。正しいことに集中するのだ。

最後に

上に挙げたことはチェックリストでも競争でもない。優れたエンジニアリングは競争ではない。

ただ、ハードワークをスキップできると自分を騙さないでほしい。近道はない。あなたの旅に幸あれ。