Я получил степень бакалавра вычислительной науки (computer science, CS) в 1991 году. Шестнадцать лет назад. Сегодня я попытаюсь связать старшие курсы моего обучения на факультете вычислительной науки со своей профессиональной деятельностью, в которую входят разработка программного обеспечения, публикации о программном обеспечении и основание софтверной компании. Конечно, все это немного нелепо: изданное в MIT «Introduction to Computer Science» («Введение в вычислительную науку») Хэла Абельсона (Hal Abelson) начинается с известного авторского разъяснения, что «вычислительная наука» — это не наука о компьютерах, и что это вообще не наука, поэтому с моей стороны было бы дерзостью утверждать, что CS — лучшая подготовка к карьере разработчика программного обеспечения, чем, скажем, изучение средств массовой информации или культурной антропологии.

Тем не менее я продолжу свою мысль. Одним из наиболее полезных курсов оказался тот, который я бросил после первой лекции. Другим был курс Роджера Шанка (Roger Schank), настолько презираемый на факультете, что его не учитывали при получении степени по вычислительной науке. Но об этом чуть позже.

Третьим был курс под названием CS 322, который теперь называется CS 323. В мои времена CS 322 требовал столько сил, что на него давали

1,5 кредит-часа. А в Йеле лишние 0,5 кредит-часа учитываются только с другими 0,5 кредит-часа на том же факультете. Действительно, было еще два курса по 1,5 кредит-часа, но можно было записаться только на оба сразу. Благодаря такому мошенничеству 0,5 кредит-часа просто не учитывались, но этим оправдывались еженедельные наборы задач, на решение которых уходило 40 часов. После многолетних жалоб студентов курс был переоценен в 1 кредит-час, получил номер CS 323 и по-прежнему еженедельно требовал 40 часов на решение задач. В остальном он остался примерно тем же. Я его любил, потому что я люблю программировать. Лучше всего в CS 323 то, что благодаря этому курсу до многих доходит, что они никогда не станут программистами. Это его достоинство. Те, кому не выпало узнать на уроках Стэна Эйзенштата (Stan Eisenstat), что программистами им не стать, влачат жалкую карьеру, вырезая и вставляя куски Java-кода. Кстати, для тех, кто записался на CS 323 и получил на экзамене оценку «A»: у нас в Fog Creek есть замечательная летняя практика. Подойдите ко мне после лекции.

Насколько я могу судить, базовый список курсов остался прежним. 201, 223, 240, 323, 365, 421, 422, 424, 429 — это почти те же курсы, которые читались шестнадцать лет назад. С тех пор, как я покинул Йель, количество выбравших специальность CS на самом деле выросло, хотя из-за временного всплеска времен дотком-бума кажется, что оно снизилось. И стало гораздо больше интересных факультативных курсов, чем в мои времена. Стало быть, прогресс налицо.

Кстати, я ведь тогда собирался получить степень PhD. Оба моих родителя — преподаватели. Среди их друзей множество ученых, и в детстве мне казалось, что все взрослые непременно получают PhD. Во всяком случае, я всерьез подумывал о поступлении в аспирантуру по вычислительной науке. Пока не попытался прослушать курс динамической логики — здесь, на этом самом факультете. Его читала Ленора Зак (Lenore Zuck), которая сейчас работает в UIC.

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

На первой лекции Ленора Зак предложила несколько аксиом и правил преобразования и начала доказывать довольно простую вещь. Она взяла компьютерную программу f := not f, где f — булево значение, бит которого просто менялся на противоположный; требовалось доказать, что если выполнить эту программу четное количество раз, то в результате f будет иметь то же значение, что и вначале.

Доказательство длилось довольно долго. Если мне не изменяет память, все происходило как раз в этом зале (ковер здесь все тот же), и вот эти доски были исписаны доказательствами. Профессор Зак применяла доказательство методом индукции, методом от противного, методом перебора всех вариантов — курс читался в конце дня, и мы уже минут на сорок задержались — и методом привлечения старшекурсника, когда она говорит «не могу вспомнить, как доказать вот этот переход», а старшекурсник из передних рядов отвечает: «Да-да, все правильно, профессор».

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

