Хакеры и художники

(Это эссе основано на гостевой лекции в Гарварде, в которую вошли материалы более раннего выступления в Северо-Восточном университете.)

Окончив аспирантуру по компьютерным наукам, я поступил в художественную школу, чтобы учиться живописи. Многих удивляло, что человек, интересующийся компьютерами, может одновременно интересоваться живописью. Казалось, они считали программирование и живопись совершенно разными видами деятельности: программирование представлялось им холодным, точным и методичным, а живопись — неистовым выражением некоего первобытного порыва.

Оба эти представления ошибочны. У хакерства и живописи очень много общего. На самом деле, из всех людей, которых я знал, хакеры и художники похожи друг на друга сильнее всего.

Хакеры и художники схожи тем, что и те и другие — создатели. Наряду с композиторами, архитекторами и писателями, хакеры и художники стремятся делать хорошие вещи. Они не занимаются исследованиями как таковыми, хотя если в процессе создания хороших вещей они открывают новый прием — тем лучше.

Мне никогда не нравился термин «computer science» (компьютерные науки). Главная причина моей нелюбви в том, что такой науки просто не существует. Computer science — это сборная солянка из слабо связанных между собой областей, объединенных исторической случайностью, прямо как Югославия. На одном полюсе находятся люди, которые на самом деле математики, но называют то, чем занимаются, компьютерными науками, чтобы получать гранты DARPA. Посередине — те, кто занимается чем-то вроде естественной истории компьютеров, например, изучением поведения алгоритмов маршрутизации данных в сетях. А на другом полюсе — хакеры, которые пытаются писать интересные программы и для которых компьютеры служат лишь средством выражения, подобно бетону для архитекторов или краскам для художников. Это всё равно что поместить математиков, физиков и архитекторов на один факультет.

Иногда то, чем занимаются хакеры, называют «программной инженерией», но этот термин столь же обманчив. Хорошие разработчики программного обеспечения — такие же инженеры, как и архитекторы. Граница между архитектурой и инженерией не имеет четких очертаний, но она существует. Она пролегает между «что» и «как»: архитекторы решают, что делать, а инженеры придумывают, как это сделать.

Не стоит слишком сильно разделять «что» и «как». Пытаясь решить, что делать, без понимания того, как это сделать, вы наживете себе неприятностей. Но программирование определенно может быть чем-то большим, чем просто решением задачи реализации чужой спецификации. В лучшем своем проявлении оно заключается в создании самой спецификации — хотя, как показывает практика, лучший способ создать спецификацию — это реализовать ее.

Возможно, однажды «computer science», подобно Югославии, распадется на составные части. И это было бы к лучшему. Особенно если это принесет независимость моей родине — хакерству.

Сваливать все эти разные виды деятельности в один факультет может быть удобно административно, но это сбивает с толку интеллектуально. Это вторая причина, по которой мне не нравится название «computer science». Можно утверждать, что люди посередине занимаются чем-то вроде экспериментальной науки. Но люди на обоих полюсах — хакеры и математики — на самом деле наукой не занимаются.

Математиков это, кажется, не беспокоит. Они с радостью берутся доказывать теоремы, точно так же, как их коллеги с математического факультета, и, вероятно, вскоре перестают замечать надпись «компьютерные науки» на фасаде здания. Но для хакеров этот ярлык представляет проблему. Если то, чем они занимаются, называют наукой, у них возникает чувство, что они должны вести себя по-научному. Поэтому вместо того, чтобы заниматься тем, чем им действительно хочется — создавать прекрасные программы, — хакеры в университетах и исследовательских лабораториях чувствуют себя обязанными писать научные статьи.

В лучшем случае эти статьи — лишь формальность. Хакеры пишут классную программу, затем пишут о ней статью, и эта статья становится формальным эквивалентом достижения, воплощенного в коде. Но часто это несоответствие порождает проблемы. Очень легко незаметно перейти от создания прекрасных вещей к созданию уродливых конструкций, которые просто лучше подходят в качестве темы для научных публикаций.

