anetto1502

anetto1502

Канал про разработку на python и не только https://t.me/+0JMEYBjpMDJiYTMy
На Пикабу
Дата рождения: 29 августа
в топе авторов на 700 месте
12К рейтинг 103 подписчика 133 подписки 51 пост 24 в горячем
Награды:
За участие в Авторской неделе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 на степике, немного подкастов и видео. Вливайся!

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

Трекайте рабочее время

О правильной организации рабочего времени написан вагон книг и статей (например, помидорная техника). Расскажу про свой опыт со стороны программиста. На протяжении 5 лет я отслеживаю время, затрачиваемое на работу. Как и всегда в разработке, стоит начать с вопроса: зачем я это делаю и что это мне даёт?

Считаю, что мастхев трекать время в двух случаях:

  1. когда сдельно работаешь на разных проектах

  2. когда работаешь на удалёнке

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

Сдельная работа

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

Приведу пример: за проект мне заплатят Х денег. Но вот вопрос: а на сколько он выгоден? А если невыгоден, то из-за чего? Что мне сделать для увеличения выгоды?

Денежную выгоду от проекта легко свести к часовой ставке. Для этого нужно разделить полученный доход Х на количество затраченных часов У. Итого моя ставка М=Х/У, и с её помощью я могу понять уровень своей удовлетворенности конкретным проектом. Если М больше устраивающей меня часовой ставки, то проект удачный, если меньше — то проект неудачный. Но эта метрика доступна, только если я измерил затраченные на проект часы. Конечно, нельзя всё только к финансовой составляющей сводить, есть ещё удовлетворение от проекта и прочие неочевидные качественные метрики.

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

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

У меня в таск-менеджере есть ежемесячная задача на анализ выгодности своих проектов. Это позволяет держать руку на пульсе.

Удалённая работа

Сейчас удалёнкой никого не удивить. Но у удалённой работы есть вот какая проблема. Ты вроде дома, а вроде и на работе. Легко попасть в одну из крайностей, где ты либо избыточно много работаешь, либо, наоборот, слишком часто прерываешься в ущерб рабочим вопросам. И трекинг времени можешь помочь соблюдать work-life balance. Я заметил два момента:

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

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

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

В этом случае измерение времени позволяет мне соблюдать тот самый work-life balance.

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

Что лучше не трекать

Небольшое предостережение. С первого взгляда может показаться: "как же классно знать, куда уходит моё время. Это же такое прекрасное поле для оптимизаций!". Но не замахивайтесь сразу на сложное — измерять всё. Сколько времени кушал, развлекался, занимался спортом, уборкой и миллионом других занятий, категории для которых часто предлагают приложения для учёта времени. Мой опыт показал, что это бесполезная информация, а отслеживание большого количества активностей требует серьёзной собранности. Без четкого понимания цели, вы, скорее всего, быстро забьёте. Если хотите попробовать трекать время, остановитесь на том, что вам действительно важно.

Что касается приложений для этих целей — я пользуюсь atracker, коллега atimelogger, но вариантов много на любой вкус.

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

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

Моя борьба со снупом2

Делюсь с вами опытом своего друга. Ему слово.

История умалчивает, как я попал в эту западню, но 5 лет я жил в полнейшей зависимости от сосудосуживающих капель вроде снупа. Оказаться где-то без капель было абсолютной трагедией. В инструкции написано, что применять не более 3 раз в день и не более 7 дней подряд. Но вот я отступил от этих требований и превысил дозу. В результате стал снупозависимым, десяток применений каждый день всё время. И нос дышит только после применения капель. Бутылочка спрея стала моим лучшим другом. Для понимания масштаба, с автономные походы (обожаю походы) я был вынужден брать пару десятков бутылочек, на всякий случай.

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

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

И таких историй у меня ещё с десяток припасено.

Что мне советовали, чтобы избавиться от этой проблемы, но что мне не помогло:

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

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

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