В качестве домашнего задания она предложила доказать обратное: если выполнить программу f := not f n раз, и бит окажется в начальном состоянии, то n должно быть четным.

Я решал эту задачу несколько часов. Передо мной было ее доказательство в прямом направлении, где при ближайшем рассмотрении обнаружилось множество отсутствующих переходов — «очевидных», но не для меня. Я прочел все, что можно было найти о динамической логике в Becton Center, и сражался с задачей до глубокой ночи. Я нисколько не продвинулся и все больше разочаровывался в теоретической вычислительной науке. Я пришел к выводу, что если доказательство занимает многие страницы, то вероятность ошибок в нем значительно выше, чем вероятность ошибки собственной интуиции относительно тривиального утверждения, которое нужно доказать. Я решил, что все эти штучки с динамической логикой -не самый плодотворный способ доказывать факты, касающиеся настоящих, интересных компьютерных программ, потому что гораздо легче ошибиться в доказательстве, чем в интуитивном представлении о том, как работает программа f := not f. Поэтому я бросил этот курс — слава богу, что было время присмотреться, — более того, я тут же решил, что аспирантура по вычислительной науке не для меня, так что этот курс оказался самым полезным из всех, на какие я когда-либо записывался.

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

Часто говорят о своего рода кризисе качества разработки программного обеспечения. Я не вполне согласен с такими заявлениями: компьютерные программы, используемые большинством людей, обладают на редкость высоким качеством в сравнении со всем прочим, что их окружает, но речь сейчас не о том. Тезис о «кризисе качества» порождает массу предложений и исследований по улучшению качества программного обеспечения. С этой точки зрения людей можно разделить на две категории — «гики» и «пиджаки» (geeks and suits).

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

Пиджаки не вполне понимают, в чем проблема. Их совершенно не волнует, что в программе есть ошибки, коль скоро люди ее покупают.

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

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

А гиков интересуют узкотехнические аспекты качества. Они смотрят в код, а не ждут, что скажут пользователи. Будучи программистами, они стремятся автоматизировать все вокруг, включая, конечно, процедуру контроля качества. Отсюда поблочное тестирование (unit testing), что не так уж плохо, и отсюда все попытки механически «доказать», что программа «корректна». Беда в том, что из определения качества выбрасывается все не поддающееся автоматизации. Мы знаем, что пользователи предпочитают программы со стильным интерфейсом, но поскольку автоматически измерить стильность нельзя, это свойство остается за рамками автоматизированной процедуры контроля качества.

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

Это очень существенная проблема. Чтобы механически проверить соответствие программы некоторой спецификации, эта спецификация должна быть предельно подробной. Фактически, такая спецификация должна полностью определять всю программу, иначе ничего нельзя будет доказать автоматически и механически. Теперь смотрите: если спецификация полностью определяет то, как должна вести себя программа, то в ней достаточно информации для того, чтобы сгенерировать саму программу! И тогда некоторые гики заходят настолько далеко, что подумывают об автоматической компиляции спецификаций в программы, и начинают думать, что изобрели способ программировать, не прибегая к программированию.

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

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

Может, это и грубый пример, тем не менее поиск Святого Грааля качества программ многих заводит в разного рода тупики. В подобном положении в Microsoft оказалась команда разработчиков Windows Vista. По-видимому, — судя по слухам и намекам в блогах — у Microsoft есть долгосрочная политика искоренения тестеров, не умеющих писать код, и замены их так называемыми SDET (Software Development Engineers in Test) — программистами, пишущими скрипты для автоматизированного тестирования.

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

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

