プログラムを頭の中に持つ

2007年8月

自分のコードに集中して取り組む優秀なプログラマーは、数学者が取り組んでいる問題を頭の中に持つように、コードを頭の中に持つことができます。数学者は、小学生が教えられているように、紙に書いて問題を解くわけではありません。彼らは頭の中でより多くのことを行います。彼らは、自分が育った家の記憶を歩き回ることができるように、問題空間を十分に理解しようとします。プログラミングは、その最良の状態では同じです。あなたはプログラム全体を頭の中に持ち、自由に操作することができます。

これは、プロジェクトの開始時に特に重要です。なぜなら、最初は最も重要なことは、自分がやっていることを変更できることだからです。単に問題を別の方法で解決するだけでなく、解決しようとしている問題を変えることです。

あなたのコードは、あなたが探求している問題に対するあなたの理解です。ですから、コードを頭の中に持っているときだけ、あなたは本当に問題を理解しているのです。

プログラムを頭の中に置くのは簡単ではありません。数ヶ月間プロジェクトを離れると、戻ってきたときに本当に理解するまでに数日かかることがあります。プログラムを積極的に開発している場合でも、毎日仕事を始めるときに頭の中にロードするのに30分かかります。そして、それは最良の場合です。典型的なオフィス環境で働く普通のプログラマーは、このモードに入ることがありません。あるいは、より劇的に言えば、典型的なオフィス環境で働く普通のプログラマーは、自分が解決しようとしている問題を本当に理解することはありません。

最高のプログラマーでさえ、常に自分が取り組んでいるプログラム全体を頭の中にロードしているわけではありません。しかし、役立つ方法があります。

**気を散らすものを避ける。**気を散らすものは、多くの種類の仕事に悪影響を及ぼしますが、特にプログラミングには悪影響を及ぼします。なぜなら、プログラマーは、自分が処理できる詳細の限界で動作する傾向があるからです。

気を散らすものの危険性は、その長さではなく、脳をどれだけ混乱させるかに依存します。プログラマーは、オフィスを出てサンドイッチを取りに行っても、頭の中のコードを失うことはありません。しかし、間違った種類の割り込みは、30秒であなたの脳を消し去ってしまう可能性があります。

奇妙なことに、予定された割り込みは、予定外の割り込みよりも悪い場合があります。1時間後に会議があることを知っていれば、難しい作業を始めることさえしません。

**長時間作業する。**プログラムの作業を開始するたびに固定コストがかかるため、短いセッションを何度も行うよりも、長いセッションを数回行う方が効率的です。もちろん、疲れてバカになるポイントが来ます。これは人によって異なります。36時間ぶっ通しでハッキングしている人を知っていますが、私が今までにできたのは18時間ぐらいで、12時間以内の塊で作業するのが一番です。

最適なのは、物理的に耐えられる限界ではありません。プロジェクトを分割することには、コストだけでなく、利点もあります。休憩後に問題に戻ると、無意識のうちに答えが待っていることに気づくことがあります。

**簡潔な言語を使用する。**より強力なプログラミング言語は、プログラムを短くします。そして、プログラマーは、少なくとも部分的には、自分が使っている言語でプログラムを考えます。言語が簡潔であればあるほど、プログラムは短くなり、頭の中にロードして保持するのが容易になります。

強力な言語の効果を拡大するには、ボトムアッププログラミングと呼ばれるスタイルを使用することができます。これは、プログラムを複数のレイヤーで記述し、下位のレイヤーが上位のレイヤーのプログラミング言語として機能するものです。これを正しく行うと、最上位のレイヤーだけを頭の中に保持するだけで済みます。

**プログラムを書き直す。**プログラムを書き直すと、多くの場合、よりクリーンな設計になります。しかし、たとえそうじゃなくても、利点があります。プログラムを書き直すには、プログラムを完全に理解する必要があるため、プログラムを頭の中にロードするのにこれほど良い方法はありません。

**再読可能なコードを書く。**すべてのプログラマーは、読みやすいコードを書くことが良いことだと知っています。しかし、あなた自身が一番重要な読者です。特に最初は、プロトタイプは自分自身との会話です。そして、自分自身のために書くときは、優先順位が異なります。他の人向けに書いている場合は、コードをあまりにも密にすることは避けたいかもしれません。プログラムのいくつかの部分は、導入の教科書のように、ものを広げて書くと、最も読みやすくなるかもしれません。一方、コードを頭の中に簡単にロードできるようにするためにコードを書いている場合は、簡潔さを目指すのが最善かもしれません。

**少人数で作業する。**頭の中でプログラムを操作すると、自分のコードの端でビジョンが止まってしまう傾向があります。他の部分は、それほど理解しておらず、さらに重要なことに、自由にすることができません。そのため、プログラマーの人数が少なければ少ないほど、プロジェクトはより完全に変異することができます。プログラマーが一人しかいない場合、最初の段階ではよくあることですが、包括的な再設計を行うことができます。

**複数の人が同じコード部分を編集しないようにする。**他人のコードは、自分のコードほど理解できません。どんなに徹底的に読んでも、読んだだけで、書いたわけではありません。そのため、コードの一部が複数の作者によって書かれた場合、誰も単一の作者ほど理解していません。

そして、もちろん、他の人が作業しているものを安全に再設計することはできません。許可を求める必要があるということだけではありません。そのようなことを考えることさえ許しません。複数の作者がいるコードを再設計することは、法律を変えるようなものです。自分だけで制御できるコードを再設計することは、曖昧な画像の別の解釈を見るようなものです。