К сожалению, прекрасные вещи не всегда служат лучшими темами для статей. Во-первых, исследование должно быть оригинальным — а всякий, кто писал кандидатскую диссертацию, знает: самый надежный способ оказаться на нетронутой целине — это застолбить участок, который даром никому не нужен. Во-вторых, исследование должно быть весомым — а неуклюжие, тяжеловесные системы дают материал для более содержательных статей, ведь можно написать обо всех препятствиях, которые пришлось преодолеть, чтобы всё заработало. Ничто не порождает столько «содержательных» проблем, как отправная точка из неверных предпосылок. Большая часть исследований в области искусственного интеллекта — пример этого правила: если предположить, что знания можно представить в виде списка выражений логики предикатов, аргументы которых обозначают абстрактные понятия, вам придется написать уйму статей о том, как заставить это работать. Как говаривал Рики Рикардо: «Люси, тебе придется многое объяснить».

Путь к созданию чего-то прекрасного часто заключается в тонкой доработке уже существующего или в объединении старых идей чуть по-новому. Такого рода работу трудно преподнести в научной статье.

Так почему же университеты и исследовательские лаборатории продолжают судить о хакерах по публикациям? По той же причине, по которой «способность к обучению» измеряют примитивными стандартизированными тестами, а производительность программистов — строками кода. Эти тесты легко применять, а нет ничего более соблазнительного, чем простой тест, который хоть как-то работает.

Оценить то, к чему хакеры стремятся на самом деле — создание прекрасного софта, — было бы гораздо сложнее. Чтобы судить о хорошем дизайне, нужно иметь хорошее чувство вкуса. При этом между способностью людей распознавать хороший дизайн и их уверенностью в том, что они на это способны, нет никакой корреляции, если не считать, возможно, отрицательной.

Единственный объективный критерий со стороны — это время. Со временем прекрасные вещи обычно выживают и расцветают, а уродливые отбрасываются. К сожалению, требуемые для этого сроки могут превышать продолжительность человеческой жизни. Сэмюэл Джонсон говорил, что для установления репутации писателя требуется сто лет. Приходится ждать, пока умрут влиятельные друзья писателя, а затем и все их последователи.

Думаю, хакерам остается лишь смириться с тем, что в их репутации велика доля случайности. В этом они ничем не отличаются от других создателей. На самом деле им даже повезло по сравнению с остальными. Влияние моды в программировании далеко не так велико, как в живописи.

Есть вещи похуже непонимания со стороны окружающих. Куда более опасная вещь — неправильно понимать собственную работу самому. Идеи обычно ищут в смежных областях. Оказавшись на факультете компьютерных наук, поддаешься естественному искушению поверить, например, что программирование — это прикладная версия того, теорией чего выступает теоретическая информатика. Все годы в аспирантуре меня на задворках сознания преследовало неприятное чувство, что я должен знать больше теории, и что с моей стороны крайне безответственно забывать весь этот материал уже через три недели после экзамена.

Теперь я понимаю, что ошибался. Хакеру теория вычислений нужна примерно в той же степени, в какой художнику нужна химия красок. Нужно уметь рассчитывать временную и пространственную сложность и понимать полноту по Тьюрингу. Стоит также помнить хотя бы концепцию конечного автомата на случай, если придется писать парсер или библиотеку регулярных выражений. Художникам, по правде говоря, приходится помнить о химии красок куда больше.

Я обнаружил, что лучшие источники идей — это не другие области со словом «компьютерный» в названии, а другие сферы деятельности, населенные создателями. Живопись стала для меня гораздо более богатым источником идей, чем теория вычислений.

Например, в колледже меня учили, что программу нужно полностью продумать на бумаге, прежде чем вообще приближаться к компьютеру. Я обнаружил, что сам я так программировать не могу. Мне нравилось программировать, сидя перед компьютером, а не перед листком бумаги. Хуже того: вместо того чтобы терпеливо выписывать законченную программу и удостоверяться в ее корректности, я выдавал безнадежно сломанный код и постепенно приводил его в порядок. Отладка, как меня учили, должна была быть финальным этапом, на котором вы вылавливаете опечатки и недочеты. В моем же стиле работы казалось, будто программирование только из отладки и состоит.

