(С) хабрахабр
Автор: Steve Streeting
Оригинал статьи:
не православный сайтРабота 2.0 — Прерываемый программист
Мне 37 лет, и я был (профессиональным) разработчиком в течение 16 лет. Ты мог бы подумать, что за это время я выработал эффективный стиль работы, приносящий желаемый результат и не вызывающий неприятных побочных эффектов. Но, к сожалению, это не так. Мне кажется, тот стиль, в котором я работал в течение первых 15 лет моей карьеры, был практически такой же, как и у любого другого разработчика, увлеченного своей профессией: ты тратишь на работу огромное количество времени. 12-16 часов в день, марафоны программирования по вечерам и по выходным, пицца на клавиатуре, тяжелые периоды, отладка в 3 часа ночи, когда ты не можешь лечь спать, потому что чувствуешь, что вот-вот отловишь этот долбаный баг, отчаянные попытки доделать работу за минуту до дедлайна, когда ты умудряешься завершить последний кусок кода, как в лихо закрученном боевике, в последнюю секунду до того, как мир был готов отправиться прямиком в ад. Если ты из тех, о ком я говорю, ты понимающе кивал и, вероятно, слегка улыбался, вспоминая о былых испытаниях и победах. Такую безумную преданность работе уважают в наших кругах и в значительной степени ожидают от любого разработчика с высокой кармой.
Но, оказывается, все это не очень хорошо для нашего здоровья. Кто знал? Те из вас, кто знаком со мной или следит за моим блогом, в курсе, что я был вынужден уйти от такого стиля работы из-за старых проблем, поначалу игнорируемых мною, затем вынудивших искать компромиссы, и, в конце концов, полностью одолевших меня. Будучи фрилансером, я столкнулся с большой проблемой. Попытки выкарабкаться из ямы, которую я сам для себя вырыл, отняли много времени и принесли немало разочарований. Я прочитал приличное количество книг о продуктивности в попытках найти ответ как на вопрос «как продолжать работать», и в результате пришел к выводу, что лучшие ответы — это те, которые ты сам формулируешь для себя. Я хотел бы поделиться одним из открытий, которое я сделал на своем пути.
Но я «в ударе»!!!
Итак, я хотел бы поговорить о самой большой проблеме, с которой я столкнулся: периоды концентрации. Я не могу непрерывно просидеть за столом больше часа. Если я не буду минимум раз в час вставать и ходить, делать небольшие растяжки и тому подобное, то я поплачусь за это, как только сделаю шаг, и вероятно буду еще расплачиваться в течение нескольких дней.
читать дальшеЯ также больше не могу работать не чувствуя боли больше стандартных 8 часов в день. Проблема была в том, что стиль, в котором я работал больше 15 лет, приучил меня к постепенному вхождению в состояние «в ударе» и непрерывному кодированию в течение длительного времени. Это общая тема для программистов, которые любят уходить в работу с головой на многие часы, одевают наушники, чтобы ничего не отвлекало, полностью отключаются от внешнего мира и тому подобное — и это также является причиной того, что мы обычно плохо реагируем, когда нас прерывают. Программирование требует концентрации, и похоже, что концентрация давит на клапан системы: требуется какое-то время, чтобы разогреться, и когда это происходит, вы не хотите отключать его, так как повторный запуск является трудной задачей.
Мне казалось, что не существует способа обойти эту проблему, и я начал смиряться с тем, что буду менее продуктивен. Однако, в течение последних 6 месяцев среди прочего я обнаружил, что медленное разогревание и длительная беспрерывная работа являются в большей степени привычкой, и можно приучить себя делать работу подругому. Это похоже на то, как люди учатся многофазному сну. Не то, чтобы ты не мог этого сделать, просто когда ты привык делать вещи определенным образом, изменить это сначала очень и очень трудно. Но это не невозможно при наличии достаточной мотивации и времени для привыкания.
Так что, моей целью было приучить себя к множеству коротких сеансов работы в течение дня вместо нескольких очень больших, сохранив при этом производительность. Ключом к этому было найти способ быстрее возвращаться в состояние сосредоточенности, подобно тому, как люди, обучающиеся многофазному сну, тренируют себя быстрее достигать стадию быстрого сна. В большей степени я уже научился этому, или, по крайней мере, у меня это получается гораздо лучше чем раньше. Итак, какие методы я использовал, чтобы достичь этого?
1. Принимай прерывания
Это не столько техника, сколько психологический настрой, связанный со всеми практическими подходами, о которых я расскажу ниже. Вместо того, чтобы быть типичным программистом, избегающим прерываний любой ценой, ты должен научиться принимать их и эффективнее управлять ими. Это трудно, ты должен постараться оставить в стороне года сопротивления перерывам, и пока ты подстраиваешься, ты будешь чувствовать, что не успеваешь сделать достаточно. Многие люди, вероятно, откажутся делать это, если у них нет чего-то мотивирующего пройти через это. Для меня ежедневные боли были отличной мотивацией. Главное, что я хочу этим сказать, это то, что этот переход — просто этап, и что возможно быть прерываемым программистом, который все так же справляется с делами. Но ты должен научиться не бороться с прерываниями. Вот почему это первый пункт.
2. Все время держи контекст вне своей головы
Основная часть проблемы с перерывами состоит в потере контекста. Когда ты сфокусирован на чем-то, ты жонглируешь целым букетом контекста в своей голове, поправляя его на лету, постоянно поддерживая и корректируя связи между различными вопросами. Прерывание заставит тебя уронить все это, и потребуется время, чтобы снова собрать все воедино. Моим ответом на это было вынести из головы как можно больше, на всех возможных уровнях:
2.1. Веди рабочие заметки к текущей задаче
Я — мой собственный летописец. Я все время пишу заметки о том, что я делаю: добавляю комментарии к задаче, часто делаю коммиты и пишу детальные описания (ты ведь используешь распределенную VCS, чтобы было удобно делать частые коммиты, не так ли? 
), делаю наброски на (упорядоченных) клочках бумаги. В действительности это не так уж обременительно, и на деле извлечение твоих мыслей из головы часто может помочь тебе прояснить их. Основное правило состоит в том, что примерно каждые 30 минут я должен получать какую-то новую часть контекста, которая сохранена где-то еще кроме моей головы. Если этого не произошло, то в случае прерывания я буду иметь больше проблем, заново собирая контекст в уме. Это не занимает много времени, а также имеет и другие преимущества, такие как запись твоих мыслей и процесса принятия решений.
2.2. Безжалостно игнорируй косвенные вопросы
Ты мог заметить, что в предыдущем пункте я написал «текущая задача» в единственном числе, а не «задачи». Не бывает такого, чтобы было несколько текущих задач. Есть только одна задача, над которой ты работаешь в текущее время, и отвлекающие факторы.
Мы, наверное, все используем багтрекеры и менеджеры задач. Но когда ты работаешь над задачей, часто обнаруживается новый баг, или возможность для оптимизации, или приходит идея о новой интересной функции. Как многие из нас сразу же хватаются за это, потому что оно в той области, над который мы сейчас работаем? Я был в их числе, но больше я так не делаю. Любая косвенно связанная задача, не относящаяся непосредственно к тому, что я делаю прямо сейчас, отправляется в список задач и моментально забывается до тех пор, пока я не закончу текущую задачу, независимо от ее размера, релевантности или приоритета. Это кажется простым и очевидным, и это даже может быть официальным правилом в твоей организации, но пусть большинство программистов скажут, что они действительно так делают. Преимущество в том, что даже малейшее отвлечение добавит дополнительный уровень в контекст, который тебе нужно поддерживать, и в случае прерывания будет еще труднее собраться.
Чтобы это работало, нужна быстрая и легкая система для управления задачами, не требующая от тебя дотошности в описании новой задачи. Ты должен открыть ее и закрыть в течение 30 секунд, чтобы выгрузить мысль, не отвлекаясь от текущей задачи. Ты можешь вернуться к ней позже.
2.3. Всегда знай, что ты будешь делать следующим
Это одно из правил GTD («Следующие действия»), но оно очень полезное. Когда ты возвращаешься к работе после перерыва или прерывания, ты не должен тратить время на выяснение того, что тебе нужно сделать следующим. Твоя система задач поможет тебе в этом, в том числе и комментарии, которые, будем надеяться, ты не забыл добавлять к текущей задаче. Если ты был вынужден переключиться между проектами, и при этом повсюду поддерживал внешний контекст, ты не должен иметь проблем с определением следующего действия. Важно иметь только одно следующее действие для каждого проекта. Если их несколько, ты должен будешь потратить время на выбор между ними, а это — зря потраченное время (смотри следующий раздел о приоритетах). В любой момент времени ты должен иметь не только одну текущую задачу, но и одно однозначное следующее действие по этой задаче. Половина проблемы эффективной работы состоит в знании, что ты будешь делать следующим.
3. Расставляй приоритеты наоборот
Я упомянул следующие действия в предыдущем разделе, но как решить что будет следующим? Можно потратить много времени мучаясь с приоритетами, и я искал способ избежать этого. Логичным казалось исходить из предположения, что я хотел бы сделать все из списка, и нужно только определить, какие пункты выполнить первыми. Я обнаружил, что можно сэкономить время на планировании, и в то же время получить более точные приоритеты, инвертировав процесс принятия решения: основываясь на предположении, что я могу не выполнить любую из задач, и оценивая негативные последствия от невыполнения каждой из них. Таким образом, вопрос «Какая из функций А и Б важнее» превращается в «Предположим, мы не реализуем функцию А и Б. К каким последствиям приведет отсутствие каждой из функций?». Это может показаться несущественным различием. Но мой опыт показывает, что необходимость полностью объяснять важность выполнения задачи, вместо определения относительного порядка в предположении, что в конечном итоге все равно все будет сделано, как правило, дает более честные оценки.
4. Признай преимущества перерывов
В основном мы рассмотрели способы избежать негативных последствий перерывов, но дело в том, что они также предоставляют много преимуществ в работе. Могу поспорить, что все программисты оставались допоздна на работе, или засиживались до поздней ночи, пытаясь исправить проблему, а на следующий день решали ее за 15 минут, или находили ответ в таких неожиданных местах, как душ. Причина этого очень простая: длительные периоды концентрации кажутся продуктивными, и могут быть такими для оперативного/последовательного мышления, но для всего остального, как креативное мышление или решение проблемы, это очень часто совершенно наоборот. Мало того, что усталый ум работает менее ясно, но часто решение проблемы состоит не в более усердном мышлении в направлении, в котором вы бесполезно трудились последние несколько часов, а во взгляде на проблему с иной стороны. Длительные периоды концентрации, как правило, блокируют мышление в одном направлении, делая очень редкими вдохновения и гениальные озарения. Творчество всегда происходит в тот момент, когда ты не пытаешься, и это часто недооцененный, но очень важный инструмент в программировании. Прерывание прямолинейно направленных мыслей может быть в действительности очень полезным.
Есть еще немало вещей, о которых я мог бы рассказать, но я думаю, что для начала этого будет достаточно. Я надеюсь, для кого-то это окажется интересным и полезным.комменты на
хабре