複数の人をプロジェクトに投入したい場合は、プロジェクトをコンポーネントに分割し、それぞれを一人に割り当てます。

**小さく始める。**プログラムは、慣れていくにつれて、頭の中に保持しやすくなります。完全に探求したと確信したら、一部をブラックボックスとして扱うことができます。しかし、プロジェクトを初めて作業するときは、すべてを見なければなりません。問題が大きすぎると、なかなか包含することができません。そのため、大きく複雑なプログラムを書く必要がある場合、最初に仕様を書くのではなく、問題のサブセットを解決するプロトタイプを書くのが最善の方法かもしれません。計画の利点は何であれ、プログラムを頭の中に保持できることの利点に勝ることはほとんどありません。

プログラマーが偶然に8つのポイントすべてを達成してしまうことがいかに多いか、驚くべきことです。新しいプロジェクトのアイデアが浮かんだのですが、正式に承認されていないため、彼は余暇時間に行わなければなりませんでした。その時間は、気を散らすものがなかったため、より生産的であることが判明しました。新しいプロジェクトへの熱意に突き動かされ、彼は長時間ぶっ通しで作業しました。最初は単なる実験だったため、彼は「プロダクション」言語ではなく、「スクリプト」言語を使用しました。実際には、はるかに強力な言語です。彼はプログラムを何度も完全に書き直しました。これは、公式のプロジェクトでは正当化できませんが、これは愛情のこもった作業であり、彼は完璧にしたいと思っています。そして、彼以外に見る人がいないので、彼はメモ書き以外のコメントはすべて省略しました。彼は必然的に少人数のグループで作業しました。なぜなら、彼はまだ誰にもそのアイデアを話していなかったか、またはあまりにも有望ではないため、他に誰も作業することを許されていなかったからです。グループがいるとしても、彼らは同じコードを複数の人が編集することはできません。なぜなら、コードは速すぎるため、それが不可能だからです。そして、プロジェクトは小さく始まります。なぜなら、アイデアは最初は小さいからです。彼はただ、試したいクールなハックを持っているだけです。

さらに驚くべきことに、正式に承認されたプロジェクトで、8つのすべてを間違えるものがどれだけあるかです。実際、ほとんどの組織でソフトウェアがどのように書かれているかを見ると、彼らは故意に間違ったことをしようとしているかのようです。ある意味では、彼らはそうしています。組織の定義的な特徴の1つは、個々の人を交換可能な部品として扱うことです。これは、戦争をするなど、より並列化可能なタスクにはうまく機能します。歴史のほとんどにおいて、訓練されたプロの兵士の軍隊は、どんなに勇敢であろうとも、個々の戦士の軍隊に勝つことができると期待されていました。しかし、アイデアを持つことは、それほど並列化可能ではありません。そして、それがプログラムなのです。アイデアです。

組織が個々の天才に依存することを嫌うのは事実であるだけでなく、それはトートロジーです。それは、組織の定義の一部であり、そうではありません。少なくとも、現在の組織の概念では。

交換可能であることを要求せずに、個人の努力を組み合わせた新しい種類の組織を定義できるかもしれません。市場は、そのような組織の形態であると主張することができますが、市場を退化したケース、つまり組織が不可能な場合にデフォルトで得られるものとして説明する方が正確かもしれません。

おそらく、私たちができる最善のことは、組織のプログラミング部分を他の部分とは異なる方法で動作させるような、何らかのハックでしょう。おそらく、最適な解決策は、大企業が社内でアイデアを開発しようとせず、単に購入することでしょう。しかし、解決策が何であれ、最初のステップは、問題があることに気づくことです。「ソフトウェア会社」というフレーズ自体に矛盾があります。2つの単語は、反対の方向に引っ張られています。大企業の優秀なプログラマーは、組織と対立することになります。なぜなら、組織はプログラマーが目指すものを防ぐように設計されているからです。

優秀なプログラマーは、それでも多くのことを成し遂げます。しかし、多くの場合、彼らを雇っている組織に対する反逆行為に近いです。プログラマーの行動が、彼らがしている仕事の要求によって駆り立てられていることを、より多くの人が理解すれば、役立つかもしれません。彼らが長時間ぶっ通しで働き、他のすべての義務を放棄し、最初に仕様を書くのではなく、直接プログラミングに飛び込み、すでに動作しているコードを書き直すのは、彼らが無責任だからではありません。彼らが一人で働くことを好み、挨拶に来た人がドアを開けて顔を出すと怒鳴りつけるのは、彼らが不親切だからではありません。この一見ランダムな迷惑な習慣の集まりには、1つの説明があります。プログラムを頭の中に持つことの力です。

これが大企業に役立つかどうかは別として、確かに競合他社に役立ちます。大企業の最も弱い点は、個々のプログラマーに素晴らしい仕事をすることを許さないことです。そのため、あなたが小さなスタートアップであれば、これが彼らを攻撃する場所です。1つの大きな脳で解決する必要があるような問題に取り組みましょう。

謝辞 Sam Altman、David Greenspan、Aaron Iba、Jessica Livingston、Robert Morris、Peter Norvig、Lisa Randall、Emmett Shear、Sergei Tsarev、Stephen Wolframに、この原稿を読んでいただいたことに感謝します。