Долгое время я корил себя за это, точно так же, как когда-то переживал из-за того, что держу карандаш не так, как учили в начальной школе. Если бы я только посмотрел на других создателей — на художников или архитекторов, — я бы понял, что для моих действий есть название: набросок, эскиз. Насколько я могу судить, то, как меня учили программировать в колледже, было в корне неверно. Программы нужно придумывать в процессе их написания — точно так же, как работают писатели, художники и архитекторы.

Осознание этого имеет вполне конкретные последствия для проектирования программного обеспечения. Это означает, что язык программирования должен быть прежде всего пластичным. Язык программирования нужен для того, чтобы думать программами, а не для записи программ, которые вы уже полностью продумали. Он должен быть карандашом, а не чернильной ручкой. Статическая типизация была бы отличной идеей, если бы люди действительно писали программы так, как меня учили в колледже. Но никто из знакомых мне хакеров так не пишет. Нам нужен язык, который позволяет черкать, мазать и растирать штрихи, а не язык, где приходится сидеть с чашечкой типов на коленях и вести вежливую беседу со строгой тетушкой-компилятором.

Раз уж мы заговорили о статической типизации: отождествление себя с создателями избавит нас еще от одной проблемы, мучающей науку, — зависти к математике. Все в научных кругах втайне считают, что математики умнее их. Думаю, сами математики тоже так считают. В любом случае, это приводит к тому, что ученые стремятся придать своим работам как можно более математический вид. В такой области, как физика, это, вероятно, не приносит большого вреда, но чем дальше вы удаляетесь от естественных наук, тем большей проблемой это становится.

Страница, испещренная формулами, выглядит так внушительно! (Совет: для пущей солидности используйте греческие буквы.) Возникает огромный соблазн браться за проблемы, которые можно описать формально, а не за те, которые, скажем так, действительно важны.

Если бы хакеры отождествляли себя с другими создателями — например, писателями и художниками, — у них не возникало бы такого соблазна. Писатели и художники не страдают завистью к математике. Они чувствуют, что занимаются чем-то совершенно иным. Хакеры, по-моему, тоже.

Если университеты и исследовательские лаборатории мешают хакерам делать то, что они хотят, возможно, их место в коммерческих компаниях? К сожалению, большинство компаний тоже не дают хакерам делать то, к чему лежит душа. Университеты и лаборатории заставляют хакеров быть учеными, а компании заставляют их быть инженерами.

Я сам понял это совсем недавно. Когда Yahoo купила Viaweb, меня спросили, чем я хочу заниматься. Бизнес-сторона мне никогда особо не нравилась, и я ответил, что просто хочу хакерить, писать код. Оказавшись в Yahoo, я обнаружил, что под хакерством они понимают реализацию софта, а не его проектирование. Программистов там воспринимали как технических исполнителей, переводивших видение (если это можно так назвать) продакт-менеджеров в код.

Похоже, в крупных компаниях это схема по умолчанию. Они поступают так, потому что это снижает стандартное отклонение конечного результата. Лишь малая часть хакеров действительно умеет проектировать софт, и руководству компании трудно их распознать. Поэтому вместо того, чтобы доверить будущее продукта одному блестящему хакеру, большинство компаний организуют процесс так, чтобы дизайн разрабатывался комитетом, а хакеры просто реализовывали утвержденный проект.

Если вы когда-нибудь захотите заработать денег, запомните это: именно в этом кроется одна из причин, почему побеждают стартапы. Крупные компании стремятся снизить стандартное отклонение результатов проектирования, потому что хотят избежать катастроф. Но когда вы гасите колебания, вы срезаете не только провалы, но и вершины. Для больших компаний это не проблема, ведь они побеждают не за счет создания великолепных продуктов. Крупные компании побеждают за счет того, что они лажают меньше других крупных компаний.

Поэтому, если вам удастся ввязаться в войну дизайна с компанией, достаточно крупной для того, чтобы ее продукты проектировались продакт-менеджерами, они никогда за вами не успеют. Такие возможности, правда, нелегко найти. Трудно навязать большой компании войну дизайна — так же, как трудно заставить засевшего в крепости противника сойтись в рукопашном бою. Было бы довольно легко написать текстовый процессор лучше, чем Microsoft Word, но Microsoft, укрывшись в замке своей монополии на операционные системы, вероятно, даже не заметила бы этого.

