ハッカーと画家
Original2003年5月
(このエッセイは、ハーバード大学でのゲストレクチャーから派生したもので、ノースイースタン大学での以前の講演を組み込んでいます。)
コンピュータサイエンスの大学院を卒業した後、私は絵画を学ぶために美術学校に行きました。コンピュータに興味を持っている人が絵画にも興味を持っていることに、多くの人が驚いたようです。彼らは、ハッキングと絵画は非常に異なる種類の仕事であると考えているようでした。ハッキングは冷たく、正確で、体系的であり、絵画は原始的な衝動の熱狂的な表現であると。
これらのイメージはどちらも間違っています。ハッキングと絵画は多くの共通点があります。実際、私が知っているさまざまなタイプの人々のうち、ハッカーと画家は最も似ています。
ハッカーと画家が共通して持っているのは、どちらも作り手であるということです。作曲家、建築家、作家とともに、ハッカーと画家がしようとしているのは、良いものを作るということです。彼らは、研究そのものをしているわけではありません。しかし、良いものを作ろうとする過程で、新しい技術を発見した場合、それはそれで良いことです。
私は「コンピュータサイエンス」という用語がずっと好きではありませんでした。私がそれを嫌う主な理由は、そのようなものがないからです。コンピュータサイエンスは、ユーゴスラビアのように、歴史の偶然によって寄せ集められた、関連性の薄い分野の寄せ集めです。一方は、実際には数学者ですが、DARPAの助成金を得るために、自分がやっていることをコンピュータサイエンスと呼んでいます。真ん中には、コンピュータの自然史のようなものを研究している人たちがいます。たとえば、ネットワークを通じてデータをルーティングするためのアルゴリズムの動作を研究しています。そして、もう一方の端には、興味深いソフトウェアを書こうとしているハッカーがいます。彼らにとって、コンピュータは、建築家にとってコンクリートや画家にとって絵の具と同じように、表現の媒体に過ぎません。まるで、数学者、物理学者、建築家がすべて同じ学部に所属しなければならないかのようです。
ハッカーがやっていることは、時々「ソフトウェアエンジニアリング」と呼ばれますが、この用語も同様に誤解を招くものです。優れたソフトウェア設計者は、建築家がエンジニアではないのと同じように、エンジニアではありません。建築とエンジニアリングの境界は明確ではありませんが、そこにはあります。それは、何をどのようにするかによって決まります。建築家は、何をすべきかを決め、エンジニアは、どのようにすべきかを考え出します。
何をどのようにするかは、あまりにも分離すべきではありません。どのようにするかを理解せずに、何をすべきかを決めようとすると、トラブルを招きます。しかし、ハッキングは、単に仕様を実装する方法を決めるだけではありません。最高の状態では、それは仕様を作成することです。しかし、それは、仕様を実装するのが最善の方法であることが判明します。
いつか、「コンピュータサイエンス」は、ユーゴスラビアのように、その構成要素に分割されるかもしれません。それは良いことかもしれません。特に、私の故郷であるハッキングの独立を意味するなら。
これらすべての異なる種類の仕事を1つの学部にまとめるのは、管理上は便利かもしれませんが、知的にも混乱を招きます。それが、私が「コンピュータサイエンス」という名前が気に入らないもう1つの理由です。議論の余地はありますが、真ん中の人たちは、実験科学のようなことをしています。しかし、両端の人々、ハッカーと数学者は、実際には科学を行っていません。
数学者は、このことに悩んでいるようには見えません。彼らは、数学部の他の数学者と同じように、喜んで定理を証明することに取り組み、おそらくすぐに、自分が働いている建物が外側に「コンピュータサイエンス」と書かれていることに気づかなくなります。しかし、ハッカーにとって、このラベルは問題です。彼らがやっていることが科学と呼ばれていると、彼らは科学的に振る舞うべきだと感じます。そのため、大学や研究機関のハッカーは、本当にやりたいこと、つまり美しいソフトウェアを設計することではなく、研究論文を書くべきだと感じています。
最高のケースでは、論文は単なる形式です。ハッカーはクールなソフトウェアを書き、その後それについて論文を書き、論文はソフトウェアによって表される成果の代理になります。しかし、多くの場合、このミスマッチは問題を引き起こします。研究論文に適した醜いものを構築することよりも、美しいものを構築することから離れていくのは簡単です。
残念ながら、美しいものは、常に論文に最適な主題になるとは限りません。第一に、研究は独創的である必要があります。そして、博士論文を書いたことがある人なら誰でも知っているように、未開拓の領域を探求していることを確認する方法は、誰もが望まない土地を確保することです。第二に、研究は実質的である必要があります。そして、ぎこちないシステムは、より肉厚な論文を生み出します。なぜなら、あなたは、物事を成し遂げるために克服しなければならない障害について書くことができるからです。間違った前提から始めることほど、肉厚な問題を生み出すものはありません。AIのほとんどは、この規則の例です。知識を、抽象的な概念を表す引数を持つ述語論理式のリストとして表すことができると仮定すると、この方法を機能させる方法について多くの論文を書くことができます。リッキー・リカルドがかつて言ったように、「ルーシー、説明するべきことがたくさんあるわ」。
美しいものを創造する方法は、多くの場合、すでに存在するものを微妙に調整するか、既存のアイデアをわずかに新しい方法で組み合わせることです。この種の仕事は、研究論文では伝えにくいです。
では、なぜ大学や研究機関は、ハッカーを出版物で判断し続けるのでしょうか？「学力」が単純な標準化されたテストで測定されるのと同じ理由で、またはプログラマーの生産性がコード行数で測定されるのと同じ理由です。これらのテストは適用しやすく、機能するような簡単なテストほど魅力的なものはありません。
ハッカーが実際にやろうとしていること、つまり美しいソフトウェアを設計することを測定することは、はるかに困難です。あなたは、良いデザインを判断するために、良いデザイン感覚が必要です。そして、良いデザインを認識する能力と、自分ができると確信する能力の間には、おそらく負の相関関係しかありません。
唯一の外部テストは時間です。時が経つにつれて、美しいものは繁栄し、醜いものは捨てられる傾向があります。残念ながら、かかる時間は、人間の寿命よりも長くなる可能性があります。サミュエル・ジョンソンは、作家の評判が収束するまでに100年かかると言いました。あなたは、作家の影響力のある友人が死ぬのを待たなければなりません。そして、彼らのすべてのフォロワーが死ぬのを待たなければなりません。
私は、ハッカーは、自分の評判に大きなランダムな要素があることを受け入れなければならないと思います。この点で、彼らは他の作り手と何ら変わりません。実際、彼らは比較して幸運です。ファッションの影響は、ハッキングでは、絵画ほど大きくありません。
自分の作品を誤解されるよりも悪いことがあります。さらに悪い危険は、あなたが自分の作品を誤解することです。関連分野は、あなたがアイデアを探しに行く場所です。あなたがコンピュータサイエンス学部にいる場合、たとえば、ハッキングは、理論コンピュータサイエンスが理論であることの応用版であると信じる誘惑があります。大学院にいる間ずっと、私は、もっと理論を学ぶべきだと、そして、期末試験の3週間以内にそのすべてを忘れてしまったのは、自分の不注意だと、心の奥底で不快な気持ちを抱いていました。
今、私は自分が間違っていたことに気づきました。ハッカーは、画家が絵の具の化学を理解する必要があるのと同じくらい、計算の理論を理解する必要があります。あなたは、時間と空間の複雑さを計算する方法、そしてチューリング完全性について知る必要があります。パーサーや正規表現ライブラリを書く必要がある場合に備えて、状態マシンの概念を少なくとも覚えておく必要があるかもしれません。実際、画家は、それよりもはるかに多くの絵の具の化学について覚えておく必要があります。
私は、最高のアイデアの源は、名前の中に「コンピュータ」という言葉を含む他の分野ではなく、作り手が住む他の分野であることに気づきました。絵画は、計算の理論よりもはるかに豊かなアイデアの源でした。
たとえば、私は大学で、コンピュータに触れる前に、プログラムを完全に紙に書き出すべきだと教えられました。私は、そうはプログラムしないことに気づきました。私は、紙ではなく、コンピュータの前に座ってプログラムするのが好きだと気づきました。さらに悪いことに、私は、辛抱強く完全なプログラムを書き出して、それが正しいことを確認するのではなく、ひどく壊れたコードを吐き出し、徐々にそれを形にする傾向がありました。デバッグは、タイポや見落としを捕まえる最終的なパスであると教えられました。私が働いていた方法は、プログラミングはデバッグで構成されているように見えました。
長い間、私はこのことで気分が悪かった。かつて、鉛筆を小学校で教わったように持っていなかったことで気分が悪かったのと同じように。もし私が他の作り手、画家や建築家を見ていたら、私がやっていたことに名前があることに気づいただろう。スケッチ。私の知る限り、大学でプログラミングを教わった方法はすべて間違っていました。作家や画家や建築家と同じように、プログラムを書きながらプログラムを理解する必要があります。
このことに気づくことは、ソフトウェア設計に現実的な影響を与えます。それは、プログラミング言語は、何よりも、柔軟である必要があることを意味します。プログラミング言語は、すでに考えたプログラムを表現するためではなく、プログラムを考えるためのものである。それは、ペンではなく、鉛筆であるべきです。静的型付けは、人々が実際に大学で教わったようにプログラムを書けば、素晴らしいアイデアでしょう。しかし、それは、私が知っているハッカーの誰もがプログラムを書く方法ではありません。私たちは、スクリブルしたり、スマッジしたり、スメアしたりできる言語が必要です。お茶のカップに型を載せて、厳格な古い叔母のようなコンパイラと丁寧な会話をしなければならない言語ではありません。
静的型付けについて言えば、作り手と同一視することで、科学を悩ませているもう1つの問題、つまり数学への憧れから私たちを救うことができます。科学の分野にいる人は皆、密かに数学者は自分たちよりも賢いと信じています。私は、数学者もそう信じていると思います。いずれにせよ、その結果、科学者は、自分の仕事をできるだけ数学的に見せる傾向があります。物理学のような分野では、おそらくそれほど害はありませんが、自然科学から離れるほど、問題が大きくなります。
数式のページは、とても印象的に見えます。（ヒント：さらに印象的にするために、ギリシャ文字の変数を使用してください。）そのため、重要な問題ではなく、正式に扱うことができる問題に取り組む大きな誘惑があります。
ハッカーが作家や画家のような他の作り手と同一視すれば、彼らはそうする誘惑を感じないでしょう。作家や画家は、数学への憧れに苦しむことはありません。彼らは、自分たちはまったく異なることをしていると感じています。だから、ハッカーもそうだと思います。
大学や研究機関がハッカーを、彼らがやりたい種類の仕事をするのを妨げている場合、おそらく彼らにとっての場所は企業です。残念ながら、ほとんどの企業は、ハッカーがやりたいことをさせるわけではありません。大学や研究機関は、ハッカーを科学者に強制し、企業は、彼らをエンジニアに強制します。
私は、最近になって初めてこのことに気づきました。ヤフーがViawebを買収したとき、彼らは私に何をしたいのかを尋ねました。私はビジネス面があまり好きではなく、ただハッキングしたいと言いました。ヤフーに行くと、ハッキングが彼らにとって意味するところは、ソフトウェアを設計することではなく、実装することだとわかりました。プログラマーは、製品マネージャーのビジョン（もしそれが言葉なら）をコードに変換する技術者と見なされていました。
これは、大企業のデフォルトの計画のようです。彼らは、それが結果の標準偏差を減らすために行います。ハッカーのほんの一握りだけが実際にソフトウェアを設計することができ、企業を運営している人にとって、これらのハッカーを見つけるのは難しいです。そのため、ほとんどの企業は、ソフトウェアの未来を1人の天才的なハッカーに託すのではなく、委員会で設計し、ハッカーは単に設計を実装するように設定しています。
いつかお金を稼ぎたい場合は、これを覚えておいてください。なぜなら、これがスタートアップが勝つ理由の1つだからです。大企業は、災害を避けたいので、設計結果の標準偏差を減らしたいと考えています。しかし、振動を減衰させると、低い点だけでなく、高い点も失われます。これは、大企業にとって問題ではありません。なぜなら、彼らは素晴らしい製品を作ることで勝つわけではないからです。大企業は、他の大企業よりも劣っていることで勝つのです。
そのため、製品マネージャーによってソフトウェアが設計されているような、十分に大きな企業とのデザイン戦争に巻き込む方法を見つけ出すことができれば、彼らはあなたについていくことはできません。しかし、これらの機会を見つけるのは簡単ではありません。城の中にいる相手を白兵戦で巻き込むように、大企業とのデザイン戦争に巻き込むのは難しいです。たとえば、Microsoft Wordよりも優れたワープロを書くのは非常に簡単でしょうが、Microsoftは、オペレーティングシステムの独占という城の中にいるため、あなたがそうしても気づかないかもしれません。
デザイン戦争を戦う場所は、誰もまだ要塞を築いていない新しい市場です。そこでは、デザインに大胆なアプローチを取り、製品の設計と実装の両方を同じ人に行うことで、大きく勝つことができます。Microsoft自身も、当初はそうでした。Appleもそうです。そして、ヒューレット・パッカードもそうです。私は、ほとんどの成功したスタートアップがそうしてきたのではないかと疑っています。
そのため、素晴らしいソフトウェアを構築する1つの方法は、自分のスタートアップを始めることです。しかし、これには2つの問題があります。1つは、スタートアップでは、ソフトウェアを書く以外にも、多くのことをしなければならないということです。Viawebでは、私が時間の4分の1をハッキングに費やすことができれば、幸運だと考えていました。そして、残りの時間の4分の3に私がしなければならないことは、退屈なものから恐ろしいものまでありました。私は、このためのベンチマークを持っています。なぜなら、私はかつて、虫歯を治療するために取締役会を退席しなければならなかったからです。私は、歯科医の椅子にもたれて、ドリルを待つ間、自分が休暇中であるような気分だったのを覚えています。
スタートアップのもう1つの問題は、お金を稼ぐソフトウェアと、書くのが面白いソフトウェアの間に、あまり重なりがないことです。プログラミング言語を書くのは面白く、実際、Microsoftの最初の製品はプログラミング言語でしたが、今では誰もプログラミング言語にお金を払ってくれません。お金を稼ぎたい場合は、誰かが無料で解決できないほど厄介な問題に取り組むことを余儀なくされる傾向があります。
すべての作り手は、この問題に直面しています。価格は、需要と供給によって決まり、楽しい仕事をするものに対する需要は、個々の顧客のありふれた問題を解決するものに対する需要ほど多くありません。オフブロードウェイの劇に出演するだけでは、トレードショーのブースでゴリラの着ぐるみを着るほどお金になりません。小説を書くのは、生ごみ処理機の広告コピーを書くほどお金になりません。そして、プログラミング言語をハッキングするのも、会社のレガシーデータベースをWebサーバーに接続する方法を理解するほどお金になりません。
私は、ソフトウェアの場合、この問題に対する答えは、ほとんどすべての作り手に知られている概念である「日々の仕事」であると思います。このフレーズは、夜に演奏するミュージシャンから始まりました。より一般的には、それは、お金のためにする仕事と、愛のためにする仕事が別々にあることを意味します。
ほとんどすべての作り手は、キャリアの初期に日々の仕事を持っています。画家や作家は、特にそうです。運が良ければ、自分の本当の仕事に密接に関連する日々の仕事を得ることができます。ミュージシャンは、多くの場合、レコード店で働いているようです。プログラミング言語やオペレーティングシステムに取り組んでいるハッカーは、同様に、それを利用して日々の仕事を得ることができるかもしれません。[1]
ハッカーが日々の仕事を持ち、副業として美しいソフトウェアに取り組むべきだと私が言うとき、私はこれを新しいアイデアとして提案しているわけではありません。これが、オープンソースハッキングのすべてです。私が言いたいのは、オープンソースはおそらく正しいモデルであるということです。なぜなら、それは他のすべての作り手によって独立して確認されているからです。
雇用主がハッカーにオープンソースプロジェクトに取り組ませることをためらうのは、私にとって驚くべきことです。Viawebでは、そうしない人を雇うことをためらっていたでしょう。プログラマーにインタビューしたとき、私たちが最も気にかけていたのは、彼らが自分の時間でどんなソフトウェアを書いているかでした。あなたが本当に何かをうまくやることはできません。あなたがそれを愛していない限り、そしてあなたがハッキングを愛しているなら、あなたは必然的に自分のプロジェクトに取り組むことになるでしょう。[2]
ハッカーは科学者ではなく作り手であるため、メタファーを探す適切な場所は、科学ではなく、他の種類の作り手の中にあります。絵画は、ハッキングについて他に何を教えてくれるのでしょうか？
絵画の例から学ぶことができること、あるいは少なくとも確認できることの1つは、ハッキングを学ぶ方法です。あなたは、絵を描くことを、ほとんどそれをやることで学びます。ハッキングも同様です。ほとんどのハッカーは、プログラミングの大学課程を受講することでハッキングを学ぶわけではありません。彼らは、13歳のときに自分のプログラムを書くことでハッキングを学びます。大学での授業でも、ハッキングを学ぶのは、ほとんどハッキングをすることでです。[3]
画家は、自分の仕事の軌跡を残すため、あなたは彼らが実践を通して学ぶ様子を見ることができます。画家の作品を年代順に見てみると、それぞれの絵が、以前の絵で学んだことを基にしていることがわかります。絵の中に非常にうまく機能しているものがあれば、通常、以前の絵の中に、より小さな形でバージョン1を見つけることができます。
私は、ほとんどの作り手はこのように働いていると思います。作家や建築家もそうです。ハッカーが画家のように行動し、定期的に最初からやり直す方が良いかもしれません。1つのプロジェクトを何年も続け、すべての後のアイデアを修正として組み込もうとするのではなく。
ハッカーが実践を通してハッキングを学ぶという事実は、ハッキングが科学とはいかに異なるかのもう1つの兆候です。科学者は、実践を通して科学を学ぶのではなく、実験や問題集を通して学びます。科学者は、他の人がすでに自分たちのためにやってくれた仕事を再現しようとしているだけなので、完璧な意味で、完璧な仕事を始めます。最終的に、彼らは、独創的な仕事ができるようになるまでになります。一方、ハッカーは、最初から独創的な仕事をしています。それは単に非常に悪いだけです。そのため、ハッカーは独創的に始まり、上手になり、科学者は上手になり、独創的になります。
作り手が学ぶもう1つの方法は、例から学ぶことです。画家にとって、美術館は、技法の参考文献です。何世紀にもわたって、偉大な巨匠の作品を模倣することは、画家の伝統的な教育の一部でした。なぜなら、模倣は、絵がどのように作られているかを注意深く見なければならないからです。
作家もそうです。ベンジャミン・フランクリンは、アディソンとスティールのエッセイの要点を要約し、それを再現しようとすることで、書くことを学びました。レイモンド・チャンドラーは、探偵小説で同じことをしました。
同様に、ハッカーは、良いプログラムを見ることでプログラミングを学ぶことができます。それらが何をするかだけでなく、ソースコードもです。オープンソースムーブメントのあまり知られていない利点の1つは、プログラミングを学ぶことを容易にしたことです。私がプログラミングを学んだとき、私たちは、本の中の例に頼らざるを得ませんでした。当時入手できた唯一の大規模なコードはUnixでしたが、それでもオープンソースではありませんでした。ソースを読んだ人のほとんどは、ジョン・ライオンズの著書の違法な複写でそれを読みました。その本は1977年に書かれたにもかかわらず、1996年まで出版されることはありませんでした。
絵画から取ることができるもう1つの例は、絵画が段階的な洗練によって作成される方法です。絵画は、通常、スケッチから始まります。徐々に、詳細が埋められていきます。しかし、それは単に埋めるプロセスではありません。元の計画が間違っていることが判明することもあります。無数の絵画は、X線で見てみると、動かされた手足や調整された顔の特徴があることがわかります。
これは、絵画から学ぶことができるケースです。私は、ハッキングもこのように機能するべきだと思います。プログラムの仕様が完璧であると期待するのは非現実的です。あなたは、これを最初から認めて、仕様がその場で変更できるような方法でプログラムを書けば、より良いでしょう。
（大企業の構造は、彼らがこれを行うことを難しくするため、スタートアップが優位に立つもう1つの場所です。）
今では、誰もが早すぎる最適化の危険性を知っているはずです。私は、早すぎる設計、つまりプログラムが何をするべきかを早すぎる段階で決めることについて、同じように心配する必要があると思います。
適切なツールは、この危険を回避するのに役立ちます。良いプログラミング言語は、油絵のように、考えを変えることを容易にする必要があります。動的型付けは、ここで勝利です。なぜなら、あなたは最初から特定のデータ表現にコミットする必要がないからです。しかし、柔軟性の鍵は、言語を非常に抽象的にすることだと思います。変更が最も簡単なプログラムは、非常に短いプログラムです。
これはパラドックスのように聞こえますが、素晴らしい絵画は、あるべきよりも優れていなければなりません。たとえば、レオナルドがナショナルギャラリーにジネヴラ・デ・ベンチの肖像画を描いたとき、彼は彼女の頭の後ろにジュニパーの茂みを置きました。彼は、その中で、個々の葉をすべて注意深く描きました。多くの画家は、これは彼女の頭を囲む背景に入れるものだと思ったかもしれません。誰もそんなに注意深くは見ていません。
レオナルドではありません。彼が絵画の一部にどれほど熱心に働いたかは、彼が誰かにどれほど注意深く見てほしいかとはまったく関係ありませんでした。彼は、マイケル・ジョーダンみたいでした。容赦ない。
容赦なさは、集計において、目に見えない詳細が目に見えるようになるため、勝利します。人々がジネヴラ・デ・ベンチの肖像画の前を歩くと、ラベルを見てレオナルド・ダ・ヴィンチと書いてあることに気づく前に、彼らの注意はしばしばすぐにそれを引き付けられます。それらすべての目に見えない詳細は、千のほとんど聞こえない声がすべて調和して歌っているような、ただ素晴らしいものを生み出すために組み合わされます。
同様に、素晴らしいソフトウェアには、美しさへの狂信的な献身が必要です。良いソフトウェアの中をのぞいてみると、誰も見ることのない部分も美しいことに気づきます。私は、自分が素晴らしいソフトウェアを書いていると主張しているわけではありませんが、コードに関しては、日常生活に同じようにアプローチしたら、薬の処方を受ける資格があるような行動をとっていることは知っています。コードがひどくインデントされているのを見るのは、私を狂わせるし、醜い変数名を使用しているのもそうです。
ハッカーが単なる実装者であり、仕様をコードに変換するだけなら、彼は溝を掘る人と同じように、一方の端からもう一方の端まで順番に作業を進めることができます。しかし、ハッカーが創造者である場合、私たちはインスピレーションを考慮に入れなければなりません。
ハッキングでは、絵画のように、仕事はサイクルで行われます。時々、あなたは新しいプロジェクトに興奮し、1日に16時間働きたいと思うでしょう。他の時は、何も面白く見えません。
良い仕事をするためには、これらのサイクルを考慮に入れなければなりません。なぜなら、それらはあなたがそれらにどのように反応するかによって影響を受けるからです。坂道をマニュアルトランスミッションの車で運転しているとき、エンストルを防ぐために、時々クラッチを離す必要があります。同様に、離れることで、野心がエンストルするのを防ぐことができます。絵画とハッキングの両方において、恐ろしく野心的なタスクと、心地よく日常的なタスクがあります。エンストルする可能性のある瞬間のために、簡単なタスクをいくつか残しておくのは良い考えです。
ハッキングでは、これは文字通りバグを蓄えることを意味する可能性があります。私はデバッグが好きです。それは、ハッキングが人々が考えているように単純である唯一のときです。あなたは、完全に制約された問題を抱えており、あなたがしなければならないのは、それを解決することだけです。あなたのプログラムは、xをすることになっています。代わりに、それはyをします。どこで間違っていますか？あなたは、最終的に勝つことを知っています。それは、壁を塗るほどリラックスできます。
絵画の例は、私たち自身の仕事の管理方法だけでなく、協力する方法も教えてくれます。過去の偉大な芸術の多くは、複数の手による作品ですが、美術館の壁の隣には、1つの名前しか書かれていないかもしれません。レオナルドは、ヴェロッキオの工房で弟子入りし、彼のキリストの洗礼の天使の1人を描きました。この種のことは、例外ではなく、規則でした。ミケランジェロは、システィーナ礼拝堂の天井のすべての図を自分で描くことにこだわったため、特に献身的な人物と見なされていました。
私の知る限り、画家が絵画を共同で制作したとき、彼らは同じ部分で作業したことはありませんでした。マスターが主要な人物を描き、アシスタントが他のものと背景を描くのが一般的でした。しかし、1人が他人の作品の上に描くことはありませんでした。
私は、これがソフトウェアにおけるコラボレーションの正しいモデルだと思います。あまりにも押し付けないでください。コードが、3人または4人の異なる人によってハッキングされており、誰もが本当に所有していない場合、それは共通の部屋のようになります。それは、薄暗くて見捨てられたように感じられ、ゴミが溜まる傾向があります。正しいコラボレーションの方法は、プロジェクトを明確に定義されたモジュールに分割することだと思います。それぞれに明確な所有者がいて、それらの間のインターフェースは、プログラミング言語と同じように、注意深く設計され、可能であれば明確に表現されています。
絵画のように、ほとんどのソフトウェアは、人間の観客を対象としています。そのため、ハッカーは、画家と同じように、本当に素晴らしい仕事をするために、共感力を持たなければなりません。あなたは、ユーザーの視点から物事を見ることができなければなりません。
子供の頃、私はいつも、他人の視点から物事を見るように言われていました。実際、これは常に、私が望むことではなく、他の人が望むことをすることでした。もちろん、これは共感に悪い名前を与え、私はそれを育てることを避けていました。
少年時代、私は間違っていました。他人の視点から物事を見ることは、実際には成功の秘訣です。それは、必ずしも自己犠牲を意味するわけではありません。他の人がどのように物事を見ているかを理解することは、あなたが彼の利益のために行動することを意味するわけではありません。戦争など、状況によっては、まったく逆のことをしたいと思うでしょう。[4]
ほとんどの作り手は、人間の観客のために物事を作り出します。そして、観客を引き付けるためには、彼らのニーズを理解する必要があります。たとえば、ほとんどすべての偉大な絵画は、人々の絵画です。なぜなら、人々は人々が興味を持っているものだからです。
共感力は、おそらく、優れたハッカーと偉大なハッカーの最も重要な違いです。一部のハッカーは非常に賢いですが、共感に関しては、実際には唯我独尊です。そのような人にとって、素晴らしいソフトウェアを設計するのは難しいです。[5]なぜなら、彼らはユーザーの視点から物事を見ることができないからです。
人々が共感力を持っているかどうかを知る1つの方法は、彼らが技術的な背景のない人に技術的な質問を説明するのを見ることです。私たちは、そうでなければ賢いにもかかわらず、この点で非常に下手な人を知っているでしょう。誰かが夕食会で彼らにプログラミング言語とは何かを尋ねると、彼らは「ああ、高級言語は、コンパイラがオブジェクトコードを生成するために使用するものです」のようなことを言うでしょう。高級言語？コンパイラ？オブジェクトコード？プログラミング言語が何であるかを知らない人は、明らかにこれらのものが何であるかを知りません。
ソフトウェアがやらなければならないことの1つは、自分自身を説明することです。そのため、良いソフトウェアを書くためには、ユーザーがどれほど理解していないかを理解する必要があります。彼らは、準備なしでソフトウェアに近づき、それは彼らが推測する通りに動作する必要があります。なぜなら、彼らはマニュアルを読まないからです。この点で私が見た最高のシステムは、1985年のオリジナルのMacintoshでした。それは、ソフトウェアがほとんどしないことをしました。それは単に機能しました。[6]
ソースコードも、自分自身を説明する必要があります。もし私が人々にプログラミングについて1つの引用を覚えていてもらうことができたら、それはStructure and Interpretation of Computer Programsの冒頭の引用でしょう。
プログラムは、人間が読むために書かれるべきであり、機械が実行するために書かれるのは偶然です。
あなたは、ユーザーだけでなく、読者に対しても共感力を持つ必要があります。それはあなたの利益になります。なぜなら、あなたは彼らの1人になるからです。多くのハッカーは、プログラムを書いて、6か月後にそれに戻ると、どのように機能するのかまったくわからないことに気づきました。私は、そのような経験の後、Perlを避けてきた人が何人かいます。[7]
共感力の欠如は、知性と関連付けられており、一部の場所では、それに対する一種の流行さえあります。しかし、私は相関関係はないと思います。あなたは、共感力を学ぶ必要なしに、数学や自然科学でうまくいくことができ、これらの分野の人々は賢い傾向があるため、2つの特性は関連付けられるようになりました。しかし、共感力がないために愚かな人はたくさんいます。トークショーで質問をして電話をかけてくる人たちの話を聞いてみてください。彼らは、ホストが彼らに代わって質問を言い換える必要があるほど、回りくどい方法で質問をします。
では、ハッキングは絵画や執筆のように、クールなのでしょうか？結局のところ、あなたは人生を1度しか生きられません。あなたは、素晴らしいことに時間を費やすべきです。
残念ながら、その質問に答えるのは難しいです。威信には、常に大きな時間差があります。それは、遠くの星からの光のようなものです。絵画は、500年前に人々がやった素晴らしい仕事のために、今威信があります。当時、誰もこれらの絵画を私たちが今日のように重要だとは思っていませんでした。当時の人々にとって、ウルビーノ公爵フェデリコ・ダ・モンテフェルトロが、ピエロ・デラ・フランチェスカによる絵画の中で、奇妙な鼻をした男として知られるようになるのは、非常に奇妙に思えたでしょう。
そのため、ハッキングは今の絵画ほどクールには見えないことを認めますが、絵画自体も、その全盛期には、今ほどクールには見えませんでした。
私たちが自信を持って言えることは、これがハッキングの全盛期であるということです。ほとんどの分野では、偉大な仕事は初期に行われます。1430年から1500年の間に作られた絵画は、まだ比類のないものです。シェイクスピアは、プロの劇場が誕生したまさにその時に登場しました。
そして、その媒体を押し上げました。それ以来、すべての劇作家は、彼の影の中で生きなければなりませんでした。アルブレヒト・デューラーは、版画で同じことをしました。そして、ジェーン・オースティンは、小説で同じことをしました。
私たちは、何度も同じパターンを見てきました。新しい媒体が登場し、人々はそれに非常に興奮しているので、最初の2世代でその可能性のほとんどを探求します。ハッキングは、今、この段階にあるようです。
レオナルドの時代には、絵画は、彼の作品がそれをクールにしたほどクールではありませんでした。ハッキングがどれほどクールになるかは、私たちがこの新しい媒体で何ができるかによって異なります。
注記
[1] 写真が絵画に与えた最大の損害は、最高の副業を殺してしまったことかもしれません。歴史上の偉大な画家のほとんどは、肖像画を描くことで生計を立てていました。
[2] 私は、Microsoftは、従業員が、自分の時間であっても、オープンソースプロジェクトに貢献することを阻止していると聞きました。しかし、最高のハッカーの多くが、今ではオープンソースプロジェクトに取り組んでいるため、このポリシーの主な影響は、彼らが一流のプログラマーを雇うことができなくなることを保証することかもしれません。
[3] 大学でプログラミングについて学ぶことは、本や服やデートについて学ぶことによく似ています。高校時代にどんな悪趣味を持っていたか。
[4] これは、応用共感力の例です。Viawebでは、2つの選択肢の間で決められない場合、私たちは、競合他社が最も嫌うのは何かを尋ねました。ある時点で、競合他社は、基本的に役に立たない機能をソフトウェアに追加しました。しかし、それは私たちが持っていない数少ない機能の1つだったので、彼らはそれを業界誌で大きく取り上げました。私たちは、その機能が役に立たないことを説明しようとしましたが、私たちがそれを自分で実装すれば、競合他社をもっとイライラさせるだろうと判断したので、その日の午後に独自のバージョンをハッキングでまとめました。
[5] テキストエディタとコンパイラを除いて。ハッカーは、これらの設計に共感力を必要としません。なぜなら、彼らは自分自身も典型的なユーザーだからです。
[6] まあ、ほとんど。彼らは、利用可能なRAMを少し超過し、多くの不便なディスクスワッピングを引き起こしましたが、これは、追加のディスクドライブを購入することで、数か月以内に修正できました。
[7] プログラムを読みやすくするための方法は、コメントを詰め込むことではありません。私は、エイベルソンとサスマンの引用をさらに一歩進めたいと思います。プログラミング言語は、アルゴリズムを表現するために設計されるべきであり、コンピュータに実行方法を伝えるのは偶然です。良いプログラミング言語は、英語よりもソフトウェアを説明するのに適しているはずです。あなたは、道路に予想外の急なカーブがある部分にだけ矢印があるのと同じように、読者に警告する必要があるような、何らかのハックがある場合にのみ、コメントを必要とするはずです。
謝辞 この原稿を読んでくれたトレバー・ブラックウェル、ロバート・モリス、ダン・ギフィン、リサ・ランドールに感謝します。そして、ヘンリー・ライトナーとラリー・フィンケルスタインに、講演の機会を与えてくれたことに感謝します。