- 著者はさまざまな開発者と出会う中で、最高の開発者たちに共通する特徴について考えるようになった
- この記事は、初心者の開発者や成長したい人にインスピレーションを与えるために書かれた観察記録である
まずリファレンス文書を読むこと
- Stack OverflowやLLMを先に探すよりも、まず公式ドキュメントを読む習慣を身につけることが重要である
- Apache、Python、TOMLなどの公式ドキュメントは、実際かなりよく書かれている
- ソースから直接学ぶ習慣は、長期的に大きな助けになる
ツールを深く理解すること
- ツールを「使える」ことと、それを「理解している」ことは別のレベルである
- ツールをよく知る人は、設定の一つひとつを説明できる
- よく理解するには、ツールの:
- 歴史（なぜ作られたのか）
- 現在（誰が保守しているのか）
- 限界（どんなときに合わないのか）
- エコシステム（周辺ツール、ライブラリなど）
をすべて把握していなければならない
- Kafkaなどを主力で使うなら、Redditで見た程度以上には理解しているべきだ
エラーメッセージを丁寧に読むこと
- エラーメッセージをじっくり見れば、そこにヒントが含まれている
- 最高の開発者は、少ない情報からでも問題を推論する
- 問題の80%は、エラーメッセージをしっかり見るだけでも解決できる
問題を細かく分割できること
- 行き詰まるのは誰にでもあることであり、解くには問題を細かく分けられなければならない
- 経験が多い人や問題解決能力に優れた人は、自然に分割できる
- 開発者の中核的な仕事は、結局のところ大きな問題を小さな問題に分けることだ
- 単純な問題を一つずつ着実に解けば、全体の問題も解決できる
恐れずにコードを扱うこと
- 最高の開発者たちは、コードを読むことを恐れない
- 「それは自分の領域ではない」といったことを言わず、とにかく試して学ぶ
- 初めて扱うコードでも、すぐにチーム内の専門家になることが多い
いつも他人を助けること
- 忙しい中でも助けてくれる開発者は、良いチームメンバーであり優れた専門家でもある
- 好奇心と協力的な姿勢は、良い開発者に不可欠な資質である
書くこと
- 優れた開発者は話すのも上手く、考えを文章で表現することもできる
- ブログ、発表、オープンソース活動などを通じて考えを共有する
- 文章力は、思考の構造と直接的につながっている
- うまく書ける人のコードは、構造的で、明確で、ときに機知に富んでいる
学びを止めないこと
- 年齢に関係なく学び続ける人こそ、本当に優れた開発者である
- 新しいツールや言語を試すことにためらいがない
- 最新技術を盲目的に追うのではなく、長所と短所を自分で分析できる
- 若くても固定観念に陥れば成長は止まる
地位にこだわらないこと
- 良い開発者は、肩書きに関係なく誰からでも学ぼうとする
- 新人からでも学ぶことがあるという姿勢を持っている
- 新しい視点を持つ人との対話からインスピレーションを得る
評判を築くこと
- 実力も重要だが、その実力を 知られること も重要である
- 評判は影響力を広げるための手段である
- 次のような方法で評判を築くことができる:
- 重要なサービスを自ら作る、またはデプロイする
- よく知られたツールを開発する
- 有名なオープンソースに貢献する
- よく引用される本を書く
- 評判は一朝一夕で築けるものではなく、継続的な努力と時間が必要である
忍耐力を持つこと
- 人にもコンピュータにも忍耐力が必要である
- 周囲の人は愚かなのではなく、単に情報が足りないだけである
- 忍耐力がなければ不満がたまりやすくなり、協業が難しくなる
- 難しい問題を解決するには、集中力と粘り強さが必要である
コンピュータのせいにしないこと
- 最高の開発者は、決してシステムや外的要因のせいにしない
- 見た目にはランダムに見える問題にも、論理的な理由がある
- 原因を見つけるために最後まで掘り下げる姿勢が重要である
「わかりません」と言えること
- 面接で、あえて「わかりません」と言う瞬間を待ったことがある
- 重要なのは答えそのものではなく、姿勢である
- 最高の候補者は、わからないと認めたうえで推論を始める
- わからないと認める姿勢は、学習の可能性を示している
- 嘘をついたり知ったかぶりをしたりする人は、チームに悪影響を与える
推測しないこと
- PEP 20の哲学のように、曖昧なときは決して推測してはならない
- 推測の危険:
- 間違っていればバグになる
- 当たっていても誤った前提を信じることになり、後で問題を引き起こす
- 確信が持てないなら:
- 質問し
- 文書を読み
- デバッグツールを使い
- 根拠を見つけるべきである
シンプルに保つこと
- 賢い人は賢そうなコードを書き、優れた人はシンプルなコードを書く
- シンプルなコードのほうが保守にはるかに有利である
- 複雑さが必要な場面とそうでない場面を見分けられてこそ、本当の実力である
締めくくりの考え
- この記事はチェックリストではなく、優れたエンジニアリングは競争でもない
- ただし、難しい作業を飛ばせると自分をごまかしてはならない
- 優れた開発者になる道に近道はない
19件のコメント
良い文章をありがとうございます。!!
これはチェックリストではないという言葉に慰められ、近道はないという言葉に勇気づけられます。
会社のプロジェクトを理解していれば、
どの分野のシニア開発者になったとしても
その分野がファームウェアでもアプリでもWebでも、
Web、アプリ、あるいはファームウェアのデバッグログを見ながら
問題がどのように発生したのかをデバッグできるレベルになるのだと思います。
面接のときに私が推測していた振る舞いを思い出しますね
個人的には、「自分が何を作っているのかを常に考えること」も重要だと考えています。
Critical Thinkingという良い用語がありましたね本当に大変参考になりました。良い文章をありがとうございます。
じゃあ、公式ドキュメントをLLMに読ませればいいってことだね！
RTFM: 公式ドキュメントをちゃんと読みましょう。
チェックリストではないと言いながらも、自分のチェックリストにしなければなりませんね。
公式ドキュメントを必ず見るべきだという点に、とても共感します。
コーディングを最初に教えるとき、この人がエラーメッセージを丁寧に読めるかどうかで、プログラマーとしての素質が最初に表れるように思います。
.... エラーやバグは常に存在するものだと認める基本的な認識がない人間こそ、詐欺師なんですよ
文章が難しすぎます..
Webでは。
すべてではありませんが、ほとんどは共感できる項目ですね。
Hacker Newsの意見
推測しないことが、仕事において最も重要
新しいものを扱うときは、リファレンスを深く読む前に少し推測するのを楽しむ
Stack OverflowやLLMに依存せず、直接ソースを参照するのがよい
最高の開発者はあらゆる層の人々とコミュニケーションし、学ぶ
Stack Overflowをうまく活用すれば大いに役立つ
最高のプログラマーはCSのバックグラウンドがなくても優れた成果を出せる
プログラミング以外にも、ビジネスドメインとのコミュニケーションが重要
エラーメッセージを読んで理解することが、問題解決に大いに役立つ
asdfを使ってPython、Go、NodeJSのバージョンを管理するとき、エラーメッセージを通じて問題を解決できたasdfとは何ですか？ 警告を見る必要があります。うーん、絶対に最高になろうとしない姿勢のほうがいい気がしますけどね。書くだの……助けるだの……そんなことを言う人間に限って……