ハッカーと画家

2003年5月

(このエッセイはハーバード大学でのゲスト講義に由来し、ノースイースタン大学での以前の講演を取り入れています。)

コンピュータサイエンスの大学院を修了した後、私は絵画を学ぶために美術学校に行きました。コンピュータに興味を持つ人が絵画にも興味を持つことに驚く人が多いようでした。彼らは、ハッキングと絵画は非常に異なる種類の仕事であり、ハッキングは冷たく、正確で、体系的であり、絵画は原始的な衝動の狂乱した表現であると考えているようでした。

これらのイメージはどちらも間違っています。ハッキングと絵画には多くの共通点があります。実際、私が知っているさまざまなタイプの人々の中で、ハッカーと画家は最も似ている人々の一部です。

ハッカーと画家の共通点は、彼らが両方とも作り手であるということです。作曲家、建築家、作家と同様に、ハッカーと画家が試みているのは良いものを作ることです。彼らは研究をしているわけではありませんが、良いものを作る過程で新しい技術を発見することがあれば、それはさらに良いことです。

私は「コンピュータサイエンス」という用語が好きではありません。その主な理由は、それが存在しないからです。コンピュータサイエンスは、歴史の偶然によって一緒に投げ込まれた tenuously 関連した分野の寄せ集めのようなもので、ユーゴスラビアのようです。一方には、本当に数学者である人々がいて、彼らは自分たちのやっていることをコンピュータサイエンスと呼んで、DARPAの助成金を得ようとしています。真ん中には、コンピュータの自然史のようなものに取り組んでいる人々がいて、例えばデータをネットワークを通じてルーティングするためのアルゴリズムの挙動を研究しています。そして、もう一方の極には、興味深いソフトウェアを書くことを試みているハッカーがいて、彼らにとってコンピュータは建築家にとってのコンクリートや画家にとっての絵の具のような表現の媒体に過ぎません。まるで数学者、物理学者、建築家がすべて同じ学部にいるかのようです。

時々、ハッカーが行うことは「ソフトウェアエンジニアリング」と呼ばれますが、この用語も同様に誤解を招くものです。優れたソフトウェアデザイナーは、建築家がエンジニアでないのと同じように、エンジニアではありません。建築と工学の境界は明確に定義されているわけではありませんが、そこには境界があります。それは「何をするか」と「どうやってするか」の間にあります：建築家は何をするかを決定し、エンジニアはそれをどうやって実現するかを考えます。

「何をするか」と「どうやってするか」はあまりにも分けて考えるべきではありません。どうやって実現するかを理解せずに何をするかを決めようとすると、問題を引き起こすことになります。しかし、ハッキングは確かに単に仕様を実装すること以上のものです。最良の形では、仕様を作成することです—ただし、それを実装することが最良の方法であることがわかります。

いつの日か「コンピュータサイエンス」が、ユーゴスラビアのようにその構成要素に分解されるかもしれません。それは良いことかもしれません。特にそれが私の故郷であるハッキングの独立を意味するならば。

これらの異なるタイプの仕事を一つの学部にまとめることは、管理上便利かもしれませんが、知的には混乱を招きます。これが私が「コンピュータサイエンス」という名前が好きでないもう一つの理由です。中間にいる人々は、実験的な科学のようなことをしていると言えるかもしれません。しかし、両端にいるハッカーと数学者は、実際には科学を行っているわけではありません。

数学者たちはこれに気を病んでいるようには見えません。彼らは数学学部の他の数学者たちと同じように定理を証明する作業に喜んで取り組み、おそらくすぐに自分たちが働いている建物の外に「コンピュータサイエンス」と書かれていることに気づかなくなります。しかし、ハッカーにとってこのラベルは問題です。彼らが行っていることが科学と呼ばれると、彼らは科学的に行動しなければならないと感じるのです。そのため、彼らが本当にやりたいこと、つまり美しいソフトウェアを設計することをする代わりに、大学や研究所のハッカーは研究論文を書くべきだと感じるのです。

