Утром 1 октября 2013 года календарь проделанной работы над открытым исходным кодом, расположенный на моей гитхабовской странице, выглядел вот как:

Это не было простой случайностью. Я нарочно решил (руководствуясь GTD-соображениями) достаточно долгое время стараться каждый день чего-нибудь делать на Гитхабе, а затем (если дело пойдёт) поделиться на Хабрахабре наиболее ценными впечатлениями от именно такой манеры работы (назовём её, скажем, calendar-driven development), когда впечатления накопятся.

И поделяюсь.

Во-первых, возрастает ощущаемое значение гитхабовской полуночи — то есть того сáмого мгновения, когда на календаре появляется новый серый квадратик и его можно начинать перекрашивать в зелёный цвет своими действиями. В этот же момент фиксируется и цвет квадратика, соответствующего предыдущим гитхабовским суткам — и кто не успел за эти сутки ничего сделать, для тех счётчик «Current Streak» обнуляется. Проигрыш.

Я знаю теперь наизусть, что полночь на Гитхабе наступает в 11:00 по московскому времени. Объясняется это, по-видимому, тем, что в Москве действует время UTC+4, а Тихоокеанское летнее время (сейчас действующее в Калифорнии — оно продолжит действовать до последнего октябрьского воскресенья) соответствует UTC-7.

Во-вторых, появляется мотивация как можно скорее после гитхабовской полуночи перекрасить новый квадратик, чтобы затем целые сутки не беспокоиться о его серости. Это приводит к росту ощущаемой значимости мелких правок в файлах. Обычно у разработчика есть соблазн (для ненарушения самососредоточенности) делать только основную работу над кодом, а разнообразные мелкие правки (задачи наподобие «набрать ещё один абзац в документации, описывающий последние изменения», «разжевать краткую пометку в документации до целого абзаца, а не то она чрезмерно загадочна», «сочинить ещё один небольшой тест, покрывающий недавно появившиеся возможности», «добавить поддержку кодировки CP808 в модуль, ужé имеющий поддержку кодировки CP866, отличающейся всего-навсего на один символ») откладывать «на потóм», хотя накопление их со временем вызывает естественную реакцию «я не хочу разбирать эту кучу!» и прокрастинацию. При календарной разработке появляется повод «начать день» (точнее, начать сутки после гитхабовской полуночи) именно с одной из этих мелочей — в итоге мелочи не накапливаются. И даже наоборот: случаются такие дни, в которых готовых мелочей недостаёт. Начинает не хватать пользы, ими приносимой.

В чём эта их польза? В том, что они являются готовою ступенькою для внутреннего подъёма к «состоянию потока». Обычно для вхождения «в поток» требуется существенное усилие: разработчику приходится погрузиться в контекст проекта, а затем охватить умом действия, предстоящие для решения некоторой очередной задачи. Начиная же дело с мелочи, разработчику проще погрузиться в контекст того проекта, к которому принадлежит мелочь; а работа над устранением этой мелочи одновременно как бы «разогревает» его ум под более крупную предстоящую задачу (можно уподобить этот приём воздержанию любителя бодибилдинга от подъёма полуторапудовой гири до тех пор, пока мускулы не окажутся «разогреты» поднятием тяжестей, имеющих менее существенный вес). Нет надрыва.

Впрочем, GTD-правила «не откладывай» и «начинай дело понемногу, а там втянешься» и без того известны широчайше. Calendar-driven development (календарная разработка) просто делает следование этим правилам совершенно естественным делом: разработчик не прилагает специальных усилий для того, чтобы вспомнить эти правила или затем принудить себя следовать им — напротив, воспринимает их как готовые игровые приёмы, неизбежно следующие из правил игры с календарём. Чтобы побыстрее озеленить серый квадратик, начни сегодняшние правки с мелочи — тем самым и не отложи её на послезавтра. Два в одном.

Поставив себя перед необходимостью уделять некоторое время проекту ежедневно, разработчик «прокачивает» и тот навык разбиения крупных задач на посильные ежедневные подзадачи меньшего масштаба, который в GTD-практике называется «есть слона по частям» (и которому, вероятно, Evernote обязан своим логотипом). Для изменения художественной силы этого образа можете использовать словосочетание «пережёвывать бегемота», например.

В правилах такой игры с календарём на Гитхабе есть нюансы. Например, коммиты в форк не озеленяют квадратик в календаре (коммиты засчитываются только при попадании в основной репозиторий — более того, только в его ветку по умолчанию или в ветку gh-pages). Зато открытие запроса на слияние (pull request) — озеленяет квадратик. Это намёк не оттягивать запросы.

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

Правда, отправка разработчиком заявки самому себе может зато стать прекрасным средством употребления Гитхаба в качестве хостинга изображений. Предположим, что вам не хочется помещать в репозиторий своего проекта некоторый скриншот (в том числе и потому, что по мере развития кода вид скриншота будет меняться, так что от хранения всех его версий может неприемлемо распухнуть репозиторий). Между тем этот скриншот был бы полезен в README. Что делать? Либо прибегнуть к услугам внешнего хостинга изображений, либо вспомнить о том, что к сообщениям о проблемах можно прилагать иллюстрации, после чего скопировать URL картинки оттуда и вставить в README. И заодно своими действиями озеленить очередной квадрат в календаре.

Можете сами всё это попробовать.

Пóмните главное: руководствоваться именно таким календарём (с жёстким началом суток и всё такое) можно не только на Гитхабе. Я не встречал пока ещё средств для аналогичного учёта труда (автоматическое появление нового серого квадрата в календаре в заданное время суток, нарастание зелёности квадрата в зависимости от количества труда), но они со временем неизбежно появятся.

Автор: Mithgol

Источник