Работа 2.0. Программист, который отвлекается

Перевод статьи бывшего лидера проекта OGRE Стива Стритинга под названием "Работа 2.0. Программист, который отвлекается" (Work 2.0 - The interruptible programmer).
Оригинал: http://www.stevestreeting.com/2010/09/04/work-2-0/

Мне 37, я (профессиональный) разработчик уже 16 лет. Вы можете подумать, что за всё это время я выработал эффективный стиль работы, который бы приводил к желаемым результатам (меньше кода, поставка программ в срок и пр.) без выбивающих из колеи ситуаций, но, к сожалению, это не так. Думаю, стиль, который я практиковал первые 15 лет своей карьеры, присущ многим разработчикам-энтузиастам: трата тонн часов. 12-16-часовые дни, марафоны программирования по вечерам и выходным, пицца на клавиатуре, тяжёлые периоды, отладка в 3 часа ночи, когда не можешь пойти спать, т.к. чувствуешь причину ошибки в двух шагах, чёрт подери, отчаянный спринт до дедлайна (deadline), когда удаётся заделать брешь как раз перед тем, как мир проваливается к чертям. Если всё это вам хорошо знакомо, вы мудро киваете головой, возможно, даже немного ухмыляетесь, вспоминая прошлые испытания и славу. Такой сумасшедшей самоотверженностью восхищаются в наших кругах и часто ожидают от любого уважающего себя разработчика.

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

Но я "в зоне"!

Итак, я хочу поговорить о самой большой проблеме, с которой столкнулся: период концентрации. Теперь я не могу безвылазно сидеть за столом более часа. Если я не встану, не пройдусь и не разомнусь немного хотя бы раз в час, то вставать позже будет намного больнее. Наверно, следующие несколько дней тоже. Теперь я не могу работать более 8 часов в день без появления боли. Проблема в том, что, как программист, за последние 15+ лет я выработал стиль работы, при котором я постепенно "погружаюсь в зону" и программирую очень долго за раз без перерыва. Это частая картина среди программистов, мы любим закрыться от внешнего мира, одев наушники, чтобы не отвлекаться и т.д.. В этом также причина того, почему мы имеем склонность плохо реагировать, когда нас прерывают. Программирование требует концентрации, и кажется, что концентрация работает как ламповая система: много времени занимает разогрев системы, а когда она запущена, не хочется её останавливать, т.к. запустить её ещё раз будет сложно.

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

Итак, моей целью было привыкнуть к большому количеству небольших занятий работой в течение дня вместо малого количества больших кусков работы без снижения уровня производительности. Для этого нужно было найти способ возврата "в зону" за короткое время. Во многом так же, как те, кто практикует многофазный сон, добиваются скорого прихода фазы быстрого (REM) сна. У меня это уже почти получилось или, по крайней мере, у меня это получается намного лучше, чем раньше. Итак, что я делал для перехода на новую схему?

1. Примите перерывы.

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

2. Всегда храните контекст вне головы.

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

2.1. Записывайте все свои мысли о текущей задаче.

Я сам себе летописец. Я всегда помечаю, что я делаю, даже если это добавление комментария к обсуждению, часто фиксирую небольшие изменения в хранилище и пишу подробный комментарий к этим изменениям (вы пользуетесь распределённой системой контроля версий, чтобы частые фиксирования небольших изменений были удобны, да?) или просто делаю запись на клочке бумаги. На самом деле, это совсем не обременительно, наоборот, запись мыслей часто помогает лучше понять проблему. Грубо говоря, каждые 30 минут я создаю некоторую новую часть контекста, которую сохраняю где-либо вне головы. В противном случае большая часть проблем будет связана именно с воссозданием контекста в голове, если меня прервут. Запись не занимает много времени и имеет другие преимущества, например, история процесса размышлений.

2.2. Беспощадно игнорируйте косвенные задачи.

