anetto1502

anetto1502

Канал про разработку на python и не только https://t.me/+0JMEYBjpMDJiYTMy
На Пикабу
Дата рождения: 29 августа
12К рейтинг 99 подписчиков 125 подписок 47 постов 24 в горячем
Награды:
За участие в Авторской неделе5 лет на Пикабу

Зачем нужен code review

Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. Конечно, в дополнение к статическому анализу с помощью настроенного pre-commit и тестам;
— выявить проблемы в архитектуре;
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных.

В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками;
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода;
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде;
— дают приток новых идей для улучшений в процессах, подходах и автоматизации;
— увеличивают децентрализацию знаний и bus factor.

В DevFM пишу о полезном для разработчика: инструментах вроде Raycast, об архитектурных схемах, записываю видео по FastAPI + Docker для начинающих. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике.

Pre-commit — must have утилита любого проекта

Бывает, смотришь на код и сразу видно, что код плохой. Признаков может быть множество:
— разные куски кода по-разному отформатированы;
— импорты в файлах никак не структурированы;
— используются вперемешку синтаксис старых и новых версий питона;
— где-то видны зачатки использования типов, но не везде;
— где-то docstring есть, где-то нет;
Всё это характеризуется так: нет единого стиля в написании кода. Проблема становится особенно актуальной, когда над проектом трудится несколько разработчиков.

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

Для решения всех обозначенных проблем есть замечательная утилита — pre-commit. Один раз в конфиге прописываете, какие анализаторы кода нужно запускать, и далее при любом коммите они будут запускаться автоматически. С этого момента код будет опрятным и шелковистым. Вы просто не сможете сделать коммит, если у анализатора есть вопросики к коду.

В DevFM пишу о полезном для разработчика: инструментах вроде Raycast, об архитектурных схемах, записываю видео по FastAPI + Docker для начинающих. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике.

Что я увидел в своих собеседованиях (часть 2)

Рекомендовал вам записатьсвоё собеседование и делился своими наблюдениями. Вторая часть моих выводов:

❌ Оказалось, что есть типовые вопросы, которые часто задают на собеседованиях, но к которым я специально не готовился. ООП, SOLID, микросервис vs монолит и подобное — без подготовки ответ выходит путанным.
✅ Подботал типовые вопросы.

❌ В какой-то момент я забывался, что нахожусь на интервью и общался с интервьюером, как с коллегой: рассказывал о каких-то негативных моментах в прошлых проектах, говорил от имени команды в контексте "Мы”.
✅ На интервью должна быть дружеская атмосфера, но не нужно забываться. Интервьюера нужно убедить, что я именно тот специалист, который им нужен. На работу устраиваюсь Я, значит в моих рассказах должно быть побольше Я и поменьше Мы. В эту же сторону, поменьше рассказывать о каких-то проблемных местах, побольше рассказывать о удачно решённых задачах.

❌ Во время рассказа "о себе" уходил в ненужные подробности, из-за чего рассказ получался водянистым и производил скорее негативное впечатление.
✅ Я полностью прописал рассказ "о себе", в несколько заходов вычитал и отрепетировал, чтобы в итоге было недолго и по делу.

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

В DevFM пишу о полезном для разработчика: инструментах вроде Raycast, об архитектурных схемах, записываю видео по FastAPI + Docker для начинающих. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике.

Как я использую папки в Телеграм для удобства

Странное дело: Телеграм используют миллионы человек, а внятных гайдов по его удобному использованию я не встречал. Интернет полнится только всратыми лайфхаками вроде "10 полезных функций Телеграм" с набором фич разной степени полезности. Но ни у кого я не видел целостной картины, как ТГ превратить в удобный инструмент для решения задач. Усаживайтесь поудобнее, я вам всё покажу.

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

Что разберём

  • как удобно работать с огромным количеством личных чатов с длительным сроком жизни

  • как удобно организовать чтение каналов, если их много

Как работать с огромным количеством чатов с длительным сроком жизни

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

Мой метод пережил три больших этапа моей жизни:

  • преподавание, при котором в личном чатах десятки студентов, которые что-то хотят спросить или сдать;

  • разработка, при которой активно плодятся рабочие групповые чаты;

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

