私が知る最高のプログラマーたち
これまでの人生で、たくさんの開発者に会ってきました。最近、こんなことを自問しました。「一流になるには何が必要なんだろう？ 彼らに共通しているものは何だろう？」
どこかの誰かの刺激になればと思い、私たちの仕事において特に優れた人たちに見られた特徴を書き留めました。駆け出しの頃にこのリストがあればよかったのにと思います。この道を歩んでいれば、かなりの時間を節約できたはずです。
リファレンスを読む
若いプログラマーだった頃の自分が、たった一つやっておくべきだったことを挙げるなら、使っているもののリファレンスを読むことです。つまり、Apache Webserver DocumentationやPython Standard Library、あるいはTOML specを読むことです。
Stack Overflowに行かない。LLMに聞かない。推測しない。まっすぐ一次情報に当たるのです。多くの場合、驚くほど読みやすく、よく書かれています。
使う道具を徹底的に知る
優れた開発者は、使っている技術を根本から理解しています。
道具を使えることと、本当の意味でそれを深く理解することは、まったく別です。単なる利用者はあれこれ手探りし、すぐ混乱し、使い方を間違え、設定も最適化できません。
専門家は（リファレンスを読んだうえで）その道具の設定を書き始めます。設定の一行一行を理解していて、同僚に説明できるのです。そこには疑いの余地がありません。
道具をよく知るには、次のことを知っておく必要があります。
- その歴史：誰が作ったのか？ なぜ作ったのか？ どんな問題を解決するためだったのか？
- その現在：誰がメンテナンスしているのか？ どこで働いているのか？ 何に取り組んでいるのか？
- その限界：どんな場合にその道具は適さないのか？ どんなときに壊れるのか？
- そのエコシステム：どんなライブラリがあるのか？ 誰が使っているのか？ どんなプラグインがあるのか？
たとえば、バックエンドエンジニアでKafkaを多用しているなら、Kafkaについて多くを知っていてほしいと思います。Redditで読んだことだけでは足りません。少なくとも、一流のエンジニアになりたいなら、私はそれくらいを期待します。
エラーメッセージを読む
ここでいう「読む」は、エラーメッセージを本当に読み、そこに書かれていることを理解しようとするという意味です。エラーメッセージを前にただ座って、じっくり考えてみてください。すると、エラーメッセージが語りかけてくるようになります。最高のエンジニアは、わずかな文脈から大量の情報を推測できます。エラーメッセージを読むだけで、問題の大半は自力で直せるのです。
そのスキルを持っていない人を助けるときには、まるで超能力のようにも感じられます。「カップを読む」占いのようなものです。
問題を分解する
誰だって、ときには行き詰まります。一流の人は、そこから抜け出す方法を知っています。問題を、消化できる大きさになるまで単純化するのです。これは身につけるのが難しいスキルで、膨大な経験を必要とします。あるいは、もともと問題解決能力が非常に高い、つまり頭が切れるのかもしれません。そうでなければ鍛えることもできますが、難しい問題を分解する以外に道はありません。この世界には、関わっている誰にとっても、一度に解くには難しすぎる問題が存在します。
プロの開発者として働くなら、報酬を受け取っている仕事の大部分は問題を分解することです。うまくできれば、ずるをしているように感じるでしょう。簡単な問題を解き続けて、気づけば終わっているのです。
手を汚すことを恐れない
私が知る最高の開発者たちは、たくさんのコードを読み、触ることを恐れません。「それは自分の担当ではない」とか、「ここでは力になれません」などとは決して言いません。その代わり、まず始めて、学ぶのです。コードはただのコードです。必要なスキルなら、時間と努力をかければ身につけられます。気づく頃には、触れたものなら何でもチームで頼られる人になっています。そもそも、触ることを恐れなかったのが彼らだけだったからです。
いつでも人を助ける
関連する話です。優れたエンジニアは引く手あまたで、いつも忙しくしています。それでも、必ず助けようとします。生まれつき好奇心が強く、人を支えようとする姿勢こそが、そもそも彼らを優れたエンジニアにしたからです。彼らがチームにいるのは本当に楽しいものです。問題を解決してくれる人たちだからです。
書く
最高にすごいエンジニアの多くは、話し上手で、知識を喜んで共有します。
一流の人には、自分の考えを発信する場があります。ブログ、講演、オープンソース、あるいはその組み合わせです。
私は、文章を書く能力とプログラミングには強い相関があると思っています。私が知る最高のエンジニアは皆、少なくとも一つの自然言語を自在に使えます。複数の言語を使える人も珍しくありません。文章の書き方を極めることは、考え方を極めることです。その逆もまた同じです。文章のスタイルには、その人の考え方がよく表れます。わかりにくく、構成がなければ、コードの書き方も同じでしょう。簡潔で、学びがあり、構成が整っていて、ときに機知に富んでいれば、コードも同じようになるはずです。
卓越したプログラマーは、言葉で遊ぶことに喜びを見いだします。
学びを止めない
私が知る最高の開発者の中には、60歳を超えている人もいます。私など、彼らにかかれば簡単に追い抜かれてしまいます。その理由の一つは、学び続けていることです。試したことのない新しい道具があれば、あるいは興味を引かれる言語があれば、彼らは学びます。そうして、大した苦労もなく、いつも状況の最先端にいられるのです。
これは当たり前のことではありません。大学を卒業したり、初めての仕事を始めたりすると、すぐに学ぶのをやめてしまう人は大勢います。学校で教わったやり方が「正しい」のだと思い込み、新しいものはすべて悪く、時間をかける価値がないと考えてしまうのです。だから、25歳なのに「精神的には引退済み」の人もいれば、68歳なのに頭が新鮮なままの人もいます。私はいつか、後者の仲間になりたいと思っています。
これと少し関係しますが、最高のエンジニアは流行を追いません。ただし、新しい技術のメリットは必ず慎重に評価します。採用しないと決めた場合も、なぜなのか、その技術が適しているのはどんな場合か、代替手段には何があるのかを、正確に説明できます。
肩書きは関係ない
最高の開発者は、プリンシパルエンジニアともジュニア開発者とも同じように話します。そこに上下関係はありません。若い人からも年長者からも学ぼうとします。新しく入った人は、まだ社内政治に染まっておらず、柔軟な視点を持っていることがよくあります。なぜ物事が難しいのかを知らないからこそ、創造的な解決策を提案できます。過去にあった障害は、もう存在しないかもしれません。だからこそ、彼らは大きな刺激を与えてくれるのです。
評判を築く
良い仕事をすれば、堅実なエンジニアにはなれます。しかし、最高の一人になるには、良い仕事をしていると知られていなければなりません。少なくとも、（より大きな）組織の中では。
自分の評判を築く方法は、たくさんあります。
- （より大きな）組織にとって重要なサービスを構築し、リリースした。
- 有名なツールを書いた。
- 人気のあるオープンソースツールに貢献している。
- 何度も言及される本を書いた。
なぜ仕事で知られることが重要だと思うのでしょうか。上に挙げたものはすべて、コミュニティにおける影響範囲を広げる方法だからです。有名な開発者は、無名の開発者よりはるかに多くの人に影響を与えます。書けるコードの量には限界があります。影響力を「スケール」させたいなら、思想的リーダーにならなければなりません。
評判を築くのは長期的な目標です。一夜にして実現するものではありませんし、そうである必要もありません。そして、偶然そうなることもありません。毎日現場に行き、仕事をするのです。時間が経てば、仕事そのものが語ってくれます。あなたとあなたの仕事を信頼する人が増え、一緒に働きたいと思ってくれるようになります。より名誉あるプロジェクトに関わるようになり、その輪は広がっていきます。
以前、「最新の仕事が、それまでに手がけたすべてを覆い隠すべきだ」という考えを聞いたことがあります。それは、正しい方向に進んでいる証拠でしょう。
忍耐力を持つ
コンピューターにも、人間にも、忍耐が必要です。特に、自分自身に対しては。すべてがすぐにうまくいくわけではありませんし、人が学ぶには時間がかかります。周りの人が愚かなわけではありません。情報が足りていないだけです。忍耐がなければ、世界が自分に敵対していて、周りは皆無能だと感じるようになります。そこは惨めな場所です。頭が切れすぎて、かえって自分の首を絞めています。
一流になるには、途方もない忍耐力と集中力、そして献身が必要です。難しい問題を解きたいなら、簡単に気を散らしている余裕はありません。乗り越えるまでキーボードに戻り続けなければなりません。プロジェクトを最後までやり遂げるために、努力を重ねる必要があります。それを、尊大な嫌な奴にならずにできるなら、なおさら素晴らしいことです。そこが、一流とその他大勢を分けるところです。
コンピューターのせいにしない
ほとんどの開発者は、不安定で、一見「ランダム」に見えるバグがあると、ソフトウェアや他人、飼い犬、あるいは天気のせいにします。
最高の開発者は、そうしません。
コンピューターの挙動がどれほど気まぐれで、いたずらをしているように見えても、必ず論理的な説明があります。まだ見つけられていないだけです。
一流の人は、理由が見つかるまで掘り続けます。すぐには見つからないかもしれません。一生見つからないかもしれません。それでも、外的な状況のせいには決してしません。
この姿勢があれば、驚くほど前進でき、他の人が学べないことも学べるようになります。バグを理解不能な魔法だと思い込めば、それはいつまでも魔法のままです。
「わかりません」と言うことを恐れない
採用面接では、候補者が少なくとも一度は「わかりません」と言うまで、厳しく質問していました。自分が優位に立っているように見せたかったからではありません（そう受け取った人も確かにいましたが）。そうではなく、相手の知識の境界にたどり着きたかったのです。相手が知っていると思っていることの、その端に一緒に立ちたかった。私自身も答えを知らないことがよくありました。正直に言えば、答えそのものには関心がありませんでした。気にしていたのは、面接で人がでたらめを並べて切り抜けようとすることです。
最高の候補者はこう言いました。「ええと、わかりません。でも面白い質問ですね！ 推測するなら……」そして、答えを推論していきました。それは、優れたエンジニアになる可能性があるというサインです。
「わかりません」と言うのが怖いなら、傲慢さや防衛的な姿勢から来ています。私は、でたらめを言う人をチームに置きたくありません。何でも知ることはできないと認めたほうがいいのです。それを受け入れれば、学べるようになります。アルベルト・アインシュタインはこう言いました。「大切なのは、質問するのをやめないことだ」
推測しない
「曖昧さに直面したら、推測したくなる誘惑を拒む」。これはPEP 20 ― Pythonの禅にある、私のお気に入りのルールの一つです。
それでも、推測したくてたまらなくなります。
私も何度もそうしてきました。そして、自分の野心に負けて失敗しました。
推測すると、二つのことが起こり得ます。
- 最善の場合は、あなたが間違っていて、その誤った前提がバグにつながります。
- 最悪の場合は、あなたが正しいことです……そして、自分を立ち止まって疑うことが二度となくなります。間違った前提に基づいて、自分のメンタルモデルを築いてしまうのです。それは長い間、あなたを苦しめるかもしれません。
繰り返しますが、推測したい衝動には抗ってください。質問し、リファレンスを読み、デバッガーを使い、徹底的に調べる。答えを得るために必要なことをしてください。
シンプルに保つ
頭の切れるエンジニアは、頭の切れたコードを書きます。卓越したエンジニアは、シンプルなコードを書きます。
たいていの場合、シンプルで十分だからです。そして、シンプルなものは複雑なものより保守しやすい。正しく実装することが本当に重要な場合もありますが、その違いを知っていることが、一流とその他大勢を分けます。
シンプルに保つだけで、実に多くのことを成し遂げられます。正しいことに集中しましょう。
最後に
ここまでの内容はチェックリストでも、競争でもありません。優れたエンジニアリングはレースではないのです。
ただ、努力を省けると思って自分を欺かないでください。近道はありません。あなたの旅に幸運を祈ります。