Место для войн за дизайн — это новые рынки, где еще никто не успел возвести укрепления. Именно там можно сорвать куш благодаря смелому подходу к проектированию, когда одни и те же люди и проектируют продукт, и реализуют его. Сама Microsoft начинала именно так. Как и Apple. И Hewlett-Packard. Подозреваю, так начинал почти каждый успешный стартап.

Итак, один из способов создавать великолепный софт — основать собственный стартап. Правда, здесь есть две проблемы. Во-первых, в стартапе приходится делать слишком много всего помимо написания кода. В Viaweb я считал за счастье, если мне удавалось кодить хотя бы четверть времени. А занятия, занимавшие остальные три четверти, варьировались от занудных до ужасающих. У меня есть эталон для сравнения: однажды мне пришлось уйти с заседания совета директоров, чтобы залечить несколько зубов. Помню, как я откинулся в кресле стоматолога в ожидании бормашины и почувствовал, будто ушел в отпуск.

Вторая проблема со стартапами заключается в том, что софт, приносящий деньги, и софт, который интересно писать, редко совпадают. Языки программирования писать интересно — и первым продуктом Microsoft был как раз язык программирования, — но сегодня никто не станет платить за языки программирования. Если вы хотите зарабатывать деньги, вам обычно приходится решать задачи, которые слишком неприятны, чтобы кто-то взялся за них бесплатно.

С этой проблемой сталкиваются все создатели. Цены определяются спросом и предложением, и на то, над чем работать приятно, спрос просто не так высок, как на решение обыденных задач отдельных клиентов. Игра в спектаклях внебродвейских театров приносит куда меньше денег, чем разгуливание в костюме гориллы у чьего-то стенда на выставке. Написание романов оплачивается хуже, чем составление рекламных текстов для измельчителей мусора. А разработка языков программирования не приносит столько денег, сколько решение проблемы подключения старой корпоративной базы данных к веб-серверу.

Мне кажется, ответом на эту проблему в программировании служит понятие, знакомое практически всем создателям: дневная работа (day job). Это выражение пошло от музыкантов, которые выступают по ночам. В более широком смысле оно означает, что одной работой вы занимаетесь ради денег, а другой — для души.

В начале карьеры дневная работа есть почти у всех создателей. У художников и писателей — почти наверняка. Если повезет, можно найти дневную работу, тесно связанную с вашей основной страстью. Музыканты часто работают в музыкальных магазинах. Хакер, работающий над языком программирования или операционной системой, точно так же может найти дневную работу, где они используются. [1]

Когда я говорю, что выход для хакеров — иметь дневную работу и параллельно писать прекрасный софт для души, я не предлагаю ничего нового. В этом и заключается суть опенсорса. Я лишь говорю о том, что опенсорс — это, вероятно, правильная модель, поскольку ее состоятельность независимо подтверждена всеми остальными создателями.

Меня удивляет, что некоторые работодатели неохотно разрешают хакерам участвовать в опенсорс-проектах. В Viaweb мы, наоборот, неохотно нанимали тех, кто этим не занимался. На собеседованиях с программистами нас в первую очередь интересовало, какой софт они пишут в свободное время. Нельзя делать что-то действительно хорошо, если ты этого не любишь, а если ты любишь программировать, у тебя неизбежно появятся собственные проекты. [2]

Поскольку хакеры — это скорее создатели, чем ученые, метафоры стоит искать не в науке, а среди других видов творцов. Чему еще живопись может научить нас в отношении хакерства?

Одна вещь, которую мы можем перенять или, по крайней мере, подтвердить на примере живописи, — это то, как учиться программировать. Учиться живописи можно в основном на практике. То же самое справедливо и для хакерства. Большинство хакеров учатся своему ремеслу не на университетских курсах по программированию. Они учатся программировать, создавая собственные программы в тринадцать лет. Даже на парах в университете вы учитесь программировать главным образом через саму практику написания кода. [3]

