10,000時間のプログラミングを振り返って

2021/08/23 09:53

Matt Rickard
Kubernetes開発者ツールの構築および保守していた元Googleのソフトウェアエンジニア

この記事は、著者の許可を得て配信しています。
 Reflections on 10,000 Hours of Programming

どんな技術でも、世界レベルの専門知識を得るためには、正しい方法で、合計10,000時間ほど時間をかけることが重要である

-マルコム・グラッドウェル『Outliers』より

まあ、確かに私は世界的な専門家ではありませんが、プログラミングに10,000時間ほど費やしてきました。それで今回ここでは、私のプログラミングに関する31の考察を紹介したいと思います。

これらは純粋なコーディングについての考察であり、「プログラミングは人である」や「上級技術リーダーになるには」といった教訓めいたものは書いていません（そういったものは間違いなくキャリアにとっては、より重要ですが、この記事のテーマではないのでそういう内容は書いていません）。

今回のこの記事は、10,000時間、意図的にコードを書くことだけについて書いています。ほとんどが初心者には当てはまらないことだと思います。またこれらの考察は、キャリアに関してのアドバイスではありません。良いバンドマンになるためのレッスンではなく、もっと優れたテクニックを持つギタリストになるためのレッスンだと思ってください。今回の記事は、自分自身がよりよいプログラマーになるためについてのものです。

StackOverflowで答えを見つけるよりも、ソースを閲覧したほうが早いことがほとんどである。
多くの場合、あなたが取り組んでいることは、インターネット上に答えがないものである。それはたいてい、その問題が難しい問題である、もしくは重要な問題であるか、あるいはその両方であることを意味している。
できる限り多くのコードを削除する。
一般的にシンタックスシュガーは悪いものが多い。
「シンプルに」が難しい。
様々なツールを持っていて、どのツールを使えばいいのかを知っていること。
gitやbashのようなよく使われているツールの内部構造を知る（gitのリベースやマージのような面倒な作業から逃れることができる）。
繰り返されるワークフローのために、自分でツールを作成する。自分で作ったツールを使うことほど速いものはない（参考：自分で作ったソフトウェア）。
最高レベルの人からだけ学ぶ。私がGoを学んでいるとき、私は標準ライブラリを読んでいた。
もしそれが醜いものに見えたら、それはたいていひどい間違いである。
docstringではないコメントを書かなければならない場合は、おそらくリファクタリングされるべきものである。コメントの新しい行が増えるたびに、この確率は高まる。(少しニュアンスの違う考え方として、Linux Kernel Documentationがある)
プログラムが本番でどのように動くのかを理解していないということは、プログラム自体を理解していないということ。今まで私が出会った優秀なエンジニアは、自分のプログラムがあらゆる環境でどのように動作するかをしっかり把握していた。
上記のルールは、ビルドパイプラインにも当てはまる。
他の人のコードを使う時は誠実な態度で。
その結果：世の中で作られているほとんどのコードはひどいものばかりである。もっと優れたバージョンを自分で書く方が簡単な場合もある。
大まかな目安：簡単に書き換えられるような小さなライブラリや、小さいはずの大きなライブラリに直接依存してはいけない。
ルールを破るタイミングを知る。「同じことを繰り返さない」というようなルールでは、多少のディペンデンシーよりも多少の繰り返しのほうが良い場合もある。
コードをモジュール、パッケージ、関数に整理することは重要です。APIの境界がどこにあるのかを知ることは本当に重要であり、芸術である。
最も効率的なツールを選ぶことが多いが、自分が知っているものを選ぶことも大切である。Arch Linux は現代の開発者にとって最も効率的なオペレーティングシステムだろうか？私にとってはそうだが、多くの人にとってはそうではないはずである。acmeを使うべきだろうか？あなたがRob Pike氏（カナダ出身のソフトウェア工学者でありソフトウェア作家。acmeを設計・実装した）なら使うべきだね。
循環的複雑度は避ける。初心者のコーダーは、手遅れになるまで、ディペンデンシーグラフがややこしくなっていることにさえ気づかない。
深いネスト条件を避ける。条件テストと命名規則については常識的に考えるべき。
変数は正しく命名すべき。これもアートである。
まれに、コンパイラの問題であることもある。そうでなければ、だいたいDNSの問題である。
難解な言語機能を使うのは控えめに、しかし使うべき時には使う、それがポイントである。
技術は平等には普及しない。例えば、フロントエンドの開発者が初心者のエンジニアから学べることはたくさんある（特に、すべてがコンパイルされるようになった今では）。同じように、JavaScriptの開発者がクラウドエンジニアに教えられるUXやユーザビリティの機能もある。
結局、異なる種類のエンジニアは、世界を違った目で見ているということである。
他のプログラマーよりも10倍効率的に稼働できるプログラマーもいる。私は10倍のプログラマーでもあったし、-1倍のプログラマーでもあったという、両方を経験しているので分かる。
10倍のプログラマーと10倍の社員の間には相関関係はない（マイナスの相関関係はあるかもしれないが）。
良いAPIは使いやすく、悪用されにくい。
コンフィギュレーションサイクルは、ハードコードされた値から、環境変数、CLIフラグ、コンフィギュレーションファイル、テンプレート化されたコンフィギュレーションファイル、DSL、一般的なbashスクリプト、そしてまたハードコードされた値へと進む。コンフィギュレーションの七角形の中のどこに自分がいるのかを知る。
抽象化されたすべてのレイヤーは、マーリアビリディがある。根本的な壁にぶつかったとき、答えは抽象化のレイヤーを下げることだったりするのだ。決して表面的な問題というわけではない

では、私は、10,000時間をどういうことに費やしてきたのでしょうか。私は約15年間、プログラミングに携わってきました。最近までは、GoogleのKubernetesや未公開株式投資会社であるBlackstoneでプロのソフトウェア・エンジニアとして働いていました。それ以前は、大学のほとんどの時間を図書館で過ごし、証明（数学を専攻していた私はこれを書かないといけなかったのです）を書く代わりに自分のプロジェクトのためのプログラムを書いていました。それ以前は、RuneScapeでボットネットを実行したり、iPhone用のラテン語翻訳アプリを書いたり（そのおかげで、ラテン語の試験で良い点数が採れました）、独自のコンフィギュレーション言語を書いたり、webクリッパーを作ったり、デスクトップをライシングしたりと、様々なことに取り組んでいました。

10,000時間のために、私は何をしていたのでしょうか？一番最近では分散システムに関する仕事をしていましたが、スタックよりもコードを書いていました。PHP、JavaScript、Go、Ruby、Python、C#、Java、Swiftなどの言語、フロントエンド、バックエンド、モバイル、カーネル、クラウド、オプス、そしてITも。また、Kubernetesのような大規模なオープンソースプロジェクトに携わり、サブプロジェクトにも携わることで、自分のコードを優秀なエンジニアたちに査読してもらうことができました。