К последнему мой гайд относится в меньшей степени. Почему? Для позиции преподавателя и разработчика во главу угла я поставил минимизацию прерываний. Это значит, что для основной работы мне нужно обеспечить что-то вроде состояния потока (см. Как поймать «поток»), когда я вовлечён в рабочий процесс (будь то программирование, проверка задания или проектирование нового курса). Любой интеррапт, к которому относится и "прочитать сообщение в месенджере", прерывает поток, откатывает нужный настрой, ломает красивые абстракции в голове. Причём исследования (см. Никогда не отвлекай программиста) показывают, что любое прерывание по факту занимает больше 10 минут, чтобы вернуться к решению задачи. Вот такая вот плата за прерывание контекста у кожаного мешка.

Мой гайд по работе с рабочими чатами и группами чатов такой:

  1. Создаём нужные папки. Думаю, всем пригодятся папки Р (рабочее) и dev (групповые чаты). Чтобы больше папок влезло без необходимости скроллить право, я пришёл к названию папок в 1-3 буквы. Не очень удобно по началу, но я быстро привык. Альтернативное решение – вместо букв использовать эмодзи, но я для этого староват, видимо. По неизвестной науке причине мне некомфортно с иконками в названиях чатов, слишком аляписто, что ли.

  2. Добавляем в Р (рабочее) все рабочие контакты.

  3. Добавляем в dev (групповые чаты) все групповые рабочие чаты.

  4. Опциональный пункт. Для студентов я создал отдельную папку Ст (студенты). Но! Каждого студента при добавлении в контакты я ещё дополнительно помечаю номером его группы, чтобы упростить навигацию. У меня устоялась пометка в формате <год-поступления>-<номер-группы>-<первые-3-буквы-фамилии>, типа 2020-50-iva для Иванова из группы 50, поступившего в 2020 году. Такой формат обозначения вошёл у нас в практику регистрации на институтском гитлабе, поверх которого всякая автоматизация накручена.

  5. Выключаю на всех групповых (кроме тех, где критически важно быстро реагировать) и студенческих чатах звук и все нотификации. У меня получилось, что контакты из Р довольно редко пишут по неважным и несрочным делам, поэтому звук я там оставил. Если бы там часто писали, я бы звук и там выключил. Или договорился общаться беззвучными сообщениями, это просто бомбическая фича в ТГ. Кто не знает – зажмите кнопку отправки сообщения (или правой кнопкой мыши на компе), и появится выбор – отправить сообщение без звука или отложенное сообщение. Отложенное сообщение тоже часто применяю, чтобы напомнить о каком-то деле, прислать мем не ночью и всякого такого.

  6. Теперь у меня 3 папки с чатами (Р, dev, Ст), и вверху есть число непрочитанных чатов в этой папке.

  7. Когда есть время, я смотрю чаты и отвечаю. Но теперь это асинхронное средство общения – уведомления меня не отвлекают от состояния потока. Как часто читать чаты? Я стараюсь ориентироваться на 1-3 часа для рабочих и групповых чатов (на мой взгляд, приемлемая скорость реагирования на не-срочные задачи), и 1-3 дня для студентов (в моём случае студентам мгновенная реакция не требуется).

  8. Схему легко расширять, создавая ещё папки для отдельных групп чатов. В ТГ есть лимит по 100 чатов на папку. С помощью Premium его можно расширить до 200 чатов на папку.

  9. Важные чаты можно закрепить, у каждой папки вроде можно закрепить до 5 чатов (и 10 с премиумом).

Конечно, ещё неплохо включить режим "не беспокоить" в нерабочее время. У меня это с 22:00 до 08:00 -_-

Как удобно читать много каналов

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

Как я использую папки в Телеграм для удобства IT, Telegram (ссылка), Telegram, Отвлечение внимания, Уведомление, Прокрастинация, Программирование, Длиннопост

По данным mediascope, в конце 2023 года 84% пользователей читают каналы в ТГ. А у tgstat есть более детальный опрос про количество каналов.

Как я использую папки в Телеграм для удобства IT, Telegram (ссылка), Telegram, Отвлечение внимания, Уведомление, Прокрастинация, Программирование, Длиннопост

Половина аудитории ТГ читают 10 и менее каналов по данным https://tgstat.ru/research-2023