最良のケースでは、論文は単なる形式的なものです。ハッカーはクールなソフトウェアを書き、それについての論文を書き、その論文がソフトウェアによって表される成果の代理となります。しかし、この不一致はしばしば問題を引き起こします。美しいものを作ることから、研究論文のためのより適した主題を作ることに向かって漂流するのは簡単です。

残念ながら、美しいものが常に論文のための最良の主題になるわけではありません。第一に、研究は独創的でなければなりません—そして、博士論文を書いたことがある人なら誰でも知っているように、未開の領域を探求していることを確実にする方法は、誰も欲しがらない土地を確保することです。第二に、研究は実質的でなければなりません—そして、厄介なシステムはより肉厚な論文を生み出します。なぜなら、物事を成し遂げるために克服しなければならない障害について書くことができるからです。間違った仮定から始めることほど肉厚な問題を生み出すものはありません。AIのほとんどはこのルールの例です。知識が抽象概念を表す述語論理式のリストとして表現できると仮定すると、これを機能させる方法について多くの論文を書くことになります。リッキー・リカードが言っていたように、「ルーシー、君にはたくさんの説明が必要だ。」

美しいものを作る方法は、既存のものに微妙な調整を加えるか、既存のアイデアを少し新しい方法で組み合わせることです。この種の作業は研究論文で伝えるのが難しいです。

では、なぜ大学や研究所はハッカーを出版物で評価し続けるのでしょうか？それは「学業適性」が単純な標準化テストで測定されるのと同じ理由です。これらのテストは適用が簡単で、ある種の効果がある簡単なテストほど魅力的なものはありません。

ハッカーが実際にやろうとしていること、美しいソフトウェアを設計することを測定するのははるかに難しいです。良いデザインセンスが必要です。人々が良いデザインを認識する能力と、それを認識できる自信との間には、可能性として負の相関があります。

唯一の外部テストは時間です。時間が経つにつれて、美しいものは繁栄し、醜いものは捨てられる傾向があります。残念ながら、関与する時間の量は人間の寿命よりも長くなることがあります。サミュエル・ジョンソンは、作家の評判が収束するのに100年かかると言いました。作家の影響力のある友人が亡くなるのを待たなければならず、次に彼らのフォロワー全員が亡くなるのを待たなければなりません。

ハッカーは、自分の評判に大きなランダムな要素があることを受け入れなければならないと思います。この点で彼らは他の作り手と変わりません。実際、彼らは比較的幸運です。ファッションの影響は、ハッキングにおいては絵画ほど大きくありません。

人々があなたの作品を誤解するよりも悪いことがあります。より悪い危険は、あなた自身が自分の作品を誤解することです。関連分野はアイデアを探す場所です。コンピュータサイエンス学部にいると、例えば、ハッキングが理論的コンピュータサイエンスの理論の応用版であると信じる自然な誘惑があります。大学院にいる間、私は理論をもっと知っておくべきだという不快な気持ちを常に抱いていました。そして、最終試験の3週間以内にそのすべてのことを忘れてしまったのは非常に怠慢だと思っていました。

今、私は自分が間違っていたことに気づきました。ハッカーは、画家が絵の化学を理解する必要があるのと同じくらい、計算理論を理解する必要があります。時間と空間の複雑さを計算する方法や、チューリング完全性について知っておく必要があります。また、パーサーや正規表現ライブラリを書く必要がある場合に備えて、状態機械の概念を少なくとも覚えておくことも望ましいです。実際、画家はそれ以上の絵の化学について覚えておく必要があります。

私は、アイデアの最良の源は、「コンピュータ」という言葉が名前に含まれている他の分野ではなく、作り手が住む他の分野であることがわかりました。絵画は計算理論よりもはるかに豊かなアイデアの源でした。

例えば、私は大学で、プログラムをコンピュータに近づく前に完全に紙の上で考えるべきだと教えられました。私はこのようにプログラムをしないことに気づきました。私は紙の上ではなく、コンピュータの前に座ってプログラムをするのが好きだと感じました。さらに悪いことに、完全なプログラムを書いてそれが正しいことを確認するのではなく、私は無茶苦茶に壊れたコードを吐き出し、徐々に形を整える傾向がありました。デバッグは、タイプミスや見落としを見つけるための最終的なパスのように教えられました。私のやり方では、プログラミングはデバッグで構成されているように思えました。

