プログラミングの学び方 - Geohot

The only advice I have for learning programming is go program.

数多くのプログラミング関連のチャンネルや記事を見てきたが、やはり Geohot の言葉が最も的を射ていると思う。秘訣なんてものは、種明かしをすれば大したことではない——動画を見ただけで突然強くなれるわけではないし、AI の補助があるからといって突然開眼して開発者になれるわけでもない（もちろん AI を上手く活用すればその過程を加速できるのは確かだが）。とにかく書き始めることだ。

この言葉は、彼が Lex Fridman の Podcast に出演した際の切り抜き動画からきている。Podcast 全体は3時間もあるが、フルで見る価値が十分にある。

Geohot とは何者か

簡単に説明すると、彼は PS3 の暗号化キーをクラックして Sony から訴えられ、iPhone の脱獄を行って AT&T 以外のネットワークでも動くようにした人物だ。ここ数年は自動運転ソフトウェアの comma.ai や、ディープラーニングフレームワークの tinygrad（PyTorch のようなものと考えていい）を手がけている。tinygrad は彼が Twitch 配信中に始めた小さなプロジェクトで、1000行以内で実用的なディープラーニングフレームワークを書くことを目標にしていた。YouTube に配信のアーカイブがあるし、GitHub で直接コードを見ることもできる。

彼に関するさらなるエピソードについては、また別の記事で紹介しようと思っている。

どの言語を学ぶべきか

Geohot が推奨する順序は C、アセンブリ言語、Python で、その後に3つの発展ルートがある。

1. 関数型プログラミング（Functional Programming）。例えば Haskell で、純粋関数の世界を理解すること。彼自身、Haskell でシンプルな Scheme インタープリタを書いたことがある。インタープリタを書くことで、プログラミング言語がコンピュータで実際に実行可能な形にどう変換されるのかというプロセスを理解できる。詳細は彼の配信アーカイブを見てほしい。

2. Verilog などの HDL（ハードウェア記述言語）で、ハードウェアの世界を理解すること。ハードウェアとソフトウェアは全く異なるメンタルモデルだ。Geohot は以前、fromthetransistor というリポジトリを作り、トランジスタから段階的にシンプルなブラウザを構築していくアウトラインを書いていた。コンセプトとしては From Nand To Tetris によく似ている。

3. ディープラーニング（Deep Learning）、例えば PyTorch。彼の学び方は論文を直接読み、それを tinygrad 上でなんとか実装してみるというものだ。これは実のところ、ディープラーニングを学ぶ上で最も効果的な方法だ——さもなければ、多くのエンジニアのように既存のフレームワークを適当に当てはめてパラメータをいくつか調整するだけで、背後にある原理には全く無知なままになってしまう。

まず低レイヤーがどう動くかを理解し、C がどのようにアセンブリにコンパイルされるかを知る。そしてアセンブリを学ぶことで、スタック、ヒープ、CPU、RAM といったコンピュータアーキテクチャの核心的な概念が自然と見えてくる。これらを理解して初めて、Python がもたらしてくれるすべての恩恵に感謝できるようになるのだ。

配信から何を学べるか

Geohot の配信からは多くの貴重な知見が得られる。

当時の彼の配信では大半が Vim を使っていた（VS Code の良さに気づいてからは VS Code に乗り換えたが）、タイピングも思考も極めて速い——彼の Vim に対する熟練度や、問題に直面したときにどこから手をつけるべきかが肌で感じられるほどだ。

僕自身、以前はタイピング速度を気にしておらず、手がキーボード上に維持されているかどうかも特に意識していなかったが、これは想像以上に重要なことだ。打鍵が遅いと、思考が中断されやすくなる。これは LLM がまだ日常の開発を代替できなかった頃のインタビューなので、手動でコードを書くことが主流だった。もっとも、Geohot 自身も最近の配信ではあまり手書きしなくなり、Opencode を使うようになっている。

彼のデバッグスタイルも一見の価値がある。神レベルのエンジニアであっても、問題にぶつかれば構文を調べ、ドキュメントを調べる。神秘的な裏技など何もない。配信では大量の試行錯誤が見られる。ここに log を1つ追加し、あそこに log を1つ追加して結果を確認する。シンプルだが効果的だ。彼はコードを極力シンプルに保ち、ほんの少し書いてはすぐに検証する。決して大量に書いてから実行し、問題が起きたときにどこから調べればいいか分からない、といった状態にはしない。

ここ数年で彼は多くのプロジェクトを積み上げてきた。興味があれば、有志がアーカイブしてくれている YouTube チャンネルでお宝を探してみてほしい。

なぜこのような人材は稀有なのか

最近僕も気づいたのだが、機能をろくに作ってもいないうちから DDD を叫び、最新フレームワークを使いたがり、状態管理 A だけでは飽き足らず B や C まで重ね、何かといえばリファクタリングを叫ぶエンジニアが少なくない。しかも彼らのリファクタリングの理解といえば、コードの塊を関数にまとめて別の場所に移動させる程度だ。その結果、機能すら完成していないのに、プロジェクトはすでに複雑すぎて手が出せない状態になってしまう。

フロントエンドの特性上、Bundler なしでウェブページを書くのは確かに少々窮屈だが（それでも可能ではある）、多くのプロジェクトにおいて、そこまで派手な装飾や過剰な抽象化は本当に必要ない。

Geohot はかつて半ば冗談で、質の高い Pull Request を送ってくれるなら、人間だろうが猿だろうが気にしないし、給料をバナナで払ってもいいと語っていた。

僕の10年のキャリアの中で、それぞれの専門領域に非常に深い理解を持つエンジニアとは何十人も一緒に仕事をしてきたが、低レイヤーまで徹底的に理解しているエンジニアには、たった一人しか出会ったことがない。そうした人物と一緒に仕事をすると、問題を見る視点、デバッグの方向性、「複雑さ」に対する許容度が、一般のエンジニアとは明らかに異なることがわかる。