Я отнюдь не испытываю ненависти к Microsoft. Это мое первое рабочее место после университета. В те времена это было недостаточно респектабельно, как устроиться в цирк. На тебя смотрели с удивлением. Microsoft? В самом деле? У нас в кампусе, в частности, считалось, что это такая скучная корпорация, где нужно ходить застегнутым на все пуговицы и писать скучное программное обеспечение, позволяющее бухгалтерам создавать таблицы — или чем там они занимаются? Совершенно не впечатляет. И все это для жалкой однозадачной операционной системы MS-DOS, в которой полно непонятных глупых ограничений вроде восьмисимвольных имен файлов, нет электронной почты, нет telnet, нет телеконференций Usenet. Давно уже нет MS-DOS, но культурная пропасть между юниксоидами и пользователями Windows все глубже. Разногласия очень запутанные и очень фундаментальные. В Йеле Microsoft считалась местом, где пишут операционные системы для производства игрушек с применением вычислительной науки тридцатилетней давности. А в Microsoft поднимали на смех новичков со странными гипотезами вроде той, что следующим основным языком программирования станет Haskell, обзывая их «компьютерными шаманами».

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

Утешает то, что интерфейс командной строки можно использовать в скриптах.

Культура Windows предполагает, что сначала пишется приложение с GUI ⁸, а потом все важнейшие функции безнадежно перемешиваются с кодом интерфейса пользователя и получаются гигантские приложения вроде Photoshop, позволяющего великолепно отредактировать фотографию, но если вы программист, и вам нужно с помощью Photoshop изменить размер 1000 фотографий, так чтобы их высота не превышала 200 пикселов, вы не сможете написать нужный код, потому что все очень тесно связано с интерфейсом пользователя.

Во всяком случае, эти две культуры примерно соответствуют противостоянию между интеллектуалами и обывателями, что находит точное отражение в учебных планах различных факультетов вычислительной науки. В институтах Ivy League вы найдете только UNIX, функциональное программирование и теорию конечных автоматов. С понижением уровня запросов все чаще встречается Java. Если опуститься еще ниже, точно появятся курсы с темами вроде «Microsoft Visual Studio 2005 101», три кредит-часа. Ну, а добравшись до двухгодичных заведений, вы увидите те самые курсы «сертификации» типа «SQL Server за 21 день», какие рекламируются по выходным дням на кабельном ТВ. Ваша карьера начнется (другим голосом) с Java Enterprise Beans!

Проведя несколько лет в Редмонде (штат Вашингтон) в бесплодных попытках приспособиться к окружающей среде, я сбежал в Нью-Йорк. Там я несколько месяцев продолжал работать на Microsoft, в качестве совершенно бездарного консультанта Microsoft Consulting, после чего несколько лет в 1990-х, в эпоху зарождения Интернета, проработал в Viacom. Это крупный конгломерат, владевший MTV, VH1, Nickelodeon, Blockbuster, Paramount Studios, Comedy Central, CBS и целой кучей других компаний индустрии развлечений. В Нью-Йорке я впервые разобрался в том, как зарабатывает себе на жизнь большинство программистов. Это жуткая вещь под названием «внутрифирменное ПО» (in-house software). Ужас, которого нужно постараться избежать. Вы работаете программистом в большой компании, которая производит, скажем, алюминиевые банки, но никакой готовый продукт не обрабатывает алюминиевые банки в точности так, как надо, поэтому у компании есть собственные программисты или она нанимает по завышенным ценам программистов у таких компаний, как Accenture и IBM, чтобы те написали им нужное программное обеспечение. Это ужасно по двум причинам: во-первых, это не приносит вам удовлетворения как программисту по ряду оснований, которые я приведу ниже, а, во-вторых, это ужасно потому, что 80% связанных с программированием работ именно таковы, и если в конце обучения не проявить крайнюю степень осторожности, вы как раз окажетесь разработчиком внутрифирменного ПО, и, смею вас заверить, такая работа лишит вас всякого интереса к жизни.

Так что же ужасного в том, чтобы разрабатывать собственное программное обеспечение для фирмы?