長い間、私はこれについて悪い気持ちを抱いていました。まるで、私は小学校で教えられたように鉛筆を持たなかったことを悪く思っていたかのようです。もし私が他の作り手、画家や建築家を見ていたら、私は自分がやっていることに名前があることに気づいていたでしょう：スケッチです。私が大学で教えられたプログラミングの方法はすべて間違っていたようです。プログラムは書いている最中に考えるべきです。作家や画家、建築家がするように。

これを理解することは、ソフトウェアデザインに実際の影響を与えます。つまり、プログラミング言語は何よりも柔軟であるべきです。プログラミング言語は、すでに考えたプログラムを表現するためのものではなく、プログラムを考えるためのものです。それは鉛筆であるべきで、ペンではありません。静的型付けは、実際に人々が大学で教えられたようにプログラムを書くならば良いアイデアです。しかし、私が知っているハッカーの誰もがそのようにプログラムを書いているわけではありません。私たちは、走り書きやぼかし、にじみを許す言語が必要です。膝の上に型のティーカップを乗せて、厳格な古いおばあさんのコンパイラと礼儀正しい会話をしなければならない言語ではありません。

静的型付けの話をしている間、作り手と同一視することで、私たちは科学に悩まされる別の問題から救われます：数学的嫉妬です。科学者たちは、秘密裏に数学者が自分たちよりも賢いと信じています。数学者たちもこれを信じていると思います。いずれにせよ、その結果、科学者たちは自分たちの仕事をできるだけ数学的に見せようとします。物理学のような分野では、これはあまり害を及ぼさないかもしれませんが、自然科学から離れるほど、問題が大きくなります。

数式のページは非常に印象的に見えます。（ヒント：さらなる印象を与えるために、ギリシャの変数を使用してください。）そのため、形式的に扱える問題に取り組む誘惑が大きくなり、重要な問題に取り組むことが少なくなります。

もしハッカーが作り手の他の人々、作家や画家と同一視すれば、彼らはこのように感じることはないでしょう。作家や画家は数学的嫉妬に悩まされません。彼らは、自分たちが全く無関係なことをしているように感じます。ハッカーもそうだと思います。

もし大学や研究所がハッカーがやりたい仕事をさせないのなら、彼らの居場所は企業にあるかもしれません。残念ながら、ほとんどの企業もハッカーがやりたいことをさせてくれません。大学や研究所はハッカーに科学者であることを強制し、企業は彼らにエンジニアであることを強制します。

私はこのことを最近発見しました。YahooがViawebを買収したとき、彼らは私に何をしたいか尋ねました。私はビジネスサイドがあまり好きではなく、ただハッキングをしたいと言いました。Yahooに着くと、彼らにとってハッキングとはソフトウェアを実装することであり、設計することではないことがわかりました。プログラマーは、製品マネージャーのビジョン（もしその言葉が適切なら）をコードに翻訳する技術者として見られていました。

これは大企業のデフォルトプランのようです。彼らは、結果の標準偏差を減少させるためにこれを行います。実際にソフトウェアを設計できるハッカーはごく少数であり、企業を運営する人々がこれらを見分けるのは難しいです。したがって、未来のソフトウェアを一人の優れたハッカーに委ねるのではなく、ほとんどの企業は委員会によって設計されるように設定し、ハッカーは単に設計を実装するだけです。

もしあなたがいつかお金を稼ぎたいのなら、これを覚えておいてください。これはスタートアップが勝つ理由の一つです。大企業は設計結果の標準偏差を減少させたいと思っています。なぜなら、彼らは災害を避けたいからです。しかし、振動を抑えると、高いポイントも低いポイントも失われます。これは大企業にとって問題ではありません。なぜなら、彼らは素晴らしい製品を作ることで勝つわけではないからです。大企業は他の大企業よりも劣っていることで勝ちます。