Поскольку художники оставляют за собой цепочку работ, можно воочию наблюдать, как они учатся на практике. Если посмотреть на работы художника в хронологическом порядке, станет видно, что каждая следующая картина опирается на то, что было усвоено в предыдущих. Если в картине есть что-то очень удачное, обычно можно найти «версию 1.0» этой детали в уменьшенном масштабе на каком-нибудь более раннем полотне.

Думаю, большинство создателей работают именно так. Писатели и архитекторы, похоже, тоже. Возможно, хакерам стоило бы чаще вести себя как художники и регулярно начинать всё с нуля, вместо того чтобы годами пилить один проект, пытаясь втиснуть все свои новые идеи в виде бесконечных правок.

Тот факт, что хакеры учатся программировать на практике, лишний раз доказывает, насколько хакерство отличается от науки. Ученые учатся науке не в процессе открытий, а выполняя лабораторные работы и решая задачи из сборников. Ученые начинают с идеальной работы — в том смысле, что они просто воспроизводят результаты, уже полученные кем-то до них. Со временем они доходят до стадии, когда могут делать что-то оригинальное. Хакеры же с самого начала делают оригинальные вещи — просто они получаются ужасно плохими. Таким образом, хакеры начинают с оригинальности и приходят к качеству, а ученые начинают с качества и приходят к оригинальности.

Другой способ обучения создателей — на примерах. Для художника музей — это справочная библиотека технических приемов. На протяжении сотен лет традиционное образование художников включало копирование работ великих мастеров, ведь копирование заставляет внимательно вглядываться в то, как именно создана картина.

Писатели делают то же самое. Бенджамин Франклин учился писать, конспектируя основные мысли из эссе Аддисона и Стила, а затем пытаясь воспроизвести их текст по памяти. Реймонд Чандлер проделывал то же самое с детективными рассказами.

Точно так же и хакеры могут учиться программированию, изучая хорошие программы — не просто то, что они делают, но и сам исходный код. Одно из наименее афишируемых преимуществ движения за открытый исходный код состоит в том, что оно упростило обучение программированию. Когда я учился кодить, нам приходилось полагаться в основном на примеры из книг. Единственным доступным тогда крупным куском кода был Unix, но даже он не был открытым. Большинство людей, читавших этот исходный код, изучали его по подпольным ксерокопиям книги Джона Лайонса, которая, хотя и была написана в 1977 году, не разрешалась к открытой публикации вплоть до 1996 года.

Еще один пример, который мы можем позаимствовать у живописи, — это создание произведения путем постепенного уточнения деталей. Картины обычно начинаются с наброска. Детали прорисовываются постепенно. Но это не просто механическое заполнение контуров. Порой первоначальный замысел оказывается ошибочным. Бесчисленные картины, если взглянуть на них в рентгеновских лучах, содержат скрытые слои: там смещены руки и ноги или перерисованы черты лица.

Вот пример того, чему мы можем поучиться у живописи. Думаю, программирование должно строиться так же. Нереалистично ожидать, что спецификации на программу сразу окажутся идеальными. Гораздо лучше признать это с самого начала и писать программы таким образом, чтобы спецификации могли меняться на лету.

(Структура крупных компаний мешает им работать подобным образом, и в этом еще одно преимущество стартапов.)

Об опасности преждевременной оптимизации к настоящему моменту знают, пожалуй, все. Думаю, нам следует в той же мере опасаться преждевременного проектирования — слишком раннего принятия решений о том, что именно должна делать программа.

Правильные инструменты помогают избежать этой опасности. Хороший язык программирования должен, подобно масляным краскам, позволять легко передумать. Динамическая типизация здесь дает преимущество, потому что вам не нужно заранее связывать себя конкретными представлениями данных. Но ключ к гибкости, на мой взгляд, кроется в том, чтобы сделать язык в высшей степени абстрактным. Проще всего изменить ту программу, которая короче всего.

Это звучит парадоксально, но великая картина должна быть лучше, чем того требуют обстоятельства. Например, когда Леонардо писал портрет Джиневры де Бенчи, который хранится в Национальной галерее, он поместил за ее головой куст можжевельника. И он тщательно выписал на нем каждый отдельный листочек. Многие художники подумали бы: это всего лишь фон, чтобы обрамить ее лицо, никто не станет разглядывать его так внимательно.

