Программист-фанатик

(Если что, у меня есть опыт в обеих сферах. Мои попытки заниматься бизнесом проваливались так же часто, как программные проекты.)

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

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

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

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

Точно не знаю, по каким причинам, но люди, в настоящее время изучающие программирование, обычно не занимаются подобными вещами.

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

Но с точки зрения программирования такая тенденция имеет свой минус. При написании веб-приложений практически никогда не приходится сталкиваться с серьезными техническими проблемами, пока дело не доходит до реально больших масштабов (мы не берем в расчет совместимость с Internet Explorer 6).

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

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

А что с копированием? Любой вам скажет, что для превращения в хорошего программиста нужно читать по-настоящему хороший код. Допускаю, что никто не подразумевает чтения в буквальном смысле (это слишком скучное занятие), но все равно такой подход остается, по сути, неверным: ведь он пассивен. Вместо него я предлагаю активно, широко и беззастенчиво заниматься копированием.

Разумеется, это относится ко многим вещам. Хантер С. Томпсон не просто читал хорошие книги; он перепечатывал Хемингуэя и Фитцджеральда. А старейшие из известных рукописей Баха являются переложениями произведений других органистов. Возможно, более известным является тот факт, что Гейтс в Гарварде доставал чужие программы из мусорной корзины.

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

В случае с кодом есть также менее очевидная — но значительная — выгода. Копирование позволяет продвинуться в проектах, которые с большой вероятностью должны были потерпеть неудачу. Это может быть как непосредственное переписывание реализации хэш-таблицы (что позволило повысить качество первого написанного мною интерпретатора), так и разработка дизайна на основе чьей-то работы (как, скажем, операционная система Linux написана на основе Minix).

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

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

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

Часть IV Маркетинг… не только для бизнесменов

Ты — самый талантливый из известных тебе разработчиков программного обеспечения. Твой творческий потенциал становится источником практически бесконечного потока элегантных проектов. Твоя архитектурная прозорливость не имеет себе равных в рабочем коллективе. Ты пишешь код быстрее и аккуратнее всех когда-либо работавших в этой фирме.

Ну и что?

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

Но это всего лишь отговорка. На самом деле они опасаются.

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

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

Как мне недавно сказал один начальник, если кто-то делает нечто совершенно фантастическое, но об этом никто не знает, можно считать, что он не делает ничего. Это может прозвучать жестоко, но с точки зрения компании такой подход является вполне осмысленным. Начальник не может пристально следить за всеми действиями своих подчиненных в течение каждого дня. И ни компании, ни их сотрудники не хотели бы, чтобы начальство тратило свое время подобным образом. Компании нужно, чтобы руководитель концентрировался на ситуации в целом, а не на мониторинге отдельных заданий. А сотрудники (особенно программисты) ненавидят, когда каждый их шаг контролируется.