したがって、もしあなたが製品マネージャーによって設計されたソフトウェアを持つ大企業とデザイン戦争をする方法を見つけることができれば、彼らは決してあなたに追いつくことができません。しかし、これらの機会は簡単には見つかりません。大企業をデザイン戦争に巻き込むのは難しいです。まるで城の中の相手と接近戦をするのが難しいように。例えば、Microsoft Wordよりも優れたワードプロセッサを書くのは非常に簡単ですが、Microsoftはおそらく、あなたがそれをしたとしても、彼らのオペレーティングシステムの独占という城の中でさえ気づかないでしょう。

デザイン戦争を戦う場所は、新しい市場です。誰もまだ防御を確立していない場所です。そこで、デザインに大胆なアプローチを取り、同じ人々が製品を設計し実装することで大きな勝利を得ることができます。Microsoft自身も最初はこれを行いました。Appleもそうでした。ヒューレット・パッカードもそうでした。ほぼすべての成功したスタートアップがそうしていると思います。

したがって、素晴らしいソフトウェアを構築する一つの方法は、自分自身のスタートアップを始めることです。しかし、これには二つの問題があります。一つは、スタートアップではソフトウェアを書く以外に多くのことをしなければならないことです。Viawebでは、私は四分の一の時間をハッキングできれば幸運だと考えていました。そして、他の三四分の時間にやらなければならないことは、退屈から恐ろしいものまでさまざまでした。私はこれに基準があります。なぜなら、私は一度、ボードミーティングを離れて虫歯を治療してもらわなければならなかったからです。私は歯医者の椅子に座って、ドリルを待っているとき、まるで休暇を取っているように感じました。

スタートアップのもう一つの問題は、お金を生むソフトウェアと書くのが面白いソフトウェアの間にあまり重複がないことです。プログラミング言語は書くのが面白いですが、Microsoftの最初の製品は実際にそれでしたが、今では誰もプログラミング言語にお金を払おうとはしません。お金を稼ぎたいのなら、誰も無料で解決できないような厄介な問題に取り組まざるを得ないことが多いです。

すべての作り手はこの問題に直面しています。価格は需給によって決まります。そして、個々の顧客の平凡な問題を解決するものに対する需要ほど、楽しい作業に対する需要はありません。オフ・ブロードウェイの劇に出演することは、展示会で誰かのブースでゴリラのスーツを着ることほどは報酬が良くありません。小説を書くことは、ゴミ処理機の広告コピーを書くことほどは報酬が良くありません。そして、プログラミング言語をハッキングすることは、ある会社のレガシーデータベースをWebサーバーに接続する方法を見つけることほどは報酬が良くありません。

この問題の答えは、ソフトウェアの場合、ほとんどの作り手が知っている概念、すなわち「日中の仕事」にあると思います。このフレーズは、夜に演奏するミュージシャンから始まりました。より一般的には、あなたが金のために行う仕事と、愛のために行う別の仕事があることを意味します。

ほとんどの作り手はキャリアの初期に日中の仕事を持っています。画家や作家は特にそうです。運が良ければ、あなたの本当の仕事に密接に関連した日中の仕事を得ることができます。ミュージシャンはしばしばレコード店で働いているようです。プログラミング言語やオペレーティングシステムに取り組んでいるハッカーも同様に、それを使用する日中の仕事を得ることができるかもしれません。[1]

私がハッカーが日中の仕事を持ち、サイドで美しいソフトウェアに取り組むべきだと言うとき、私はこれを新しいアイデアとして提案しているわけではありません。これはオープンソースハッキングの本質です。私が言っているのは、オープンソースが正しいモデルである可能性が高いということです。なぜなら、それは他のすべての作り手によって独立して確認されているからです。

どんな雇用主もハッカーがオープンソースプロジェクトに取り組むことをためらうとは驚くべきことです。Viawebでは、私たちはそうでない人を雇うことにためらいがありました。プログラマーを面接するとき、私たちが最も気にしていたのは、彼らが余暇にどのようなソフトウェアを書いているかということでした。あなたは本当にうまくできることは、愛していない限りできません。そして、ハッキングを愛しているなら、必然的に自分自身のプロジェクトに取り組むことになります。[2]

ハッカーは作り手であり、科学者ではないため、メタファーを探す正しい場所は科学ではなく、他の種類の作り手の中にあります。絵画はハッキングについて何を教えてくれるでしょうか？