Первое: вам никогда не дадут делать что-либо правильно. Вы всегда будете вынуждены действовать практически выгодным образом. Нанять такого программиста недешево: обычно компании типа Accenture или IBM берут 300 долларов в час за услуги недавнего выпускника Йеля с дипломом политолога, который прослушал шестинедельный курс .NET-программирования, зарабатывает 47 000 долларов в год и надеется на хорошую практику, чтобы попасть в школу бизнеса, — иными словами, за большие деньги компания получает программиста, которому не разрешат работать с Ruby on Rails, как бы крут ни был Ruby и каким бы классным ни стал Ajax. Вы откроете Visual Studio, запустите мастер, перетащите на страницу элемент управления Grid, подключите его к базе данных — и готово. Достаточно. Переходим к следующей задаче. Вот и вторая причина, по которой эта работа так противна: как только программа начинает достаточно прилично работать, ее разработка заканчивается. Основные функции действуют, главная задача решена, и дальше никакого возврата на инвестиции, никаких деловых причин, чтобы пытаться ее улучшить. Поэтому все доморощенные программы выглядят тошнотворно: никто и копейки не потратит на то, чтобы они выглядели лучше. Можете забыть про гордость профессией или ремеслом, воспитанную в вас курсом CS 323. Вы будете со стыдом плодить хлам, а потом вас бросят на починку прошлогоднего хлама, который стал разваливаться — главным образом, потому, что сделан неправильно, — и через двадцать семь лет такой жизни вы получите золотые часы. Впрочем, золотые часы больше не раздают. Двадцать семь лет — и вы получите синдром запястного канала. К примеру, в компании, создающей товарный продукт или даже сетевой продукт типа Google или Facebook, чем лучше у разработчика получится этот продукт, тем лучше он будет продаваться. Главная же особенность внутрифирменного продукта в том, что как только он стал «достаточно хорош», работа над ним прекращается. Товарный продукт можно бесконечно уточнять, шлифовать, перерабатывать и совершенствовать, например, работая для Facebook, вы можете месяц оптимизировать код, выбирающий имя через Ajax, пока он не станет действительно красивым и быстрым, и все эти труды оправданны, потому что делают продукт лучше, чем у конкурента. Итак, вторая причина, по которой лучше работать над товарным продуктом, чем над внутрифирменным, -это возможность делать красивые вещи.

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

И тем не менее. После Microsoft я поступил на работу в Viacom, потому что хотел больше узнать об Интернете, а Microsoft в те времена его упорно игнорировала. Но в Viacom я был просто внутрифирменным программистом, на несколько уровней ниже любого, кто занимался тем, на чем Viacom зарабатывала деньги.

И, должен сказать, несмотря на всю важность правильного входа в Интернет для Viacom, когда дошло до расселения людей по помещениям, собственных программистов затолкали по трое в кабинку в дальнем конце, где окон и в помине не было, зато «продюсеры» (не знаю, чем занимались эти типы, напоминающие Черепаху из сериала «Антураж») получили собственные кабинеты с огромными окнами на Гудзон. Однажды на новогодней вечеринке Viacom я был представлен начальнику, отвечавшему за интерактивную стратегию или нечто в этом роде (очень высокий пост). Он сказал что-то туманное и глупое о важности интерактивности, за которой будущее, из чего я сделал вывод, что у него нет ни малейшего представления о происходящем, об Интернете или о том, чем я занимаюсь как программист, и его все это немного пугало, но не все ли равно, потому что он зарабатывает два миллиона в год, а я всего лишь печатаю на машинке, или какой-то «оператор HTML», или бог весть чем занимаюсь, с чем вполне справилась бы его дочь-школьница.

Итак, я перебрался в соседнее место под названием Juno Online Services. Это был один из первых интернет-провайдеров, предоставлявший бесплатный доступ по телефонным линиям для работы с электронной почтой — и ничего больше. Это отличалось от Hotmail и Gmail, которых тогда еще не было, потому что доступ к Интернету был не нужен, и система была действительно бесплатной.