Но только не Леонардо. То, с каким усердием он прорабатывал деталь картины, нисколько не зависело от того, насколько пристального внимания он ждал от зрителя. Он был как Майкл Джордан. Неумолимым и беспощадным к себе.

Бескомпромиссность побеждает потому, что в совокупности невидимые детали становятся заметными. Когда люди проходят мимо портрета Джиневры де Бенчи, их внимание часто оказывается приковано к нему мгновенно, еще до того, как они взглянут на табличку и заметят имя Леонардо да Винчи. Все эти невидимые детали объединяются, создавая нечто просто ошеломляющее — подобно тысяче едва слышных голосов, поющих в унисон.

Великое программное обеспечение точно так же требует фанатичной преданности красоте. Заглянув внутрь хорошего софта, вы увидите, что части, которые никто никогда не должен был увидеть, тоже прекрасны. Я не утверждаю, что сам пишу великий софт, но знаю, что в отношении кода веду себя так, что за подобное поведение в повседневной жизни мне бы наверняка выписали рецепт на сильнодействующие препараты. Я выхожу из себя, когда вижу код с кривыми отступами или уродливыми именами переменных.

Если бы хакер был всего лишь исполнителем, переводящим спецификацию в код, он мог бы методично продвигаться от начала до конца, словно землекоп, копающий траншею. Но если хакер — творец, нам приходится считаться с вдохновением.

В хакерстве, как и в живописи, работа идет циклами. Порой вас захватывает новый проект, и вы готовы работать над ним по шестнадцать часов в сутки. В другое время ничто не кажется интересным.

Чтобы делать хорошую работу, эти циклы необходимо учитывать, поскольку они зависят от того, как вы на них реагируете. Когда вы едете на машине с механической коробкой передач в гору, иногда приходится выжимать сцепление, чтобы мотор не заглох. Сбавление оборотов точно так же помогает предотвратить угасание запала. И в живописи, и в хакерстве есть задачи пугающе масштабные, а есть — успокаивающе рутинные. Имеет смысл приберегать простые задачи для тех моментов, когда вы рискуете заглохнуть.

В хакерстве это буквально может означать откладывание багов на потом. Я люблю отладку: это единственный момент, когда программирование оказывается столь же простым и понятным, каким его считают со стороны. Перед вами строго очерченная проблема, и всё, что требуется, — это решить ее. Ваша программа должна делать X. Вместо этого она делает Y. Где кроется ошибка? Вы твердо знаете, что в итоге победите. Это расслабляет не хуже, чем покраска забора.

Пример живописи может научить нас не только тому, как управлять собственной работой, но и тому, как работать вместе. Многие великие произведения искусства прошлого созданы несколькими парами рук, хотя на стене музея рядом с ними может висеть табличка лишь с одним именем. Леонардо был подмастерьем в мастерской Верроккьо и написал одного из ангелов в его «Крещении Христа». Подобные вещи были правилом, а не исключением. Микеланджело считался исключительно преданным своему делу человеком за то, что настоял на самостоятельном написании всех фигур на потолке Сикстинской капеллы.

Насколько мне известно, когда художники работали над картиной сообща, они никогда не писали одни и те же фрагменты. Обычно мастер писал главные фигуры, а помощники — остальных персонажей и фон. Но никогда не бывало так, чтобы один человек переписывал работу другого поверх.

Полагаю, это правильная модель сотрудничества и в разработке программного обеспечения. Не стоит заходить слишком далеко. Когда кусок кода пишется тремя-четырьмя разными людьми, ни один из которых им по-настоящему не владеет, в итоге он превращается в нечто вроде общей комнаты в общежитии. Он выглядит унылым и заброшенным и быстро обрастает хламом. Правильный способ совместной работы, на мой взгляд, состоит в том, чтобы разделять проекты на четко определенные модули, у каждого из которых есть конкретный владелец, а интерфейсы между ними спроектированы столь же тщательно и, по возможности, столь же выразительны, как языки программирования.