Как я использую папки в Телеграм для удобства IT, Telegram (ссылка), Telegram, Отвлечение внимания, Уведомление, Прокрастинация, Программирование, Длиннопост

Забавно при этом, что многие подписаны на какое-то адовое число каналов. Но не читают.

Я отношусь к той малой категории людей, которые читают 50+ каналов. Но мой способ чтения, в целом, будет полезен при любом количестве каналов, если вы периодически добавляете новые каналы и удаляетесь из более не актуальных.

  1. Создаём две папки. Я назвал их К (контент) и S (хрен знает почему...).

  2. В К (контент) добавляем самые важные для вас каналы, которые хочется читать всё время. Когда есть время для прокрастинации, читаем отсюда, пока все каналы не прочитаем.

  3. В S добавляем новые, непроверенные каналы. Читаем, когда всё из К уже прочитано, и хочется чего-то ещё.

  4. Если канал из К долго не читается, удаляем его совсем или переносим в S.

  5. Если канал из S всё время хочется прочитать, переносим в К и читаем всё время :)

  6. Для К я сверху закрепил несколько каналов, которые читаю в первую очередь.

  7. Если постоянно остаются непрочитанные каналы, стоит задуматься и отписаться от не интересного вам.

  8. Для удобства я ещё сделал папку Ch (chats), куда положил домовой чат (и закрепил), плюс все чаты каналов с отдельной подпиской. Но этой папкой я в итоге почти не пользуюсь, кроме время от времени заглядывания в домовой чат.

Такое деление на две группы каналов по приоритету позволяет подписываться на кучу временных каналов (типа, о, что-то прикольное), но при этом не терять основные каналы, которые хочется прочитывать всегда. И теперь вкладку "все чаты" можно игнорировать. Хотя я во "всех чатах" закрепил основные чаты (жена и пара друзей), с которыми я чаще всего веду переписку.

Ещё в какой-то момент Телеграм автоматически создал папки "личное" (куда попадают все личные чаты, то есть не каналы и не боты) и "боты" (где все боты и мини-аппы). Довольно удобно. Я сократил названия до Л (личное) и Б (боты). Личное удобно использовать, чтобы посмотреть последние чаты (из всех папок сразу).

В итоге получаем такую картину папок

Как я использую папки в Телеграм для удобства IT, Telegram (ссылка), Telegram, Отвлечение внимания, Уведомление, Прокрастинация, Программирование, Длиннопост

А в верхнем меню это выглядит так. Блоки S с неважными каналами и чаты Ch не влезают, нужно скроллить.

Как я использую папки в Телеграм для удобства IT, Telegram (ссылка), Telegram, Отвлечение внимания, Уведомление, Прокрастинация, Программирование, Длиннопост

Сейчас болею и даже основые каналы нет сил читать, поэтому накопилось непрочитанных уведомлений в каналах.

Вот такой вышел гайд по применению ТГ для разработчика или тимлида. Или профессионального читателя каналов :)

В DevFM пишу о полезном для разработчика: инструментах вроде Raycast, об архитектурных схемах, записываю видео по FastAPI + Docker для начинающих. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике.

Показать полностью 5

Что я увидел в своих собеседованиях, часть 1

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

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

❌ Камера смотрела не на меня, а в сторону, при этом я сам не смотрел в камеру, иногда я говорил не в микрофон и меня было плохо слышно. Да, это тоже очень важно. Собеседнику должно быть комфортно с вами общаться.
✅ Заранее настроил камеру, чтобы по умолчанию смотреть на собеседника, сделал в голове заметку говорить в микрофон.

❌ Я спешил ответить на вопрос интервьюера и начинал отвечать до завершения вопроса. Со стороны выглядело так, будто я просто перебиваю собеседника. Более того, иногда вопрос мог оказаться совсем не таким, как я думал.
✅ Пункт "дослушивать вопрос и не перебивать собеседника" отправился в копилку заметок.

❌ Порой меня спрашивали о технологиях, с которыми я не работал и про которые мало знал. В этот момент я терялся.
✅ При более предметном анализе оказалось, что на любую малознакомую технологию у меня в багаже есть аналогичная, решающая поставленную задачу. Я сделал для себя заметку: если не работал с технологией, не теряйся, подумай, как решить задачу знакомым способом. Более глобальная мысль: стараться минусы обращать в плюсы. И не забывать постоянно изучать разные технологии.