絵画の例から学べること、あるいは少なくとも確認できることの一つは、ハッキングを学ぶ方法です。あなたは主にそれを行うことによって絵を学びます。ハッキングも同様です。ほとんどのハッカーは、大学のプログラミングコースを受講することによってハッキングを学びません。彼らは13歳のときに自分自身のプログラムを書くことによってハッキングを学びます。大学のクラスでも、あなたは主にハッキングを通じてハッキングを学びます。[3]

画家は自分の作品の跡を残すので、彼らが実践を通じて学ぶ様子を見ることができます。画家の作品を年代順に見ると、各絵画が以前の作品で学んだことに基づいていることがわかります。絵画の中に非常にうまく機能するものがあるとき、それは通常、以前の絵画の中に小さな形でバージョン1が見つかります。

私はほとんどの作り手がこのように働くと思います。作家や建築家もそうです。ハッカーが画家のように行動し、定期的にゼロからやり直すことが良いかもしれません。何年も一つのプロジェクトに取り組み、後のアイデアをすべて修正として組み込もうとするのではなく。

ハッカーがハッキングを実践することで学ぶという事実は、ハッキングが科学とはどれほど異なるかのもう一つの兆候です。科学者は、実践を通じて科学を学ぶのではなく、実験や問題集を通じて学びます。科学者は、他の誰かがすでに自分のために行った作業を再現しようとする意味で完璧な作業を行うことから始めます。最終的には、彼らは独創的な作業を行うことができるようになります。一方、ハッカーは最初から独創的な作業を行っていますが、それは非常に悪いものです。したがって、ハッカーは独創的に始まり、良くなり、科学者は良く始まり、独創的になります。

作り手が学ぶもう一つの方法は、例からです。画家にとって、美術館は技術の参考図書館です。何世代にもわたり、画家の伝統的な教育の一部は、偉大な巨匠の作品を模写することです。模写は、絵画がどのように作られているかを注意深く見ることを強制します。

作家も同様です。ベンジャミン・フランクリンは、アディソンとスティールのエッセイの要点を要約し、それを再現しようとすることで書くことを学びました。レイモンド・チャンドラーも探偵小説で同じことをしました。

ハッカーもまた、良いプログラムを見て学ぶことができます—彼らが何をしているかだけでなく、ソースコードも見ることができます。オープンソース運動のあまり公にされていない利点の一つは、プログラミングを学ぶのが容易になったことです。私がプログラミングを学んだとき、私たちは主に本の例に頼らなければなりませんでした。当時利用可能だった大きなコードの塊はUnixでしたが、これもオープンソースではありませんでした。ソースを読む人のほとんどは、1977年に書かれたジョン・ライオンズの本の違法なコピーを読んでいましたが、これは1996年まで出版が許可されませんでした。

絵画から得られるもう一つの例は、絵画が徐々に洗練されて作成される方法です。絵画は通常、スケッチから始まります。徐々に詳細が埋められていきます。しかし、それは単に埋めるプロセスではありません。時には、元の計画が間違っていることが判明します。無数の絵画は、X線で見ると、肢が移動したり、顔の特徴が再調整されたりしていることがわかります。

ここで私たちは絵画から学ぶことができます。私はハッキングもこのように機能すべきだと思います。プログラムの仕様が完璧であることを期待するのは非現実的です。あなたは、仕様がその場で変更できるようにプログラムを書くことを前提にした方が良いです。

（大企業の構造はこれを難しくするので、ここでもスタートアップが優位に立つ場所です。）

今や、早すぎる最適化の危険性については誰もが知っていると思います。私は、早すぎるデザイン—プログラムが何をすべきかを早く決定することについても同様に心配すべきだと思います。

適切なツールは、この危険を避けるのに役立ちます。良いプログラミング言語は、油絵のように、心変わりを容易にするべきです。動的型付けはここで勝利です。なぜなら、特定のデータ表現に前もってコミットする必要がないからです。しかし、柔軟性の鍵は、言語を非常に抽象的にすることだと思います。変更が最も簡単なプログラムは非常に短いものです。