Источником средств для Juno якобы была реклама. Оказалось, однако, что реклама, нацеленная на людей, не желавших платить AOL 20 долларов в месяц, — не самый доходный бизнес, так что в действительности Juno поддерживали богатые инвесторы. Но, во всяком случае, компания Juno производила продукт, программисты там были в почете, и меня удовлетворяла поставленная задача обеспечить всех электронной почтой. И я действительно с удовольствием проработал там три года программистом C++. Однако со временем я стал подумывать, что философия руководства Juno устарела. Считалось, что менеджеры нужны для того, чтобы объяснять людям, что они должны делать. Этот подход диаметрально противоположен принятому в компаниях высоких технологий на западном побережье. На Западе я привык считать, что руководить — значит выполнять неприятные и скучные обязанности, которыми кто-то должен заниматься, чтобы толковые люди могли делать свое дело. Сравните это с научным факультетом в университете, руководить которым — тяжкий труд, за который никто не хочет браться, предпочитая научные исследования. Таков стиль управления в Силиконовой долине. Менеджеры нужны для того, чтобы мебель не мешалась на дороге и подлинные таланты могли ваять свои шедевры.

Juno была основана очень молодыми и очень неопытными людьми: президенту компании было 24 года, и это была его первая работа, а не просто первая административная работа, — и из каких-то книг, фильмов или ТВ-шоу он почерпнул представление о том, что менеджеры нужны для того, чтобы ПРИНИМАТЬ РЕШЕНИЯ.

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

Итак, я ушел оттуда, не имея реального плана.

Я отчаялся найти работу в такой компании, где к программистам относились бы как к талантам, а не как к машинисткам, и решил, что нужно создать собственную фирму. В те времена мне попадалось множество очень глупых людей с очень глупыми бизнес-планами, которые создавали интернет-компании, и я решил, что если я хотя бы на 10% умнее их, что не исключено, то тоже смогу создать компанию, и уж в этой компании будут совсем другие порядки. Мы станем относиться к программистам с уважением, мы будем выпускать продукты высокого качества, мы не станем связываться с венчурным капиталом или 24-летними президентами, мы будем проявлять заботу о своих клиентах и решать их проблемы, когда они обратятся к нам за помощью, а не сваливать всю вину на Microsoft, и пусть наши клиенты сами решают, платить нам или не платить. В Fog Creek мы будем возвращать деньги всем желающим, не задавая никаких вопросов и при любых обстоятельствах. Мы будем вести праведную жизнь.

Это было летом 2000 года, и я на какое-то время отошел от работы, вынашивая планы создания Fog Creek Software и много времени проводя на пляже. Тогда-то я и стал записывать некоторые размышления по поводу своей карьеры и публиковать их на сайте «Joel on Software». Еще не были изобретены блоги, и некий программист по имени Дэйв Уайнер (Dave Winer) организовал систему под названием EditThisPage.com, позволявшую всем публиковаться в Сети в формате, напоминающем блог. «Joel on Software» быстро развивался и дал мне ту трибуну, с которой я мог излагать свои мысли о разработке программного обеспечения, привлекая к ним внимание. Сайт состоял из малооригинальных идей, сдобренных шутками. Он имел успех, потому что я применял шрифт крупнее обычного, что облегчало чтение. Оценить, сколько людей читает сайт, достаточно трудно, особенно если не ставить себе целью их учет, но типичные статьи на этом сайте имели от 10 000 до миллиона читателей в зависимости от популярности той или иной темы.