Вы, наверно, заметили, что в предыдущем пункте я использовал словосочетание "текущая задача", единственное число. Не "задачи". Не существует такой вещи, как "несколько текущих задач". Есть лишь одна текущая задача, над которой вы работаете, и отвлечения.
Вероятно, мы все используем системы отслеживания ошибок / управления задачами (bug / task trackers), но, когда работаешь над задачей, очень часто можно заметить новую ошибку, улучшение текущего кода или просто придумать новый крутой функционал. Сколькие из нас сразу же принимаются за решение этих косвенных задач, т.к. мы оказались в этой области кода, это "тривиально" или просто круто и хочется это сделать? Раньше я поступал именно так, но теперь иначе: любые косвенные задачи, не относящиеся прямо к тому, чем я сейчас занят, я записываю в систему управления задачами и сразу же забываю, пока не завершу текущую задачу, независимо от их размера, уместности и срочности. Это звучит просто и очевидно, это даже может быть официально закреплено у вас в организации, но я сомневаюсь, что большинство программистов всегда так поступают. Это выгодно, потому что даже малейшее отвлечение добавляет дополнительный уровень контекста, который нужно держать в уме, который опять же сложно собрать обратно, когда вас отвлекут. Чтобы такой подход работал, нужна быстрая и лёгкая система управления задачами, не требующая дотошного описания новой задачи. Нужно успеть за 30 секунд записать новую задачу, выгрузить новую мысль из головы без отвлечения от текущей задачи. Подробности реализации можно будет указать позже.

2.3. Всегда знайте, чем будете заниматься далее.

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

3. Упорядочивайте от противного.

Я упомянул следующие действия в предыдущем пункте, но как определить их очерёдность? Много времени может быть растрачено на выяснение очерёдности, и я искал способ его уменьшить. Раньше я планировал, исходя из того, что хочу выполнить всё перечисленное в списке; я просто пытался понять, какую из задач мне нужно сделать первой. Я обнаружил, что можно сократить время планирования, а также получить более хорошую и менее амбициозную очерёдность путём изменения порядка принятия решений: предположить, что я не сделаю ни одну задачу, и оценить негативные последствия невыполнения каждой из них. Так что вопрос "Какая из возможностей А или Б более важна?" превращается в "Предположим, мы выпускаем продукт без возможностей А и Б. К чему приведёт отсутствие каждой из них?". Может показаться, что разница между ними несущественна, но из своего опыта могу сказать, что оправдание реализации функционала приводит к более реалистичным оценкам, нежели попытки установить относительную очерёдность реализации, предполагая выполнение всего списка.

4. Осознайте выгоды перерывов.

Большая часть вышеизложенного касается минимизации негативных последствий перерывов, но правда такова, что они тоже полезны для работы. Держу пари, все программисты задерживались допоздна на работе, пытаясь исправить ошибку, решение которой находили либо на следующий день за 15 минут, либо в каком-либо малообещающем месте вроде душа. Это очень просто объяснить: длительные периоды концентрации кажутся продуктивными и даже могут быть таковыми для оперативного / последовательного мышления, но для всего остального вроде творческого мышления и решения задач очень часто результат прямо противоположный. Проблема не только в утомлённом мозге, который соображает менее чётко, но и в том, что решение задачи часто находится не там, где мы завязли на несколько часов, а в совершенно иной плоскости. Длительные периоды концентрации имеют тенденцию "запирать" движение мысли по одной колее, что препятствует появлению вдохновения и озарения. Творчество всегда происходит, когда вы не стараетесь. Это часто недооценённый, но жизненно важный инструмент в программировании.
Перерыв в этом движении по одной колее может оказаться очень полезным.

Я мог бы ещё добавить советов, но, думаю, пока достаточно. Надеюсь, перечисленные выше вам помогут.




Примечания переводчика

Эту статью я решил написать после прочтения книги Гранина Д. А. "Эта странная жизнь", рассказывающая о Любищеве А. А., который на протяжении 56 лет вёл учёт своего времени на жизнь. Советы Стива отчасти соответствуют подходам Любищева. Например, Любищев выучил Английский язык во время поездок в транспорте. Т.е. использовал много маленьких кусков времени.

На перевод статьи я затратил 18 календарных дней. Из них на первоначальный перевод ушло 4ч 20м, на ревизию 4ч 10м, на публикацию 1ч 5м, т.е. всего я потратил 9ч 35м своей жизни. Таким образом, я использовал много небольших кусков времени.
Хочу отметить, что использование 10- и 15-минуток довалось намного легче. Сейчас публикацию я сделал почти за один присест и чувствую утомление. Чувствую, что уже надоело заниматься этим делом. Так что короткие периоды работы ещё полезны и для сохранения бодрости духа.

Также очень интересно получилось, что не только я перевёл эту статью на Русский язык. То же сделали в этом же месяце ещё два человека, опубликовавшие свои переводы на Хабре: http://habrahabr.ru/blogs/arbeit/106523/ и http://habrahabr.ru/blogs/arbeit/106510/.

Выражаю благодарность Kai SD за указание трудночитаемых предложений. Которые смог - исправил. Некоторые позаимствовал у raacer, который сделал перевод по второй ссылке.