среда, 18 марта 2009 г.

Работать по 10-12 часов в день?

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

Итак все начинается с этапа “мозгового штурма” или “выкуривания” идеи (от “эту тему нужно покурить”). Как правило, здесь не требуется программировать, зато приходится много думать. Иногда очень много думать. Но я не могу напряженно думать над чем-то более 3-4 часов подряд. Получается, что на стадии обдумывания идеи плодотворный рабочий день у меня длится не более четырех (!) часов. Да, всего четыре часа. Временами еще меньше.

Затем наступает этап воплощения идеи в коде. Здесь так же редко встречаются 10-часовые рабочие дни. Скорее речь идет о 5-6, может быть, 7-ми часах нормального кодирования в день. Тогда пишется хороший код, с комментариями, с тестами, и у меня самого нет претензий к качеству написанного кода.

После того, как код готов, наступает этап документирования. Здесь так же продолжительность плодотворного рабочего дня сильно не дотягивает до стандартных 8 часов. Часов 6 на написание документации в день – это еще можно выдержать, хотя и не очень просто. Иногда бывало и побольше, но впечатления были плохими -- “выжатый лимон” это очень точное выражение.

Так когда же можно плодотворно работать по 10 и более часов? Размышляя над этим я вспомнил три ситуации, когда время летит очень-очень быстро.

Во-первых, можно убить массу времени на проведение различных экспериментов. Например, нужно использовать новую библиотеку в проекте или нужно выяснить, как работать с каким-то устройством. Тут просто не замечаешь, как за написанием небольших тестиков уходит один час за другим. Ведь это же так интересно: а что будет, если вот этот параметр передать? А почему ничего не напечатало? А если вот так? Опять нет! А что Google по этому поводу говорит? Ага, тогда вот так. Опять нет! Ну тогда вот так! Опаньки! А чего же сразу не заработало, я же так в самый первый раз писал! Да, да, я знаю, что уже десятый час, еще минут пятнадцать и поеду домой…

Во-вторых, отладка. В поисках причин различных багов время летит совершенно незаметно. Казалось бы, только недавно пришел на работу, а уже поздний вечер, уже пора идти домой, а хочется попробовать еще вот эту комбинацию входных данных. Поскольку сейчас уже точно получится выловить ошибку! А, не получилось. Значит можно вот так попробовать. Сейчас уже точно получится. Опять не получилось… Ну сейчас-то уж точно… Хорошо, когда такая отладка идет не в ночь перед демонстрацией продукта заказчику. Однажды я убил три дня на поиск чужого бага, когда до сдачи оставалось что-то около недели и это при том, что из-за этой ошибки мы еще ни разу не делали полных тестов всей системы. Я бы тогда сидел на работе и сутки напролет, но предприятие было режимное, и в 22:00 помещение нужно было покинуть…

В-третьих, профилирование и оптимизация. Это занятие сочетает в себе “лучшие” стороны двух предыдущих пожирателей времени. Плюс к тому, в профилировании есть объективная составляющая, очень успешно убивающая время: получение результатов профилирования. У меня как-то была программа, которая под профайлером отрабатывала за пятнадцать минут (ну или около того). Уменьшить объем вычислений нельзя было, т.к. тогда не достигалось нужного количество проходов по проблемным участкам кода. Вот и получалось, что я делал небольшую правку в коде, потом пятнадцать минут ждал результата. Потом еще одну правку и еще пятнадцать минут ожидания. Не удивительно, что в таком режиме рабочие дни сильно превышали 8-мь часов.

Получается, что при нормальном развитии событий продолжительные рабочие дни – это редкость. Сначала “мозговой штурм”, когда работать больше четырех часов не получается физически. Иногда эта стадия разбавляется экспериментами. Тогда несколько дней можно просидеть на работе и по 10 часов. Затем кодирование. Во время которого случаются и периоды отладки, и периоды профилирования. После чего документирование, но там опять работа идет не более 5-6 часов в день.

Важное дополнение. Речь шла именно о времени работы над проектов. А не о времени работы в офисе. Это очень разные вещи. Поэтому, когда мне нужно что-нибудь важное сделать, я стараюсь в офисе не показываться :)

2 комментария:

Rustam комментирует...

Можно много работать и почти не уставать :), психологи выделяют так называемое "потоковое состояние" в котором физиологическая цена деятельности понижена а эффективность работы повышена, подробнее тут - http://ezotera.ariom.ru/2008/10/05/print:page,1,pss.html под твои наблюдения вполне неплохо ложится, хотя по моему, при кодировании тоже реально поймать поток.

eao197 комментирует...

За ссылочку спасибо, обязательно прочитаю.

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