Тому, чем я занимаюсь на «Joel on Software» — писанию статей на технические темы, — я тоже научился здесь, на факультете CS. Вот как это произошло. В 1989 году в Йеле достаточно успешно занимались искусственным интеллектом (ИИ), и один из светил в этой области, профессор Роджер Шанк (Roger Schank), приехал сюда и прочел небольшую лекцию о некоторых своих изысканиях в области ИИ — скрипты, схемы, слоты и все такое прочее. Сейчас я подозреваю, что эту самую лекцию он читал уже двадцатый год, и в течение двадцати лет своей карьеры он писал программки, основанные на его теориях, — вероятно, для их проверки, — и хотя они не работали, его теории почему-то никогда не отвергались. Он производил впечатление блестящего ученого, и я хотел записаться к нему на курс, но узнал, что он не любит студентов младших курсов, и единственная возможность — записаться на его курс под названием «Algorithmic Thinking» («Алгоритмическое мышление»), CS 115, — по существу, облегченный конспект курса группы IV, рассчитанный на поэтов. Формально он числился за факультетом CS, но отношение к нему в преподавательской среде было таково, что в зачет по специальности CS он не шел. Хотя это был самый посещаемый курс на факультете CS, меня коробило всякий раз, когда мои друзья, учившиеся на историков, называли его «вычислительной наукой». Типичным заданием было написать сочинение на тему «Могут ли думать машины». Теперь вы поняли, почему этот курс не засчитывался для получения степени по вычислительной науке. Не удивлюсь, если, узнав про этот курс, вы потребуете, чтобы у меня отобрали диплом.

Лучшим в курсе «Алгоритмического мышления» было то, что приходилось очень много писать. Было тринадцать контрольных работ — раз в неделю. Оценки не ставились. Нет, конечно, ставились. Впрочем, тут особая история. Одна из причин, по которым Шанк так не любил студентов младших курсов, была их озабоченность оценками. Ему хотелось поговорить о том, могут ли компьютеры думать, а они требовали объяснить, почему их работа получила оценку «В», а не «А». В начале семестра он произнес длинную речь о вредности оценок и объявил, что единственной оценкой на вашей работе может быть маленькая галочка, означающая, что какой-то старшекурсник ее прочел. Со временем он решил отличать более удачные работы, на которых ставилась галочка с плюсом, а поскольку встречались и очень слабые работы, он ставил на них галочку с минусом. Припоминаю, что однажды я получил галочку с двумя плюсами. Но отметку — ни разу.

Несмотря на то что курс CS 115 не шел в диплом по специальности, самым полезным, что я вынес с факультета CS, оказался полученный опыт написания статей на темы, связанные с техникой. Умение ясно писать на технические темы — это то, что отличает руководителя от невнятно бормочущего программиста. Первая моя должность в Microsoft — руководитель программы в команде Excel, и, занимая ее, я написал техническую спецификацию для огромной программной системы под названием Visual Basic for Applications. В этом документе было около 500 страниц, и каждый день буквально сотни людей, придя на работу, читали в нем, что они должны сегодня делать. Среди этих людей были программисты, тестеры, маркетологи, составители документации и специалисты по локализации со всех концов света. Я заметил, что выдающимися менеджерами программ в Microsoft становились те, кто умел действительно хорошо писать. Microsoft повернула свой стратегический курс на 180 градусов в результате одного лишь неотразимого электронного письма, которое написал Стив Синоф-ски (Steve Sinofsky), озаглавив его «Cornell is Wired» («Весь Корнелл в сети!»,www.cornell.edu/about/wired/). Исход спора решает тот, кто умеет писать. Язык программирования C обрел свое влияние благодаря замечательной книге Брайана Кернигана (Brian Kernighan) и Денниса Ричи (Dennis Ritchie) «The C Programming Language» (Prentice Hall, 1988).

Итак, вот кульминационные моменты моего обучения вычислительным наукам: CS 115, где я научился писать, единственная лекция по динамической логике, благодаря которой я не пошел в аспирантуру, и CS 322, где я изучил обряды и ритуалы учения UNIX и с удовольствием написал массу кода. Главное, чему не учат, готовя к степени по компьютерной науке, — это тому, как разрабатывать программы, хотя у вас и развиваются определенные части мозга, которые могут оказаться полезными, если когда-нибудь вы решите, что разработка программного обеспечения — это то, чем вы хотите заниматься. Другой путь научиться разрабатывать программы — послать свое резюме на [email protected] и подать заявление на летнюю практику. Кое-чему мы вас там научим.

Большое спасибо за внимание.

8 GUI (Graphical User Interface) — графический интерфейс пользователя. — Прим. перев.