Статьи про продуктивность, которые я время от времени читаю, часто советуют сложные методики и приложения, весьма далёкие от реальной жизни. Я уже много лет пользуюсь простым способом, который держится на одном-единственном документе, моём логе. Расскажу, как он спасает меня от хаоса, в котором программирование — это не столько про код, сколько про общение. Ну, и просто немного об эффективности, королях и капусте.

Почему общение становится такой проблемой? Потому что его слишком много, оно хаотично и не имеет единого центра. Вас дергают коллеги, сыплются непонятные задачи, начальство ставит задания вскользь на созвонах, а через месяц интересуется результатом. Информация теряется в почте, чатах и в собственной памяти. А ещё фоном мозг напоминает: "Не забудь, надо сделать то-то и то-то!".

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

Предуведомление: эта система — плод работы моих тараканов в моей, отдельно взятой голове, и может подойти не всем. Но её достоинство в том, чтобы попробовать: пара недель по 5 минут — невысокая цена за надежду побороть хаос.

Вавилонская башня: Взгляд из Р'льеха

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

• Сверху сыпятся не всегда понятные задачи.

• Задачи от команды качества с заголовками "У нас ничего не работает #32", копией заголовка в описании задачи, парой непонятных видео, десятком скриншотов без подписи и 50 Мб логов. В смысле zip на 50 Мб.

• Дёргают люди с их смутными желаниями.

• Отчёт о проделанной работе за неделю паре-тройке начальников, причём в разные дни недели – поди вспомни, о чём надо отчитаться одному, а о чём другому. Причём каждому из шефов интересны разные области: один "железячник", другой "программист", а третий – "менеджер, просто менеджер". И каждому интересна только его область.

• Вопросы остальных членов команды о каком-то коде, написанном и успешно забытом год назад.

• А ещё, выясняется, что всё, что делал по проекту целый год, надо отразить в документации. А что там было, что поменялось, вот и вспомни теперь.

• Приходит неприятный звонок от начальства – почему не сделана фича о которой две недели назад вскользь говорилось на созвоне.

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

• Лапша кода без единого комментария, в котором непонятно, что она делает. Нет, можно понять, после получасового пристального вглядывания, но эта ситуация явно не нормальная.

• Особенно неприятно, когда эта лапша написана мной, а я уже не помню, для чего и как писал.

Вот. Вроде описал всю основную проблематику. Теперь, как со всем этим разбираться.

Мой подход

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

1. Немного не сильно важной, но, тем не менее, полезной информации, типа путей к важным директориям на сервере или куда-нибудь вглубь "C:\Users\User\AppData…", которыми пользуюсь пару раз в месяц, пароли пониженной секретности, типа "12345".

2. Мои задачи,

3. Дальние цели проекта (ближайшие пара месяцев),

4. Ближайшие задачи (сегодня-завтра, максимум на текущую неделю)

5. Лог того, что было сделано каждый день.

В принципе, все первые 4 пункта умещаются на двух страницах. А вот последний пункт – наиболее важный, растягивается до конца документа.

На каждый день у меня есть шаблон, который я каждый день с утра копирую:

Дата (в виде ДД.ММ.ГГГГ)

    Достижения

Раньше там был ещё и подпункт "Проблемы", но он самоудалился, так как проблемы записываются непосредственно перед нашими дневными достижениями в пункт 4, "Ближайшие задачи". Ну, а если найдена новая ошибка, достойная переноса в систему контроля задач, то добавляю туда новую задачу. Чаще всего мне проще её закрыть самому, а потому она в виде ссылки (и её заголовка!) перекочёвывает уже в список моих задач.

Каждый новый день записывается сразу после "Ближайших задач".

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

Каждый новый год этот лог просто копируется и переименовывается, например, в "Планы 2026.docx". Старые достижения в нём стираются, и жизнь начинается с чистого листа.

За год накапливается примерно 80 страниц текста.

Одностраничный шаблон в виде Word документа представлен по этой ссылке, а для тех, кто хочет сразу увидеть на сколько всё просто – скриншот этой страницы:

Смотреть скриншот

Как это работает

Итак, что же писать в лог?

Да всё, что найдёте уместным:

• Ссылки на закрытые задачи в системе учёта задач. Это весьма удобно – закрыл задачу, дал на неё ссылку в логе, а что ещё важнее, название задачи. В принципе, после того, как задача решена, вы просто переносите строку с задачей из задач вам в лог. Ctrl-X, Ctrl-V. Вот и всё.

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