В DevFM пишу о полезном для разработчика: инструментах вроде Raycast, об архитектурных схемах, записываю видео по FastAPI + Docker для начинающих. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике.

Пока ты спишь — враг качается

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

Как организовать процесс постоянного поиска информации? Нужно на постоянной основе (в идеале ежедневно, нормально раз в несколько дней, приемлемо еженедельно) потреблять разнородную информацию как в своей профессиональной области, так и в различных соседних. Это существенно расширяет кругозор и повышает вероятность решения новой задачи впоследствии. Не стоит забывать и про не-технические скиллы, куда входят управление людьми, воспитание детей, истории из жизни — это позволит ориентироваться не только в технологиях, но и в жизни.

Неплохим источником информации для постоянного потребления могут быть проверенные книги, телеграм-каналы, подкасты, хабр, площадки вроде hackernews. Решать прикладные задачи самому тоже не следует забывать.

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

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

Помни: пока ты спишь, враг качается.

В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, Raycast, или об архитектурных схемах, или записываю видео разного уровня, например, для начинающих по FastAPI + Docker. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео. Вливайся!

Показать полностью

Пересмотри своё собеседование

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

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

В случае онлайн-собеседований у вас есть уникальная возможность посмотреть на себя со стороны. Запишите всё: аудио, видео со своей камеры и монитор с собеседником. На Linux для записи экрана удобен Kazam.

По видеозаписи вы сможете выявить свои косяки, которые совершенно не заметны без взгляда "со стороны". Кроме того, вы можете словить реакцию собеседующего на ваши ответы. В процессе интервью сделать это сложно — мозг занят другими вопросами.

После прохождения интервью просмотрите запись и выявите систематические ошибки. Легко сказать — выявить ошибки. На деле совсем не просто найти проблемы в своём же интервью.

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

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

При анализе следующего интервью сверяйтесь со списком проблем. Всё ли получилось исправить?

По результатам просмотра двух первых интервью мои злые друзья нашли 36 проблемных мест. В результате их проработки я сформулировал десяток конкретных пунктов как надо делать и как делать не надо.

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

Желательно спросить разрешение противоположной стороны на видеозапись. С другой стороны, если вы не планируете запись публиковать, то требуется ли разрешение?

В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, Raycast, или об архитектурных схемах, или записываю видео разного уровня, например, для начинающих по FastAPI + Docker. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео. Вливайся!

Показать полностью

Ведение дел – мой опыт

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

Кому будет полезно?

– проектным работникам и фрилансерам, чтобы не упускать важные задачи;
– людям с супер разнообразными задачами, которые не ложатся в стандартный флоу условной разработческой деятельности;
– руководителям и тим лидам;
– студентам, чтобы как-то упорядочить непрерывный поток лабораторных работ и прочих активностей.

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

Основные принципы

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

  1. Фиксируйте всё. Абсолютно любые задачи, идеи и прочие мелочи, всё должно быть записано. Разгрузите оперативную память, не храните ничего в голове. Голова нужна, чтобы думать, а не помнить.

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

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

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

Как начать в первый раз

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

Готовимся:

  1. Где-то раздобыть хорошее настроение, свободную голову и расслабиться.

  2. Взять ручку и бумажку, а лучше несколько.

  3. Освободить час времени, хотя кому-то может хватить и 15 минут.

  4. Выключить все мобилки, любые нотификации, закрыть всю технику, убрать все отвлекающие факторы.

Действуем:

  1. Садимся в удобном месте, засекаем время (зачем трекать время?) и начинаем писать ааааабсолютно все мысли, которые приходят в голову: там будут задачи, идеи, напоминалки вроде "полить цветы", всё-всё-всё. Пишем и пишем. Когда я такое первый раз делал, исписал 4 листа А4.

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

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

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

Устройство пространства

Теперь поговорим о структуре организации наших задач. Реализовать подобное, думаю, можно в любом таск-трекере. Пространство задач состоит из разделов, тегов и фильтров: – разделы позволяют разбить задачи на группы; – теги я применяю для структурирования задач, причём теги работают вне разделов; – фильтры как способ отобрать нужные задачи и работать только с ними, центральная фича в моём ведении дел.

