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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Бангалоре, в нашем центре программного обеспечения, была группа, которая более года работала в ночь. Из семи входящих в нее человек двум всегда доставалась ночная смена. Еженедельно они менялись, в итоге каждую третью или четвертую неделю каждому члену группы приходилось работать с 7 вечера до 3 утра. Группа постепенно выдыхалась, страдая от постоянной смены суточных ритмов. Но эта группа играла важную вспомогательную роль, и заказчики из США считали, что не справятся без специалистов из Бангалора, помогающих в режиме реального времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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