– сделать операцию. Также слышал об этом, но в эту сторону пристально как-то не смотрел. Наверняка, для кого-то это окажется единственным вариантом.

Парампампам... как же в итоге все решилось у меня.

Уже и не помню, откуда мне пришла эта идея, но все оказалось очень просто. Я начал по чуть-чуть в капли подбодяжиавть простую воду (upd: в комментариях по делу рекомендуют физраствор, а не воду). Если что, крышечка капель хорошо открывается после небольшого усилия.

То есть берёте свой пузырек и подливаете туда процентов 10 воды. Когда этот пузырек закончится, в следующий пробуете добавить побольше водички. И так с каждой итерацией доля воды будет становиться всё больше. А ваша зависимость от капель всё меньше. Небольшое отступление. Некоторым снуп с водой кажется мерзким. Я разницы не чуствовал.

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

Тут-то на помощь и придут лечебные капли. Я пользовался Назонексом, но лучше проконсультируйтесь у врача. То есть в тот момент, когда увеличение дозы приводит к тому, что капли перестают работать, больше дозу воды не увеличиваем и начинаем ещё закапывать Назонекс.

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

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

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

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

Преодолеваем постоянное откладывание дел

Для разгрузки оперативной памяти я все будущие задачи вношу в таск-менеджер. Независимо от объёма задачи, всё должно быть записано, чтобы не держать в голове. Но дальше возникает большая проблема — некоторые задачи после внесения в таск-менеджер я делаю примерно никогда, постоянно отодвигая на "когда-нибудь потом". Это приводит к большим неудобствам. Например, вторая часть стрима python student уже два года откладывается. Проблема в том, что назначение подобной задачи "на сегодня" плохо помогает, так как задача большая и сложная, подступиться к ней сложно. Мой опыт преодоления откладывания дел базируется на одном принципе:

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

Давайте на примере. Задача "снять ролик python students, часть 2". Декомпозируем:
— решить, какие темы включить в ролик;
— прописать сценарий;
— прописать текст;
— снять ролик;
— смонтировать ролик;
— расставить текстовые подсказки по смонтированному ролику;
— подкорректировать аудиодорожку;
— выложить ролик;
— написать пост-расшифровку ролика.

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

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

Для меня главный фактор откладывания задачи — её неясность. Дробление задачи позволяет неясность устранить. Задачи должны быть такого размера, чтобы минимизировать напряжение мозга: взял и сделал.

Еще один житейский пример: в машине загорелась лампочка "долить охлаждающую жидкость".

Уже на опыте я не заношу задачу: "Съездить в сервис и долить жидкость". Куда ехать? Когда ехать? — вот такие вопросы у меня будут возникать и я точно буду её откладывать.

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

Обратите внимание на подсказки в скобках, они позволяют в момент решения задачи дополнительно не думать: А как выбрать сервис? А что нужно дополнительно уточнить, когда буду звонить?

Полезны ещё несколько аспектов:

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

✅ Учитываю приоритет задачи. Если задача важная / выгодная / полезная, то планирую её пораньше.

✅ Умеряю перфекционизм. Часто надо сделать хорошо, а не идеально. Опускаться до уровня "кое-как" не всегда оправданно, но иногда и это годится.

✅ Для меня ещё работает практика начать чуть-чуть. Если к чему-то не могу приступить, просто ставлю себе установку — начну и 15 минут поделаю. Обычно после такого старта я с удовольствием продолжаю делать задачу. А если нет, то не расстраиваюсь, ибо значит задача не такая нужная.

В дополнение вспомним про хорошую и плохую прокрастинацию от Пола Грэма . Это когда ты занят, но не тем.

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

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

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

Ответ на пост «Провайдеры потребовали у ФАС разобраться с Роскомнадзором из-за замедления YouTube. Во - дела!»7

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

Отличная работа, все прочитано!