Разделы, теги и фильтры могут быть весьма индивидуальными, ниже я делюсь своими.

Разделы:

Стараюсь обходиться минимальным количеством разделов: inbox для входящих задач/мыслей/всего подряд, work для оформленных рабочих задач, meeting для созвонов и встреч и wiki для заметок, мыслей и идей. Подробнее о разделах:

  1. inbox (входящие) – это вход в ваше пространство. Место, куда записывается абсолютно всё, никак не обработанное. Идеи, задачи, микро-таски, что-то на подумать, ответить позже – всё сбрасываем сюда, чтобы не упустить. В дальнейшей работе целью будет ежедневно опустошать этот раздел.

  2. work (работа) – раздел, где содержатся оформленные, понятные рабочие задачи.

  3. meeting (встречи) – онлайн созвоны или оффлайн встречи являются особым типом задач, в которых ты привязан к конкретному времени и где нужно коммуницировать с другими людьми. Бывает нерабочие дела, попадающие в рабочее время (например, поход к врачу) удобно оформлять в виде встречи.

  4. wiki (база знаний) – некоторое пространство для заметок, мыслей, хранения статей. Тут пока ничего не порекомендую, очень индивидуально выходит. Можно отдельный рассказ строить о том, как организовать базу знаний. Многие для таких целей используют отдельные приложения, например, Obsidian с разухабистым функционалом или Anytype. Я пока и это храню в TickTick, но в поиске другого решения.

Теги:

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

  • awaits_me (ожидает_меня) – супер-важный тег, им помечаю задачи, которые блокируют чью-то работу. Стоит делать такие задачи в первую очередь, так как кто-то сидит и ждёт от меня результат, чтобы продолжить выполнение какой-то своей задачи.

  • assigned_control (поручено_контроль) – использую, когда кому-то поручил задачу и жду результата, чтобы дальше использовать артефакт работы. Иногда использую для контроля выполнения не очень больших заданий. В таком случае, сразу после постановки задачи закидываю себе задачу по контролю на через условно неделю, чтобы проверить.

  • ping (напомнить) – использую для напоминаний в личных целях, например, напомнить что-то жене. На работе я рассчитываю, что сотруднику ничего напоминать не нужно. Хотя бывают случаи, когда команда работает в запаре. Тогда явно себе помечаю, что хоть Коле задачу я выдал, но нужно бы напомнить, а то у него сейчас и так OOM (out-of-memory). Причём выдать задачу Коле означает: создать задачу для Коли в командном таск-менеджере, прописать в задаче её особенности, зафиксировать время выполнения. При этом для контроля выполнения у нас есть прекрасный тег assigned_control, который был выше.

  • now (сейчас) – таким иногда помечаю те микро-таски, которые можно сделать меньше, чем за 5 минут. Их полезно делать сразу, чтобы они не висели, и быстренько их закрывать.

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

Фильтры:

Когда задачи разложены по разделам и помечены тегами (как всё разложить расскажу ниже), нам надо в них ориентироваться. Не все нужно задачи делать сегодня, а по некоторым вообще непонятна дата исполнения. Если пользоваться только разделами, то получится некая такая мусорка. При этом часто одновременно нужны задачи из нескольких разделов (работа и встречи, например). Для себя я накрутил несколько фильтров.

  • Работа на сегодня. Показывать разделы work и meeting с установленными датами Сегодня или Ранее (то есть просроченные задачи). Это самый главный фильтр, по сути, он используется 90% времени. Начинать рабочий день удобно с понимания предстоящего фронта работ. Также важно, чтобы глаза не разбегались от количества задач. Очень приятно, когда всё или почти всё сделано в конце дня, можно почесать пузико и идти обнимать жену и детей.

  • Завтра. Показывать разделы work и meeting с датой выполнения Завтра. Иногда (или очень часто?) нужно понимать, что вас ждёт завтра.

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

Разбираем inbox