これは逆説のように聞こえますが、素晴らしい絵画はそれが必要とする以上に優れている必要があります。例えば、レオナルドがナショナルギャラリーでジネヴラ・デ・ベンチの肖像画を描いたとき、彼は彼女の頭の後ろにジュニパーの茂みを置きました。その中で彼は各葉を注意深く描きました。多くの画家は、これは彼女の頭をフレームするための背景に置くものに過ぎないと思ったかもしれません。誰もそれをそんなに注意深く見ることはないでしょう。

レオナルドはそうではありませんでした。彼が絵画の一部にどれだけ努力したかは、誰かがそれをどれだけ注意深く見るかには全く依存していませんでした。彼はマイケル・ジョーダンのようでした。執拗でした。

執拗さは勝利をもたらします。なぜなら、全体として、見えない詳細が見えるようになるからです。人々がジネヴラ・デ・ベンチの肖像画の前を通り過ぎるとき、彼らの注意はしばしばそれにすぐに引き寄せられます。ラベルを見て「レオナルド・ダ・ヴィンチ」と書かれていることに気づく前に。すべての見えない詳細が組み合わさって、驚くべきものを生み出します。まるで千のかすかな声がすべて調和して歌っているかのようです。

素晴らしいソフトウェアも同様に、美しさへの狂信的な献身を必要とします。良いソフトウェアの内部を見ると、誰も見ることがない部分も美しいことがわかります。私は素晴らしいソフトウェアを書くと主張しているわけではありませんが、コードに関しては、日常生活に同じように接近した場合、処方薬の対象となるような行動をとることを知っています。悪いインデントのコードや、醜い変数名を使っているコードを見ると、私は気が狂いそうになります。

もしハッカーが単なる実装者であり、仕様をコードに変換するだけなら、彼は溝を掘る人のように一端から他端まで進むことができるでしょう。しかし、もしハッカーが創造者であるなら、私たちはインスピレーションを考慮に入れなければなりません。

ハッキングは、絵画と同様に、作業がサイクルで行われます。時には新しいプロジェクトに興奮し、16時間働きたいと思うことがあります。他の時には、何も興味深く感じません。

良い仕事をするためには、これらのサイクルを考慮に入れる必要があります。なぜなら、それらはあなたがそれにどのように反応するかによって影響を受けるからです。手動トランスミッションの車を丘で運転しているとき、時にはクラッチを緩めてエンストを避けなければなりません。緩めることは、野心が停滞するのを防ぐこともできます。絵画とハッキングの両方には、恐ろしいほど野心的なタスクと、安心感のあるルーチンなタスクがあります。そうした瞬間に停滞することを避けるために、いくつかの簡単なタスクを保存しておくのは良いアイデアです。

ハッキングでは、これは文字通りバグを保存することを意味することがあります。私はデバッグが好きです。それは、ハッキングが人々が考えるほど単純である唯一の時です。あなたには完全に制約された問題があり、あなたがする必要があるのはそれを解決することだけです。あなたのプログラムはxをすることになっています。代わりにyをします。どこで間違っているのでしょうか？あなたは最終的に勝つことがわかっています。それは壁を塗るのと同じくらいリラックスできます。

絵画の例は、私たちが自分の作業を管理する方法だけでなく、一緒に作業する方法も教えてくれます。過去の偉大な芸術の多くは、複数の手による作品ですが、博物館の壁には一つの名前しかないかもしれません。レオナルドはヴェロッキオの工房で見習いをしており、彼のキリストの洗礼の天使の一つを描きました。このようなことは例外ではなく、ルールでした。ミケランジェロは、システィーナ礼拝堂の天井のすべての人物を自分で描くことにこだわったため、特に献身的だと見なされました。

私の知る限り、画家が一緒に絵を描くとき、彼らは同じ部分で作業することはありませんでした。主な人物を描くのはマスターであり、助手が他の部分や背景を描くのが一般的でした。しかし、誰かが他の人の作品の上に描くことはありませんでした。