Как и живопись, большая часть программного обеспечения предназначена для людей. И поэтому хакерам, как и художникам, необходима эмпатия, чтобы создавать по-настоящему выдающиеся вещи. Вы должны уметь смотреть на вещи с точки зрения пользователя.

В детстве мне постоянно говорили, что нужно смотреть на вещи с точки зрения других людей. На практике это всегда означало делать то, чего хочет кто-то другой, вместо того, чего хотелось мне. Из-за этого эмпатия, конечно, приобрела дурную славу, и я сознательно избегал ее развития.

Боже, как же я ошибался. Оказывается, умение смотреть на вещи с чужой точки зрения — это практически секрет успеха. Это вовсе не обязательно означает самопожертвование. Отнюдь. Понимание того, как другой человек видит вещи, не подразумевает, что вы будете действовать в его интересах; в некоторых ситуациях — например, на войне — вам захочется поступить с точностью до наоборот. [4]

Большинство творцов создают вещи для человеческой аудитории. А чтобы увлечь аудиторию, вы должны понимать ее потребности. Почти все величайшие картины — это изображения людей, потому что именно люди интересны людям больше всего.

Эмпатия — это, пожалуй, самое главное отличие хорошего хакера от великого. Некоторые хакеры весьма умны, но когда дело касается эмпатии, они оказываются практически солипсистами. Таким людям трудно проектировать прекрасный софт [5], потому что они не способны взглянуть на вещи с точки зрения пользователя.

Один из способов определить, насколько человек способен к эмпатии, — понаблюдать, как он объясняет технический вопрос тому, кто далек от техники. Мы все, вероятно, знаем людей, которые, будучи вполне умными во всем остальном, в этом отношении комически безнадежны. Если кто-нибудь на званом ужине спросит их, что такое язык программирования, они выдадут что-то вроде: «О, язык высокого уровня — это то, что компилятор использует в качестве входных данных для генерации объектного кода». Язык высокого уровня? Компилятор? Объектный код? Тот, кто не знает, что такое язык программирования, очевидно, не знает и значения этих слов.

Часть работы софта состоит в том, чтобы объяснять самого себя. Поэтому, чтобы писать хорошие программы, нужно понимать, насколько мало понимают пользователи. Они подойдут к программе без всякой подготовки, и лучше бы ей делать именно то, о чем они догадываются сами, потому что читать инструкцию они не станут. Лучшей системой в этом отношении из всех, что я видел, был оригинальный Macintosh в 1985 году. Он делал то, что программное обеспечение почти никогда не делает: он просто работал. [6]

Исходный код тоже должен объяснять себя сам. Если бы я мог сделать так, чтобы люди запомнили всего одну цитату о программировании, это была бы фраза из начала книги Structure and Interpretation of Computer Programs («Структура и интерпретация компьютерных программ»):

Программы должны писаться для того, чтобы люди их читали, и лишь попутно — для того, чтобы машины их исполняли.

Вам нужна эмпатия не только по отношению к пользователям, но и по отношению к читателям вашего кода. Это в ваших же интересах, ведь одним из них будете вы сами. Сколько хакеров написали программу только для того, чтобы, вернувшись к ней через полгода, обнаружить, что они понятия не имеют, как она работает. Я знаю нескольких человек, которые после подобного опыта навсегда зареклись писать на Perl. [7]

Отсутствие эмпатии часто связывают с интеллектом, вплоть до того, что в некоторых кругах на это даже возникла своеобразная мода. Но я не думаю, что тут есть какая-то корреляция. Можно преуспевать в математике и естественных науках, не развивая в себе эмпатию, а люди в этих областях обычно умны, так что эти два качества стали ассоциироваться друг с другом. Но есть масса глупых людей, которые точно так же лишены эмпатии. Просто послушайте тех, кто дозванивается с вопросами на ток-шоу. Они формулируют то, о чем хотят спросить, настолько путано и вокруг да около, что ведущим часто приходится перефразировать вопрос за них.

Итак, если хакерство устроено так же, как живопись и литература, столь же ли оно круто? В конце концов, жизнь дается всего одна. Ее с тем же успехом можно посвятить созданию чего-то великого.