• Если весь день бились над какой-то сложной проблемой, то так и пишите: занимался задачей #15. Немного текста, почему же задача пока не получилась, ваши идеи по ней – всё это только в плюс.

• Заношу туда результаты созвонов, если они относятся ко мне. Просто, чтобы не забыть.

• То же самое и с чатиками в Teams. Всю эту бесконечную ленту прокручивать невозможно, искать – малоприятно. Так что, если есть что-то важное именно для меня – тащу в лог.

Что должно присутствовать обязательно:

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

• Ссылки. Любые – на документы в сети, полные пути к важным документам на вашем локальном диске.

Для чего полезно:

• Быстро записать только что пришедшую в голову задачу. Ну, вроде: "Блин! Тут ещё документацию переписать надо!". Быстренько записываем, и можно думать над более важными вещами.

• Поиск по ключевым словам:

  • Например, спрашивают у вас решение какой-то важной проблемы, которую вы решали два года назад. Достаёте ваши "Планы" за тот год, ищете по ключевым словам из разговора, и сразу натыкаетесь на ссылку на закрытую задачу, а порой даже и на свой ход мысли, если задача была не тривиальная. По тривиальным "морхун"-задачам (о них ниже) обычно через 2 года не приходят.

• Когда коллега спрашивает о чём-то, я быстро отсылаю ему ссылку на описание задачи в системе учёта задач или на параграф в документации. Это в разы эффективнее, чем устное объяснение "по памяти". Работает это, правда только в том случае, если над этой проблемой или параграфом в описании работал лично я.

• Недельный отчёт начальству:

  • Просто копируете лог за неделю, очищаете от дат и ненужного. 5 минут и отчёт готов, даже вспоминать ничего не нужно. Про ненужное: у каждого начальства разные интересы – кто-то начальник над инженерами и его интересует поддержка его оборудования, а кто-то над программистами, и у него совсем другие интересы. У каждого своя тематика и это приходится учитывать.

  • Звонок от начальства: "Что у нас по задаче 15". Просто зачитываете, что там у вас по задаче 15.

А теперь о людях

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

Устные задачи

Бывает так, что начальство / коллега звонит и устно ставит задачу, а потом само про неё забывает. В результате, возникает конфликт: вы сделали, а это было не нужно (начальство забыло или забило) или, вы не сделали, потому что это была не приоритетная задача, а начальство вдруг о ней вспомнило.

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

Привет, Петя!

Помнишь, на прошлой неделе мы обсуждали задачу о [следует максимально полное описание этой задачи]. У меня появилось на неё время и я занесу её в список задач под названием [название задачи]. Согласен?

Теперь у начальства только два выхода: сказать или да или нет. При любом исходе вы не потратили ни дня рабочего времени впустую и не забыли о задаче. Для подстраховки лучше ещё включить в копию письма ваше непосредственное начальство (если задача не от него лично) и пару коллег которые тоже работают над этим проектом, плюс тестировщик – ему же всё это потом тестировать.

"Ходоки"

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

А зачастую, вопрос простенький. Либо, как протестировать закрытую мною задачу, либо что-то связанное с настройкой оборудования. Поэтому, проще описать всё в документации и / или описании решения задачи и количество "ходоков" значительно уменьшится. Ну, а второе – дополнительно отослать тем людям, которых затронет ваше изменение кода письмо с описанием изменения и тем, как оно их коснётся.

Отдел контроля качества и тестировщики

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

Дополнительно, можно маленькими шажками донести до тестировщиков необходимость максимально подробно записывать в описание задачи ошибку и метод её воспроизведения.

О документации

Просто скажу банальную истину: документацию надо писать по горячим следам. Если этого не сделать, придётся долго копаться в коммитах, поднимать изменения в коде и вспоминать, зачем всё это было. Если же времени на документацию не хватило, то на помощь придёт ваш лог – ищете по ключевым словам то, что должно войти в документацию, поднимаете соответствующие коммиты или ссылки на ошибки, смотрите свой ход мысли, если размышляли над проблемой прямо в логе – это уже полдела. И такие изменения в документации тоже документирую в своём логе с указанием названия и номера параграфа.

А теперь немного о дополнительных помощниках в составлении документации:

Внутренние презентации

