Источник: http://russian.joelonsoftware.com/Articles/FireAndMotion.html

Автор: Джоэл Сполски
Переводчик: Алексей Симонов
Редактор: Марат Зборовский
Оригинальная статья: Fire and Motion
6 января 2002

Иногда я просто не в состоянии что-либо сделать.

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

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

Каждый из нас подвержен переменам настроения. У одних они лёгкие, у других более резко выраженные или даже выводящие из строя. И похоже, что приступы непроизводительности каким-то образом связаны с унылым настроением.

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

Но что просто выводит меня из себя, так это то, что ещё на первой моей работе я понял - производительное кодирование отнимает у меня, как разработчика, в среднем по два-три часа в день. Когда я проходил летнюю стажировку в Microsoft, мой приятель сказал, что на самом деле он активно работает всего лишь с 12 до 5 каждый день. Пять часов минус обед - и его команда души в нём не чаяла, потому что он умудрялся сделать гораздо больше чем средний член команды. Я тоже пришёл к этому выводу. Я чувствую себя немножечко виноватым, когда вижу, какими чрезвычайно занятыми выглядят все остальные, а мне удаётся достичь лишь двух или трёх часов качественной работы в день. При том я всегда был одним из самых производительных членов команды. Видимо, именно в этом кроется прична того, почему книга "Человеческий фактор в программировании" (Peopleware) и экстремальное программирование настаивают на отказе от сверхурочной работы и на работе ровно 40 часов в неделю. Они поступают так потому, что уверены, что на самом деле это никак не скажется на результате.

Но меня выводят из себя не те дни, когда мне удаётся достичь "всего лишь" двух действительно рабочих часов в день. Меня выводят из себя те дни, когда я не могу сделать ничего.

Я много думал об этом. Я пытался вспомнить время, когда я выполнял больше всего работы в моей карьере. Это было, когда Microsoft перевёл меня в великолепный роскошный новый кабинет с большими окнами, выходящими в прелестный каменный внутренний двор, наполненный цветущими вишнями. Всё было просто супер. Месяцами я работал без остановок, прорабатывая в деталях спецификацию Excel Basic - монументальную стопку бумаги, вдающуюся в невероятные подробности, описывающую гигантскую объектную модель и среду программирования. Я буквально ни на секунду не останавливался. Когда я был вынужден ехать в Бостон на выставку MacWorld, я взял ноутбук с собой и документировал класс Window, сидя на уютной террасе Harvard Business School.

Как только вы попали в поток, несложно продлить это состояние. Многие мои дни идут по следующему расписанию: 1) прийти на работу; 2) проверить почту, полазить по сети и т.д.; 3) решить что я мог бы пообедать прежде чем начать работать; 4) вернуться с обеда; 5) проверить почту, полазить по сети и т.д.; 6) окончательно решить что пора взяться за работу; 7) проверить почту, полазить по сети и т.д.; 8) опять решить что, действительно пора поработать; 9) запустить чёртов редактор; и 10) безостановочно писать код, пока я не осознаю что уже полвосьмого.

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

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

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

Я запомнил это надолго. Я замечал, что почти любая военная стратегия, начиная с воздушных боёв и заканчивая масштабными манёврами военно-морского флота, основана на идее "огня и движения". Мне потребовалось ещё пятнадцать лет чтобы понять, что принцип "огонь и движение" действует и в обычной жизни. Необходимо ежедневно продвигаться вперёд, хотя бы на немного. Не имеет никакого значения что ваш код уродлив и содержит много ошибок, и никому он не нравится. Если при этом вы двигаетесь вперёд, - пишете код и постоянно исправляете ошибки - время на вашей стороне. Будьте начеку когда конкуренты ведут по вам огонь. Может они всего лишь хотят вынудить вас тратить всё ваше время отвечая на их залпы, так чтобы вы не могли продвигаться вперёд?!

Подумайте об истории всевозможных стратегий доступа к данным, разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET - И все абсолютно новые! Может это было вызвано технологической необходимостью? Может это результат некомпетентной группы проектирования, которой необходимо придумывать по-новой доступ к данным каждый чертов год? (Возможно, это в самом деле так.) Но конечный результат - всего лишь огонь для прикрытия. Конкуренты не имеют никакого другого выбора, кроме как тратить своё время, переписывая код под новые библиотеки и поспевая за лидером - время, которое они не могут использовать для создания новых возможностей. Посмотрите получше на ландшафт индустрии программного обеспечения. Компании, которые можно назвать успешными - это те, кто меньше всего зависят от монстров рынка программного обеспечения и не вынуждены тратить всё своё время догоняя лидеров, переписывая код и исправляя ошибки, возникающие только в Windows XP. Менее успешные компании - это те, кто тратит слишком много времени, ловя каждое движение Microsoft, гадая в каком направлении она пойдёт дальше. Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия для того чтобы они могли двигаться вперёд, а вы нет. Таковы правила игры, дружок. Вы собираетесь встроить поддержку Hailstorm? SOAP? RDF? Вы поддерживаете всё это потому, что это нужно вашим клиентам, или потому что кто-то ведёт по вам огонь и вы чувствуете себя обязанным отвечать? Отделы по продажам крупных компаний понимают стратегию огня для прикрытия. Они приходят к своим клиентам и говорят: "ОК, вы не обязаны покупать именно у нас. Покупайте у самого лучшего продавца. Но убедитесь, что получите продукт, который поддерживает (XML / SOAP / CDE / J2EE), потому что иначе вы окажетесь запертым в багажнике". Затем, когда небольшие компании пытаются продавать свои продукты на данном рынке, всё что они слышат - послушное повторение главным менеджером по технологиям: "У вас есть J2EE?". И они убивают кучу времени, переходя на J2EE, даже если это не увеличивает продаж и не даёт никакой возможности выделиться. Эта возможность - чисто для галочки. Вы её реализуете лишь потому, что вам необходима галочка, говорящая, что вы имеете данную возможность, но никто не будет её использовать и никому она по большому счёту не нужна. Это огонь для прикрытия.

"Огонь и движение" для маленьких компаний, вроде моей, означает две вещи. Вы должны иметь время на своей стороне и вам необходимо продвигаться вперёд каждый день. Рано или поздно вы выиграете. Всё, что я сумел сделать вчера - немного улучшить цветовую схему в FogBUGZ. Это нормально. Она становится лучше с каждым разом. Каждый день наша программа становится лучше и лучше и у нас всё больше и больше клиентов. И это единственное, что имеет значение. Пока наша компания не достигла размеров Oracle, мы не должны думать о грандиозных стратегиях. Мы должны просто приходить каждое утро и, как-нибудь, запускать редактор.