Чед Фаулер - Программист-фанатик

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

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

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

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

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

Патрик Коллисон, студент Массачусетского технологического института

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

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

Знаю, что ошибаюсь чаще других программистов. Большинство моих проектов заканчиваются провалом. В папке — /Projects можно найти целый ворох забытых попыток сделать нечто интересное. Шансы на успех у каждой из них были примерно такими же, как шансы лобстера уплыть из кастрюли в океан. Кое-чем они привлекают внимание. Успешные проекты, как и счастливые семьи, похожи друг на друга, а вот неудачные проекты завершаются по-разному.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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