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

Я контролирую, пока я не

Когда я начинаю находиться в зоне, мой мозг уже видит конечное состояние, в котором он хочет быть. Как и карты Google, у него есть приблизительное представление о том, как добраться до пункта назначения с небольшими обходными путями (по крайней мере, он так думает). Я начинаю программировать, и с каждым небольшим успехом мой мозг начинает ожидать все новых и новых успехов. Внезапно я наткнулся на блокпост. Предположение, которое я сделал интуитивно, больше не имеет никакого смысла. Это может быть API, который не делает то, что я ожидал, или какое-то условие, которое требует большего участия со стороны бизнеса. Идеальный вариант на данном этапе — сделать шаг назад и сделать небольшой технический всплеск или поговорить с людьми, занимающимися продуктом. Мой мозг, однако, теперь пристрастился к «зоне». Он думает, что сможет справиться с проблемами. Просто ради того, чтобы быть в зоне, я буду находить неоптимальные краткосрочные решения своих проблем. Я могу найти недокументированный хак, чтобы обойти проблему API. Я буду угадывать и, возможно, делать неверные предположения о бизнес-логике. Все это рухнет довольно быстро, и в конечном итоге я буду делать гораздо больше работы, чем должен был бы в идеале.

Похмелье

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

«Зона» в умеренных количествах может быть продуктивной

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

Парное программирование помогает

Когда я работал в среде парного программирования, это действительно помогло. Мой напарник не дает мне зайти слишком далеко в кроличьи норы. Поскольку я постоянно разговариваю с партнером, мой мозг думает медленнее, переваривая мысли партнера. Один из нас устанет и подтолкнет другого к перерыву. Если ваша динамика парного программирования включает в себя только одного человека, который непропорционально много думает и/или печатает, то это может не относиться к вам (вам нужно улучшить свою парную программу).

Быстро не всегда оптимально

Как метафорический заяц в «Заяце и черепахе», ваш мозг может заставить вас думать быстро == продуктивность. Написание программного обеспечения — это не 100-метровый спринт, а марафонская гонка. Как и для марафонцев, темп для финиша важнее, чем чистая скорость. Кроме того, программирование != продуктивность, но для этого нужна отдельная запись в блоге.