У наших задач уже есть структура, они разбиты по разделам и помечены тегами. Как дальше с этим работать, что брать в работу и когда? Что в первый раз, что при каждом очередном просмотре inbox моя логика обработки примерно такая. Каждый раз просматривая inbox, раскидываем задачи, исходя из ваших приоритетов. Что-то нужно сделать завтра, что-то через неделю, что-то записать в базу знаний, что-то удалить. При просмотре inbox также смотрю на понятность формулировки и наличие деталей к задаче, если что-то непонятно – дописываю или ставлю задачу уточнить какие-то детали.

Главное – планировать на день выполнимое количество задач. Если попробовать формализовать задачу заполнения расписания по дням, то выходит так:

  • Задачи с фиксированным временем начала (в основном, это встречи/созвоны) оформляем с привязкой ко времени.

  • Периодические задачи (полить цветы, актуализировать ресурсный план, подготовить отчётность, ...) оформляем как задачи, привязанные к дате.

  • Теперь на завтра осталось сколько-то свободного времени, условно, 5 часов. По опыту желательно запланировать на завтра задач часа на 4, потому что неизбежно будут появляться доп задачи, которые тоже съедят время. Эти задачи я уже планирую без времени. Как только образуется свободное время, я начинаю делать очередную задачи из запланированных. Закончил всё на сегодня? Можно взять из планированных задач на завтра.

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

Алгоритм работы с таск-менеджером

Попробуем рассмотреть мою работу на примере. Итак, начинается рабочий день.

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

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

  • Если в течение дня прилетают задачи по любым каналам, то либо кладём в inbox (если задача абстрактная и непонятная), либо добавляем сразу в раздел Работа (для понятных и структурированных задач). Однако, если добавляете в "Работу на сегодня", стоит подумать, а что из запланированного у вас съедет. Время не резиновое.

  • Наступает конец рабочего дня, на крайняк начало следующего. И тут обращаемся к задаче Ежедневный обзор. Что это такое? Это киллер-фича используемого мной метода ведения дел, периодическая ежедневная задача Ежедневный обзор, ниже опишу процесс работы с ней. В описании Ежедневного обзора такие чекбоксы:

    • Все ли планируемые задачи записаны? Если нет, внести в inbox.

    • Разобрать inbox. Задачи оттуда должны переехать в категорию, опционально получить тег и дату выполнения.

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

    • Посмотреть запланированное в "Работа на сегодня", но не выполненные задачи. Надо ли вам в связи с этим что-то делать прямо сейчас/ завтра/ на неделе/ потом? Если да, то перепланировать задачу или создать новую.

    • Есть ли в вашем списке "Работа на сегодня" старые задачи, которые менялись больше суток назад? Переформулируйте их.

По каждому пункту пройдёмся подробнее.

  • Внести всё в inbox важно, чтобы разгрузить оперативную память. Какие задачи вам надо будет выполнить завтра? Подумать всё ли, что запланировал сделать, внёс в список? Просто посидеть в тишине минутку, подумать, ничего ли не упустил. Много задач на день не должно быть, и приоритизировать их после беглого взгляда очень просто. Не буду тут акцентировать внимание, как приоритизировать задачи, у вас может быть свое видение и алгоритм. Но оговорюсь, если задач на день у вас слишком много, то что-то не так в консерватории. Вы физически не сможете сделать задач больше, чем умещается в ваше рабочее время. Несделанные задачи могут превращаться в снежный ком и демотивировать. Реальность нужно принять. Задачи, которые не влезают в ваш рабочий день, нужно либо делегировать, либо удалять.

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

  • Полезно пересматривать выполненные задачи. Часто бывает так, что по результатам сделанной задачи может потребоваться новая задача. Условно, разбирали с командой беклог. После разбора нужно создать новую задачу: поставить задачи команде по результатам груминга. И вот, чтобы такое не упускать, нужен этот пункт. Просматриваем все сделанные за день задачи, и смотрим, нужно ли завести какие-то новые. Если да, то, очевидно, заводим.

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

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

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

Себе я купил TickTick premium, но, в целом, он не требуется. Подписка стоит 36$ в год, даёт календарь, хитрую статистику и разного по мелочи.

В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, fcron, интересных хаках вроде запуска LLM прямо в шрифте, или об архитектурных схемах. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео. Вливайся!

Показать полностью
Отличная работа, все прочитано!