Иногда, устраиваются презентации по группам о том, что уже сделано и над чем всё ещё идёт работа. Согласен, большинству слушателей это вообще не нужно, и это большинство, слушая в пол уха, занимается своими делами. Тем не менее, если вам выпала возможность рассказать о своей работе коллегам, то хорошо выполненная презентация – это уже как минимум четверть вашего вклада в документацию. Помните, это нужно не дяде-менеджеру, а именно вам (извиняюсь за менторский тон)! Ну, и так как большая часть презентации так или иначе пойдёт в документацию, то лучше с самого начала готовить её самым лучшим образом и, таким образом сэкономить время на документации.

Описания в коммитах и в системе учёта задач

На описании коммита тоже лучше не экономить – он потом так или иначе пригодится, хотя бы при подготовке комментария на закрытие задачи. Просто копируете ваше описание коммита, добавляете информацию для тесторовщика и всё. Fixed.

Комментарии в коде

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

Почта и календарь

В отношении почты я – минималист, не люблю, когда во входящих много сообщений. В этих тысячах входящих просто ничего не найдёшь. Поэтому почту я обычно раскладываю входящую почту по десятку папочек:

• Trash – самая большая папка, куда сваливаются почти все письма,

• Папки по текущим проектам,

• Организационная папочка – туда падает всё общение с HR, информация от дирекции,

• Папочка по каждому из созвонов (если они еженедельные и начальство рассылает письма с обсуждавшимися темами и принятыми решениями). Если начальство после созвонов ничего не рассылает, то папочка, понятное дело, отсутствует,

• Всякие мелочи, вроде папочки для общений с техподдержкой.

В принципе, если приходят ответы, то в папке с входящими оставляю только свежее письмо, так как в нём уже есть все предыдущие ответы. То письмо, на которое был данный ответ переношу в соответствующую папочку. В результате, количество писем во входящих редко превышает 70, причём основная масса – это письма, которые я считаю важными, но не сильно актуальными. Все важные отмечаю цветом.

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

Мотивация

Не знаю, как у других, но для меня работа – это что-то среднее между чтением детектива и игрой в Moorhuhn (помните, была такая игруля, в которой надо было стрелять по петухам?).

Так вот, если задача простенькая, то это типичный "морхун" – "вынес" его прицельным исправлением, протестировал, выложил код в репозиторий, написал развёрнутое описание и скопировал ссылку на закрытую задачу себе в лог.

Но, такие лёгкие задачи случаются не всегда. Иногда исправление ошибок – это как криминальный роман: труп (герцог), пара подозреваемых (садовник, куда же без него, племянник хозяина дома, молодой анархист и нигилист), место преступления (сад)… Надо только их всех допросить и преступник найден. Вроде всё просто – убийца, молодой анархист, ликвидирован, тесты проходят, но, что-то гложет… Тестируем в другой конфигурации – ошибка по прежнему там. И тут внезапно из-за угла всплывает третий подозреваемый, совершенно неожиданный, и оказывается, что преступление было совершено не в саду, а скажем, в спальне, и убит не герцог, а кухарка, а герцог умер, потому что упал на кухаркин нож. Такие задачи заставляют сердце биться быстрее, а описание найденной ошибки и её устранения может выйти довольно длинным, почти как коротенький рассказ:

Заключение

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

В чём это делаю – в Ворде, но, прекрасно ваш любимый WYSIWYG редактор, главное, чтобы в нём можно было выделять цветом, вставлять картинки, списки (обожаю маркированные и нумерованные списки, они визуально структурируют информацию, думаю, вы это и так заметили) и кликать на ссылки. Для минималистов могу порекомендовать RTF. Единственное, что в нём напрягает, так это отсутствие разбивки на страницы.

Тут я выложил небольшой вордовский документ.

Ещё раз: скриншот единственной страницы этого документа

Почему не пользуюсь популярными Notion и Obsidian? Просто потому что их настройки и плагины выглядят как пульт управления космическим кораблём. Слишком много всего.

Из приложений очень понравился SingularityApp, но, "Windows есть Windows, Android есть Android, и с мест они не сойдут".

Благодарности

• Александру Клименкову ( @AKlimenkov ) за шикарные статьи "Прекрасный минимализм текстовых файлов" и "Порядок против хаоса: мои главные ошибки и 5 правил организации личной базы знаний".

• Тебе, читатель, за то, что дочитал до конца.

Такие дела.