私はこれがソフトウェアにおけるコラボレーションの正しいモデルだと思います。あまり押し進めないでください。コードの一部が3人または4人の異なる人によってハッキングされているとき、誰も本当にそれを所有していない場合、それは共用の部屋のようになります。それは荒廃し、放置されたように感じ、クルフトが蓄積される傾向があります。私が考えるに、コラボレーションの正しい方法は、プロジェクトを明確に定義されたモジュールに分割し、それぞれに明確な所有者を持たせ、可能であればプログラミング言語のように慎重に設計されたインターフェースを持たせることです。

絵画と同様に、ほとんどのソフトウェアは人間の聴衆を対象としています。したがって、ハッカーも画家と同様に、真に素晴らしい作品を作るためには共感が必要です。ユーザーの視点から物事を見ることができなければなりません。

子供の頃、私は常に他の人の視点から物事を見るように言われていました。実際には、これは常に他の誰かが望むことをすることを意味していました。私が望むことではなく。これはもちろん、共感に悪い名前を付け、私はそれを育てないことにしました。

私は間違っていました。他の人の視点から物事を見ることが成功の秘密であることが判明しました。必ずしも自己犠牲を意味するわけではありません。全く逆のことをしたい場合もあります。例えば、戦争のような状況では、正確にその逆を望むことがあります。[4]

ほとんどの作り手は人間の聴衆のために物を作ります。そして、聴衆を引き込むためには、彼らが何を必要としているかを理解しなければなりません。例えば、ほとんどの偉大な絵画は人々の絵画です。なぜなら、人々は人々に興味があるからです。

共感は、おそらく良いハッカーと偉大なハッカーの間の唯一の最も重要な違いです。いくつかのハッカーは非常に賢いですが、共感に関してはほとんど独我論者です。このような人々が素晴らしいソフトウェアを設計するのは難しいです[5]。なぜなら、彼らはユーザーの視点から物事を見ることができないからです。

人々が共感にどれだけ優れているかを判断する一つの方法は、技術的な質問を技術的なバックグラウンドのない誰かに説明する様子を見ることです。おそらく、私たちは皆、他の点では賢いが、これに関しては滑稽に悪い人々を知っています。誰かがディナーパーティーでプログラミング言語とは何かと尋ねると、彼らは「高水準言語はコンパイラがオブジェクトコードを生成するための入力として使用するものです」と言うでしょう。高水準言語？コンパイラ？オブジェクトコード？プログラミング言語が何であるかを知らない人は、これらのことも知らないのは明らかです。

ソフトウェアが自分自身を説明する必要があります。したがって、良いソフトウェアを書くためには、ユーザーがどれほど少ししか理解していないかを理解する必要があります。彼らは準備なしにソフトウェアに近づくつもりであり、それが彼らが推測することをしなければなりません。なぜなら、彼らはマニュアルを読むつもりはないからです。この点で、私が見た中で最良のシステムは、1985年のオリジナルのMacintoshでした。それは、ソフトウェアがほとんど決してしないことをしました：それはただ機能しました。[6]

ソースコードもまた、自分自身を説明するべきです。もし私が人々にプログラミングについての一つの引用を思い出させることができるなら、それはコンピュータプログラムの構造と解釈の冒頭の引用です。

プログラムは人間が読むために書かれるべきであり、機械がそれを実行するために書かれるのは副次的なものです。

あなたはユーザーだけでなく、読者に対しても共感を持つ必要があります。それはあなたの利益になります。なぜなら、あなたも彼らの一人だからです。多くのハッカーはプログラムを書いた後、6ヶ月後に戻ってきたときに、それがどのように機能するのか全くわからないことに気づきます。私は、そうした経験の後にPerlをやめたと誓った人々を何人か知っています。[7]

共感の欠如は知性と関連しており、ある場所ではそれに対するファッションがあるほどです。しかし、私は相関関係があるとは思いません。あなたは共感を学ぶ必要がなく、数学や自然科学でうまくやることができ、これらの分野の人々は賢い傾向があるため、これらの二つの特性は関連付けられてきました。しかし、共感が苦手な愚かな人々もたくさんいます。トークショーで質問をする人々の声を聞いてみてください。彼らは、ホストが質問を言い換えなければならないほど、回りくどい方法で尋ねます。

では、ハッキングが絵画や執筆のように機能するなら、それは同じくらいクールでしょうか？結局のところ、あなたは一度だけの人生を持っています。素晴らしい何かに取り組むためにそれを費やすべきです。

