自分の頭の中でプログラムを保持する

2007年8月

自分のコードに集中的に取り組む優れたプログラマーは、数学者が取り組んでいる問題を頭の中で保持するのと同じように、それを頭の中に保持することができます。数学者は、学校の子供たちが教えられるように、紙の上で問題を解くことによって質問に答えることはありません。彼らは、問題空間を十分に理解しようとし、成長した家の記憶の周りを歩くようにそれを歩き回ることができるのです。プログラミングも最良の状態では同じです。あなたはプログラム全体を頭の中に保持し、自由に操作することができます。

これは特にプロジェクトの初めに価値があります。なぜなら、最初に最も重要なことは、あなたがやっていることを変更できることだからです。問題を異なる方法で解決するだけでなく、解決している問題自体を変更することです。

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

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

最も優れたプログラマーでさえ、常に自分が取り組んでいるプログラム全体を頭の中にロードしているわけではありません。しかし、助けになることができることがあります：

気を散らさない。 気を散らすことは多くの種類の仕事にとって悪いですが、特にプログラミングにとっては悪いです。なぜなら、プログラマーは扱える詳細の限界で操作する傾向があるからです。

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

奇妙なことに、予定された気を散らすことは、予定外のものよりも悪いかもしれません。1時間後に会議があることがわかっていると、難しいことに取り組むことすら始めません。

長い時間働く。 プログラムに取り組むたびに固定コストがかかるため、短いセッションを多く行うよりも、いくつかの長いセッションで作業する方が効率的です。もちろん、疲れて愚かになるポイントが来るでしょう。これは人によって異なります。36時間連続でハッキングする人もいますが、私が管理できるのは約18時間で、最も効果的に働くのは12時間以内の塊です。

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

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

強力な言語の効果を高めるために、ボトムアッププログラミングと呼ばれるスタイルを使用することができます。これは、複数の層でプログラムを書くスタイルで、下層が上層のプログラミング言語として機能します。これを正しく行うと、最上層だけを頭の中に保持すればよくなります。

プログラムを再構築し続ける。 プログラムを再構築することは、しばしばクリーンなデザインを生み出します。しかし、たとえそれがそうでなくても利点があります。再構築するためにはプログラムを完全に理解する必要があるため、プログラムを頭の中にロードするための最良の方法はありません。

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

小さなグループで働く。 プログラムを頭の中で操作するとき、あなたの視界は所有しているコードの端で止まる傾向があります。他の部分はあまり理解できず、より重要なことに、自由に扱うことができません。したがって、プログラマーの数が少ないほど、プロジェクトはより完全に変化することができます。最初は一人のプログラマーしかいない場合、包括的な再設計を行うことができます。

同じコードの編集を複数の人にさせない。 他の人のコードを自分のコードほど理解することはありません。どれだけ徹底的に読んでも、あなたはそれを書いたのではなく、ただ読んだだけです。したがって、複数の著者によって書かれたコードの一部は、単一の著者が理解するほどには理解されません。

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

プロジェクトに複数の人を参加させたい場合は、それをコンポーネントに分割し、それぞれを一人に割り当ててください。

小さく始める。 プログラムは、あなたがそれに慣れるにつれて、頭の中に保持しやすくなります。完全に探求したと感じたら、部分をブラックボックスとして扱い始めることができます。しかし、プロジェクトに取り組み始めたときは、すべてを見なければなりません。あまりにも大きな問題から始めると、決してそれを包括することができないかもしれません。したがって、大きくて複雑なプログラムを書く必要がある場合、最良の方法は仕様を書くことではなく、問題のサブセットを解決するプロトタイプを書くことかもしれません。計画の利点が何であれ、プログラムを頭の中に保持できる利点がしばしばそれを上回ります。

プログラマーが偶然にすべての8つのポイントを達成することがどれほど多いかは驚くべきことです。誰かが新しいプロジェクトのアイデアを持っていますが、公式に承認されていないため、オフアワーにそれを行わなければなりません。これが、気を散らすものがないため、より生産的であることが判明します。新しいプロジェクトへの熱意に駆り立てられ、彼は何時間も連続して取り組みます。最初は単なる実験であるため、「生産」言語の代わりに単なる「スクリプト」言語を使用します。これは実際にははるかに強力です。彼はプログラムを何度も完全に再構築します。それは公式プロジェクトでは正当化されないでしょうが、これは愛の労働であり、彼はそれを完璧にしたいのです。そして、誰もそれを見ることはないので、彼は自己メモのようなコメントを省略します。彼は小さなグループで働かざるを得ません。なぜなら、彼は他の誰にもそのアイデアについてまだ話していないか、それがあまりにも期待外れに見えるため、他の誰もそれに取り組むことが許可されていないからです。たとえグループがあっても、コードがあまりにも早く変わるため、複数の人が同じコードを編集することはできません。そして、プロジェクトは最初は小さいアイデアから始まります。彼はただ試してみたいクールなハックを持っているだけです。

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

組織が個々の天才に依存することを嫌うのは単なる事実ではなく、それは同義反復です。組織の定義の一部はそうでないことです。少なくとも私たちの現在の組織の概念では。

個人の努力を交換可能でなく結びつける新しい種類の組織を定義できるかもしれません。市場はそのような形の組織の一つであると言えるかもしれませんが、組織が不可能な場合にデフォルトで得られるものとして市場を説明する方が正確かもしれません。

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

優れたプログラマーはそれでも多くのことを成し遂げることができます。しかし、それにはしばしば、彼らを雇用する組織に対する反乱の行為が必要です。プログラマーの行動が彼らの仕事の要求によって駆動されていることをより多くの人々が理解すれば、役立つかもしれません。彼らが他のすべての義務を無視し、最初に仕様を書くのではなくプログラミングに直行し、すでに動作しているコードを再構築するのは、無責任だからではありません。彼らが一人で働くことを好むのは、友好的でないからではありません。ドアに顔を出して挨拶する人にうなり声を上げるのもそうです。この一見無作為な煩わしい習慣の集まりには、単一の説明があります：プログラムを頭の中に保持する力です。

これを理解することが大規模な組織に役立つかどうかは別として、競争相手には確実に役立つでしょう。大企業の最も弱い点は、個々のプログラマーが素晴らしい仕事をすることを許さないことです。したがって、あなたが小さなスタートアップであるなら、これは彼らに攻撃する場所です。一つの大きな頭脳で解決しなければならない問題に取り組んでください。

感謝をサム・アルトマン、デビッド・グリーンスパン、アーロン・アイバ、ジェシカ・リビングストン、ロバート・モリス、ピーター・ノーヴィグ、リサ・ランドール、エメット・シア、セルゲイ・ツァレフ、スティーブン・ウルフラムに、草稿を読んでくれたことに感謝します。