Как я изобрёл таймбоксинг

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

И тут я подумал: а что, если блокировать себе не целый блок focus time, а конкретные задачи?

Focus time у меня уже работали, в календаре были выделены блоки на каждый день недели. У меня появился новый ритуал: с утра я садился и 15 минут планировал свой день. Я смотрел на свои задачи, планы и записывал прямо в календарь, где и чем я буду заниматься.

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

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

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

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

Больше интересного про жизнь в IT у меня в ТГ

Лучший способ самопрокачки для инженеров

Я считаю, что лучший способ прокачать свои скиллы - это сделать сайд-проект.

Часто встречаю убеждение, что учиться/саморазвиваться - это про чтение книжек, прохождение курсов и тд. Однако теория без практики мертва, практика без теории слепа. Прочтение кучи книжек и прохождение кучи курсов делает человека эрудированным, а не крутым спецом.

Обучение идет хорошо лишь тогда, когда получаемая информация подкрепляется практикой. Именно поэтому я считаю, что лучший способ прокачаться программисту - это сделать сайд-проект, в котором можно закрепить практикой изучаемую теорию.

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

Я за свою карьеру сделал огромную пачку сайд-проектов. Какие-то были неудавшимися стартапами, другие же я делал с целью разобраться в конкретной теме. Свой первый сайд-проект я сделал ещё до получения первой официальной работы - это был RSS-ридер на C# и WPF.

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

И даже сейчас я продолжаю делать сайд-проекты. Один из них вы читаете прямо сейчас ?

Больше интересного про жизнь в IT у меня в ТГ

Monolith-first подход

Из опыта я глубоко убеждён, что в 99% случаем начинать создание новой системы лучше с монолита. Особенно если это абсолютно новый продукт, которому только предстоит выйти на рынок.

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

В такой ситуации вы начнёте спокойно делить монолит на микросервисы. Выделите связанные контексты, начнёте вынос кода и миграцию баз данных. Это стандартная история IT-мира. У нас был монолит, но мы выросли и мигрировали на микросервисы.

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

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

Больше интересного про жизнь в IT у меня в ТГ

Описание и комменты к код ревью

Есть один очень простой, но удивительно эффективный способ ускорить код ревью в команде и сделать этот процесс более приятным.

Выложив Pull Request, напиши к нему описание и оставь комментарии.

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

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

Не нужно растекаться словом по древу. Достаточно буквально 3-5 предложений. Читать огромную портянку текста тоже никто не захочет.

Сделав это, оставьте комментарии к самому коду. На что ревьюерам стоит обратить внимание? Где вы сомневаетесь в своём решении? Если есть доработки какого-то общего кода, то зачем они были сделаны?

Эти комментарии облегчат жизнь человеку, который будет смотреть ваш код. Помогите ему выделить главное из кода и заострить своё внимание именно на этом.

Больше интересного про жизнь в IT у меня в ТГ

Do it yourself

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

В нашей работе много несовершенства (как и в мире вообще). Системы не идеальны, код далёк от мечты дяди Боба, процессы слегка прихрамывают. И лучшее, что можно сделать — начать понемногу убираться вокруг себя.

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

Гораздо лучшая стратегия — замечать какие‑то недостатки вокруг себя и постепенно устранять их. Это уже сложнее. Нужно тратить свои силы и время на обнаружение, анализ и устранение проблем. Нужно брать на себя ответственность за результаты. Это занятие может быть не самым приятным, но оно приносит свои плоды.

C таким отношением к проблемам никогда не будет скучно. Ведь вокруг постоянно столько всего интересного не сделано и столько всего можно улучшить! Жизнь превращается в увлекательное приключение.

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

Больше интересного про жизнь в IT у меня в ТГ

Focus time

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

Спасла меня в итоге одна простая техника — блокировать в календаре фокус‑таймы. Это просто отрезки времени по 1–2 часа, в которые я отключаю мессенджер и не принимаю звонки. По сути, я просто выделил себе каждый день отрезок (иногда даже не один) времени, в которые я могу сосредоточенно поработать.

Чтобы всем вокруг было проще, я настроил синхронизацию гугл календаря со слаком (использовали их в работе). В итоге у меня в статусе всегда выводилось «Focus time» и время, до которого меня не будет на связи. Ну и конечно я объяснил коллегам, что это такое и зачем я это делаю. А также что в случае адской срочности можно просто позвонить мне на телефон.

Фокус таймы я блокировал с утра в понедельник, в процессе планирования недели. Иногда даже раньше, пока всё созвонами не успели забить. Но для каких‑то очень важных вещей я вполне мог отказаться от focus time и пойти на созвон. Правда, для этого инициатору нужно было убедить меня так поступить — что само по себе улучшало качество коммуникаций.

Что я в итоге получил от этого:

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

2. Созвонов стало чуть меньше. Внезапно оказалось, что многие штуки вообще в тексте можно решить без проблем.

3. Поскольку задачи делались, я стал меньше переживать из‑за них.

Мой канал в ТГ