残念ながら、この質問に答えるのは難しいです。名声には常に大きな時間差があります。それは遠くの星からの光のようです。絵画は、500年前に人々が行った偉大な作品のおかげで今は名声があります。当時、誰もこれらの絵画が今日私たちが考えるほど重要だとは思っていませんでした。ウルビーノ公のフェデリコ・ダ・モンテフェルトロが、ピエロ・デッラ・フランチェスカの絵画の中で奇妙な鼻を持つ男として知られるようになるとは、当時の人々には非常に奇妙に思えたでしょう。

したがって、ハッキングが今は絵画ほどクールに見えないことを認めますが、絵画自体がその栄光の日々には今ほどクールに見えなかったことを思い出すべきです。

私たちがある程度自信を持って言えることは、これがハッキングの栄光の日々であるということです。ほとんどの分野では、偉大な作品は初期に行われます。1430年から1500年の間に作られた絵画は、今でも比類のないものです。シェイクスピアは、プロの演劇が生まれつつあるときに現れ、メディアを押し進め、以降のすべての劇作家が彼の影に生きなければならなくなりました。アルブレヒト・デューラーは版画で同じことを行い、ジェーン・オースティンは小説で同じことを行いました。

私たちは何度も同じパターンを見ることができます。新しいメディアが現れ、人々はそれに非常に興奮し、最初の数世代でそのほとんどの可能性を探求します。ハッキングは今、この段階にあるようです。

レオナルドの時代には、絵画は彼の作品がそれを助けたほどクールではありませんでした。ハッキングがどれほどクールになるかは、この新しいメディアで私たちが何をすることができるかに依存します。

ノート

[1] 写真が絵画に与えた最大の損害は、最高の日中の仕事を奪ったことかもしれません。歴史上の偉大な画家のほとんどは、肖像画を描くことで自分を支えていました。

[2] Microsoftが従業員にオープンソースプロジェクトへの貢献を控えるように促していると聞いたことがあります。たとえ彼らの余暇であっても。しかし、今では最高のハッカーの多くがオープンソースプロジェクトに取り組んでいるため、この方針の主な影響は、彼らが一流のプログラマーを雇うことができなくなることを確実にすることかもしれません。

[3] 大学で学ぶプログラミングは、書籍や服、デートについて学ぶことと非常に似ています：高校時代の悪い趣味です。

[4] これは応用された共感の例です。Viawebでは、二つの選択肢の間で決められない場合、私たちは「競合他社が最も嫌がることは何か？」と尋ねました。ある時、競合他社が基本的に無駄な機能をソフトウェアに追加しましたが、それは彼らが持っている数少ない機能の一つであり、トレードプレスで大きく取り上げられました。私たちはその機能が無駄であることを説明しようとすることもできましたが、私たちはそれを自分たちで実装した方が競合他社をもっと苛立たせるだろうと決定し、その午後に自分たちのバージョンをハッキングしました。

[5] テキストエディタやコンパイラを除いて。ハッカーはこれらを設計するために共感を必要としません。なぜなら、彼ら自身が典型的なユーザーだからです。

[6] まあ、ほぼそうです。彼らは利用可能なRAMをやや超過し、不便なディスクスワッピングを引き起こしましたが、これは数ヶ月以内に追加のディスクドライブを購入することで修正できました。

[7] プログラムを読みやすくする方法は、コメントで詰め込むことではありません。私はアベルソンとサスマンの引用を一歩進めたいと思います。プログラミング言語はアルゴリズムを表現するために設計されるべきであり、コンピュータにそれを実行する方法を伝えるのは副次的なものであるべきです。良いプログラミング言語は、英語よりもソフトウェアを説明するのに優れているべきです。あなたは、読者に警告する必要があるような何らかの手段がある場合にのみコメントが必要です。道路に予期しない急なカーブがある部分にのみ矢印があるのと同じです。

感謝をTrevor Blackwell、Robert Morris、Dan Giffin、Lisa Randallに、この草稿を読んでくれたことに、Henry LeitnerとLarry Finkelsteinに私を招待してくれたことに感謝します。