К сожалению, на этот вопрос трудно ответить. В престиже всегда есть большой временной лаг. Это как свет далекой звезды. Живопись обладает престижем сейчас благодаря великим работам, созданным пятьсот лет назад. В то время никто не считал эти картины столь важными, какими мы считаем их сегодня. Людям той эпохи показалось бы крайне странным, что Федерико да Монтефельтро, герцог Урбинский, когда-нибудь останется в памяти в основном как человек со странным носом на картине Пьеро делла Франческа.

Так что, хотя я признаю, что сейчас хакерство не кажется столь же крутым, как живопись, нам следует помнить: сама живопись в дни своего расцвета отнюдь не выглядела столь крутой, как теперь.

Что мы можем сказать с некоторой уверенностью, так это то, что прямо сейчас наступили золотые дни хакерства. В большинстве областей величайшие работы создаются на ранних этапах. Картины, написанные между 1430 и 1500 годами, до сих пор непревзойденны. Шекспир появился как раз тогда, когда зарождался профессиональный театр, и продвинул это искусство так далеко вперед, что всем последующим драматургам пришлось жить в его тени. Альбрехт Дюрер проделал то же самое с гравюрой, а Джейн Остин — с романом.

Снова и снова мы наблюдаем одну и ту же закономерность. Появляется новая форма выражения, и люди настолько ею увлечены, что исследуют большую часть ее возможностей уже в течение первых пары поколений. Хакерство, похоже, сейчас находится именно в этой фазе.

Живопись во времена Леонардо не была настолько крутой, какой ее помогли сделать его работы. То, насколько крутым окажется хакерство, будет зависеть от того, что мы сможем сделать с этой новой формой.

Примечания

[1] Самый большой ущерб, который фотография нанесла живописи, вероятно, заключается в том, что она уничтожила лучший способ заработка на жизнь. Большинство великих художников в истории обеспечивали себя написанием портретов.

[2] Мне говорили, что Microsoft запрещает сотрудникам участвовать в проектах с открытым исходным кодом даже в свободное время. Но сейчас так много лучших хакеров работает над проектами с открытым исходным кодом, что главным последствием этой политики может стать то, что они просто не смогут нанять ни одного первоклассного программиста.

[3] То, что вы узнаете о программировании в колледже, очень похоже на то, что вы узнаете о книгах, одежде или свиданиях: насколько ужасный вкус был у вас в старших классах.

[4] Вот пример прикладной эмпатии. В Viaweb, если мы не могли выбрать между двумя вариантами, мы спрашивали себя: что больше всего возненавидят наши конкуренты? В какой-то момент конкурент добавил в свою программу функцию, которая была в сущности бесполезной, но поскольку это была одна из немногих функций, которые были у них и отсутствовали у нас, они подняли вокруг нее много шума в отраслевой прессе. Мы могли бы попытаться объяснить, что эта функция бесполезна, но решили, что конкурента сильнее взбесит, если мы просто реализуем ее сами, поэтому за тот же вечер набросали собственную версию.

[5] За исключением текстовых редакторов и компиляторов. Хакерам не нужна эмпатия для их проектирования, потому что они сами являются их типичными пользователями.

[6] Ну, почти. Они несколько переоценили доступный объем оперативной памяти, что приводило к постоянной и неудобной смене дискет, но это можно было исправить за пару месяцев, купив дополнительный дисковод.

[7] Способ сделать программы легко читаемыми заключается вовсе не в том, чтобы напичкать их комментариями. Я бы развил цитату Абельсона и Сассмана на шаг вперед. Языки программирования должны разрабатываться для выражения алгоритмов и лишь попутно — для того, чтобы сообщать компьютерам, как их исполнять. Хороший язык программирования должен подходить для объяснения работы софта лучше, чем английский. Комментарии должны требоваться только тогда, когда вам нужно предупредить читателей о каком-то костыле, точно так же, как стрелки на дороге появляются только на участках с неожиданно крутыми поворотами.

Благодарности: Тревору Блэквеллу, Роберту Моррису, Дэну Гиффину и Лизе Рэндалл за чтение черновиков этой статьи, а также Генри Лейтнеру и Ларри Финкельштейну за приглашение выступить.