Илья Шишков: код, собесы, IT

Почему мои системы ломались одинаково Подведём итоги первой части сериала о личной эффективности (начало тут). Я довольно долго считал, что мои эксперименты с личной эффективностью проваливались по разным причинам. Календарь не выдержал рабочего аврала. В Todoist я слишком увлёкся счётчиками. Методики Дорофеева попытался применять целиком и полностью. Привычки с наказаниями просто не закрепились. Но сейчас мне кажется, что почти во всех этих историях был один общий паттерн. Если моя жизнь не соответствовала системе, я пытался исправить себя, а не подстроить систему. Не успеваю выполнить запланированное — значит, нужно лучше перформить. Не могу поддерживать все практики — значит, не хватает дисциплины. Поставил цель и не достиг — плохо постарался. Знаю, как «правильно» формулировать задачи, разбирать inbox и проводить обзоры, но не делаю этого — ну что же ты такую простую вещь не можешь выполнить, слабак? В комментариях к прошлому посту это хорошо назвали «проклятием знания». Пока не знаешь о какой-то практике, у тебя есть просто проблема. Когда узнал, как её якобы правильно решать, появляется ещё и второй слой: ты теперь знаешь, что делаешь неправильно. Последний раз я довольно ярко наступил на эти грабли в 2025 году. Я посмотрел большое видео Маргулана Сейсембаева про кайдзен-планирование. Методика обещала примерно всё, чего мне хотелось: двигать несколько проектов одновременно, меньше уставать и испытывать меньше стресса. Там были действительно полезные идеи. Например, большие проекты нужно дробить на совсем маленькие действия. Эту штуку я использую до сих пор. Но саму систему меня хватило поддерживать примерно две недели. Каждый день предлагалось начинать с «кайдзен-часа» — целого часа планирования. И вот я сижу, раскладываю задачи, декомпозирую проекты, а внутри растёт тревога: работы полно, люди ждут результата, а я уже час занимаюсь тем, как правильно заниматься работой. Методика, которая должна была уменьшить стресс, сама стала источником стресса. Раньше я бы решил, что опять недостаточно дисциплинирован, чтобы пользоваться хорошей системой. Сейчас смотрю на это наоборот. Если система требует от меня каждый день быть собранным, спокойным, мотивированным, выполнять все ритуалы и никогда не выпадать из процесса — проблема может быть не во мне. Я живой человек. Я устаю. Иногда у меня аврал. Иногда я теряю интерес. Иногда неделю не разбираю список задач. Иногда вообще неправильно понимаю, что со мной происходит. Хорошая система должна уметь работать и с таким пользователем. Наверное, это и был главный поворот во всей этой истории: я перестал искать способ заставить себя соответствовать системе и начал подстраивать систему под реальность. И забавно, что после этого я снова вернулся практически к тем же идеям Дорофеева, которые уже однажды мне «не помогли». Только на этот раз начал совсем с другого конца. И дальше мы поговорим о том, к чему я пришёл сейчас.

Deadline is coming... На выходных съездили в Нижний Новгород. В числе прочего сходили в Нижегородской художественный музей. У меня там глаз упал на картину Рериха "Явление срока". Она вроде как вдохновлена революцией в Монголии в 1924 году, но мне кажется название шикарно отражает приближающийся дедлайн 😁 Он выглядывает из-за гор и суровым своим лицом показывает, что с тобой будет, если не успеешь...

Protobuf оказался не таким монолитным TL;DR: Яндекс выложил в open source YaFF, и это очень красивое архитектурное решение. Я впервые услышал про YaFF больше года назад на одном из мероприятий компаний про бэкенд. А недавно увидел пост у Димы Александрова, руководителя разработки в Лавке, где он поделился подробной статьей на Хабре о том, зачем формат создавали и как он устроен, и ссылкой на исходники. С Protobuf я работал ещё в Яндексе: мы строили на нём cross-backend-протокол. А в «Чёрном поясе по C++» объясняли, как им пользоваться и для чего он вообще нужен. Для меня Protobuf всегда был решением по умолчанию для бинарной сериализации. Описываешь сообщение в .proto, генерируешь код и дальше работаешь с обычными классами. Не думаешь, в каком порядке разложить байты, что делать с little-endian и big-endian и как корректно развивать протокол. Если вы впервые столкнулись с задачей передавать структурированные данные между сервисами или хранить их на диске, скорее всего, не нужно придумывать собственный формат. Берёте Protobuf — и он просто работает. Но у любого универсального решения есть границы применимости. В сценарии, который описывается на Хабре, через runtime проходят огромные объемы данных. Protobuf-сообщение нельзя просто положить в память и начать читать как готовый объект. Его нужно разобрать, выделить память под поля и переложить туда данные. Когда объектов очень много, постоянная десериализация начинает съедать заметную долю CPU. Эту проблему уже решают zero-copy-форматы, например FlatBuffers. Они позволяют читать поля прямо из сериализованного буфера, не создавая отдельное представление объекта в памяти. Но если большая система уже построена вокруг Protobuf, перейти на FlatBuffers — не значит просто заменить одну функцию сериализации другой. Появляются новая схема, другие сгенерированные типы и другой API. Если часть системы продолжает использовать Protobuf, приходится синхронизировать два представления и писать конвертеры между ними. И вот здесь появляется YaFF — Yet Another Flat Format. Он использует привычный .proto как источник схемы и генерирует Protobuf-подобный интерфейс. Но сериализует данные уже не в стандартный Protobuf wire format, а в собственное представление, из которого их можно читать без обычной десериализации. Именно это показалось мне самым интересным. Я всегда воспринимал Protobuf как неделимую экосистему: .proto-схема, сгенерированные классы, правила совместимости и бинарный формат. А авторы YaFF провели внутри неё границу. Они сохранили контракт, интерфейс и привычный способ развивать схемы, но заменили физическое представление данных. Получился почти классический рефакторинг: внешнее поведение сохраняется, а дорогая реализация меняется под капотом. Только рефакторят здесь не класс и не модуль, а целый формат обмена данными. В устройство самого YaFF я пока до конца не погрузился. Несколько важных тезисов по YaFF можно найти в посте у Димы, а в самой статье подробно разбираются разные способы раскладки полей внутри буфера — на эту часть меня уже не хватило. Зато сама архитектурная идея кажется очень красивой: самое интересное в YaFF — не zero-copy само по себе, а то, как его авторы отделили полезный контракт Protobuf от ставшего дорогим способа хранения данных.

Пятьдесят отжиманий за поздний отбой В комментариях к прошлому посту уже ждут счастливого конца истории с выходом на мега-продуктивность. Но в начале 2020 года до счастливого конца было ещё далеко. После тренинга Дорофеева я решил, что полезные техники мне не помогли, потому что снова не хватило дисциплины. Логичный следующий шаг — развивать дисциплину ещё сильнее. На тренинге по успешному успеху я познакомился с человеком, который занимался развитием силы воли и дисциплины. Назовём его Артём. В конце января или начале февраля 2020 года я обратился к нему за помощью. Само по себе это было довольно странно 🤔 Я в детстве занимался в спортивной школе. После неё у меня и с силой воли, и с дисциплиной всё было неплохо. Я умел долго терпеть, работать через усталость и на морально-волевых вытаскивать тяжёлые ситуации. В школе это много раз помогало. В университете тоже. Если что-то не получалось, я привык отвечать дополнительным усилием: сильнее собраться, больше поработать, ещё немного потерпеть. Но к началу 2020 года этот способ перестал давать результат. Параллельно я делал «Алгоритмический фундамент программиста» и работал в Яндекс.Браузере, где у меня не особо клеилось. Мне казалось, что я просто недостаточно стараюсь. Значит, нужно ещё сильнее укрепить силу воли. Подход Артёма строился вокруг формирования полезных привычек. Нужно было выбрать новую рутину и выполнять её каждый день в течение пресловутого 21 дня. За выполнение надо было себя наградить как хочешь. За пропуск — наказание. Через три недели привычка должна была закрепиться. Лучше всего мне запомнилась попытка научиться ложиться спать в 22:30. Если я ложился позже, то должен был наказать себя отжиманиями. Причём их количество зависело от того, насколько позже я лёг. Если ложился после полуночи, по моей формуле могло набежать около пятидесяти отжиманий. Я их делал. Но это почему-то не приводило к тому, что на следующий день я начинал послушно ложиться в половине одиннадцатого. Пока существовала внешняя конструкция, я выполнял необходимые действия. Как только она исчезала, вместе с ней исчезала и привычка. В какой-то момент я всё забросил. Когда награды и наказания назначаешь себе сам, довольно быстро обнаруживаешь, что можешь сам же перестать соблюдать правила 😎 Сейчас я понимаю, что неправильно поставил диагноз. С «Алгоритмическим фундаментом» проблема была не в недостатке дисциплины, а в максимализме и желании сделать слишком много сразу. А в Яндекс.Браузере я просто не прижился и постепенно полностью демотивировался. Только пока продолжал там работать, я этого не понимал. Никакой дополнительный нажим не мог помочь мне там преуспеть. Иногда проблема не в том, что ты недостаточно стараешься. Иногда ты пытаешься силой воли продавить ситуацию, которая тебе просто не подходит. А с вами случалось, что вы пытались напором дожать то, что было просто не ваше? P.S. Это 6-я часть из 12 сериала о моём пути в личной эффективности. Предыдущие части: 1. В 32 года я узнал, что неэффективен 2. Когда всё перестало помещаться в голову 3. Todoist не разрешал мне спать 4. Ты делаешь на 10. Делай на 5 5. Путь джедая мне не помог

Путь джедая мне не помог В конце 2019 года я решил, что упёрся в потолок дохода на основной работе. Мне казалось: если хочу зарабатывать больше, рядом с работой должен появиться ещё один проект, который будет приносить дополнительный доход. Но как всё это совместить? В этот момент мне попался тренинг Максима Дорофеева. Его сайт тогда назывался «Многосделал.ру» — уже из названия следовало, что именно там мне сейчас объяснят, как делать больше и наконец обрести счастье. Я пошёл. Это был живой тренинг в Москве. Его содержание позже почти полностью легло в основу второй книги Дорофеева — «Путь джедая». На тренинге было много принципов, упражнений и инструментов для работы с задачами. Но одну сцену я запомнил особенно хорошо. Максим заставлял участников вычёркивать дела из своих списков! Не переносить на следующую неделю. Не складывать в отдельный проект «Когда-нибудь». Не искать для них более правильное место в системе. Просто признать: вот это делать не нужно. Вообще подход Дорофеева во многом был именно про разгрузку. Про то, как перестать пытаться удержать всё, уменьшить количество обязательств и сделать работу с задачами легче. Но со мной произошёл противоположный эффект. После тренинга у меня осталась рабочая тетрадь и куча новых инструментов: способы формулировать задачи, разбирать списки, декомпозировать проекты, управлять вниманием и принимать решения. И я решил, что теперь должен всем этим пользоваться. В предыдущем посте я рассказывал, как наставник посоветовал мне делать задания не на десять, а на пять. Тот разговор мне не помог 🙈 Я снова отнёсся к обучению как отличник: раз нам дали технику, хороший ученик обязан её освоить. Если я что-то не применяю, наверняка упущу важную часть системы и останусь недостаточно эффективным. Та же история уже случалась со мной на «Электронном мозге». Там я пытался сразу внедрить GTD, разобрать все входящие, выгрузить всё из головы и выстроить ежедневные ритуалы. Теперь поменялись автор, терминология и набор инструментов. Но пользователь системы (то есть я) остался прежним. В итоге система, предназначенная для разгрузки, стала ещё одним большим набором обязательств. Теперь мне нужно было не только работать и делать дополнительный проект, но ещё и правильно обслуживать всё, что я узнал на тренинге. Разумеется, довольно быстро конструкция развалилась. Техники Дорофеева здесь были ни при чём. Проблема была в моём убеждении, что эффективный человек должен освоить всю методику и пользоваться ею правильно. Сразу. Целиком. Но тогда я этого ещё не понимал. Я сделал гораздо более простой вывод: система хорошая, просто мне опять не хватило дисциплины и силы воли. Поэтому в начале 2020 года я пошёл развивать дисциплину и научился делать 30 отжиманий за то, что поздно лёг спать. Но об этом в следующий раз...

Ты делаешь на десять. Делай на пять Вернёмся к сериалу про личную эффективность. В предыдущем посте про Todoist я рассказывал, как начал выполнять задачи ради галочек, а не ради результата. Теперь поговорим о слове, прочно осевшем в нашем лексиконе в последние годы - перфекционизме. На тренинге по успешному успеху было огромное количество домашних заданий. Я далеко не всё успевал делать и сильно из-за этого расстраивался. Я не привык пропускать задания на обучении, в которое сам вписался и за которое заплатил. Если есть программа, её нужно пройти полностью. Если есть домашняя работа, её нужно выполнить. Однажды я подошёл к наставнику тренинга и спросил: — Как мне успевать делать все задания? Ты же сам ругаешь нас за то, что мы выполняем не всё. Он ответил: — Ты делаешь на десять. А ты делай на пять. Я вообще не понял, что он имеет в виду. 😳 Как это — сделать на пять, а не на десять? В школе и университете я был отличником. Потом так же относился к работе: если брался за задачу, старался глубоко разобраться, учесть детали и сделать как следует. Я умел либо сделать хорошо, либо не сделать. Осознанно выбрать другой уровень качества я не умел. Поэтому практически любую технику личной эффективности я превращал в очередной экзамен. Например, одним из заданий на тренинге был дневник успехов. Каждый вечер нужно было записывать минимум десять успехов за день. Поначалу практика оказалась полезной. Я постепенно научился признавать успехом не только что-то масштаба «выпустил фичу, которую делал полгода», но и более обычные вещи: договорился с другом о встрече, прибрался на рабочем месте, закончил небольшую задачу. После тренинга я продолжал вести дневник ещё примерно месяц. Но к тому моменту он уже не решал никакую мою проблему. Я заполнял его, потому что так якобы поступают богатые и эффективные люди. В конце концов я просто бросил. Примерно так же было с целями по SMART. Сначала они помогали сформулировать конкретный результат и не откладывать его бесконечно. Потом я начал заворачивать в SMART почти всё. Если к воскресенью цель достигнута — я молодец. Если нет — сам поставил себе срок, сам его сорвал и сам себя за это отругал. Проблема была не просто в перфекционизме. У меня отсутствовал навык заранее определять, какого качества достаточно для конкретной задачи. Где действительно нужно сделать на десять? Где хватит пяти? А где полезнее вообще вычеркнуть задачу? Без ответов на эти вопросы любая система легко превращается в учебную программу, которую хороший ученик обязан выполнить полностью и правильно. А у вас получается заранее определить, где достаточно сделать на 5 из 10? P.S. Чтобы два раза не вставать: снова приглашаю вас 1 августа на конференцию Back to Back. В этом году C++ Zero Cost Conf проходит внутри неё, а я буду ведущим C++-трека. Участие бесплатное, зарегистрироваться можно на сайте конференции.

I’m back 18 марта 1995 года Майкл Джордан объявил о возвращении в NBA пресс-релизом из двух слов: I’m back. Я тоже возвращаюсь ... к роли ведущего Zero cost conf. Масштаб моего возвращения скромнее, но очень уж мне хотелось привести аналогию с Джорданом 🇺🇸 Четыре года подряд я был ведущим C++ Zero Cost Conf. В прошлом году пропустил, а в этом организаторы снова позвали меня на сцену. Мне нравится сам этот процесс. И нравится моё состояние во время работы на сцене — собранное, живое и очень включённое. Поэтому для меня это не просто возможность ещё раз провести мероприятие. Мне интересно снова поучаствовать в конференции, которая мне близка, и внести в неё свой вклад. В этом году C++ Zero Cost Conf возвращается в новом формате: теперь это отдельный C++-трек внутри большой бэкенд-конференции Back to Back. В общем, I’m back на Back to Back. Удержаться от этой игры слов было невозможно 😁 Конференция пройдёт 1 августа, начало программы — в 12:00. Я буду вести московскую площадку: Лофт №4, 2-й Кожуховский проезд, 29, корпус 6. Присоединиться также можно онлайн. Участие бесплатное, но нужна предварительная регистрация. Смотрите программу и регистрируйтесь на сайте конференции. Приходите — буду рад увидеться с читателями канала уже не в комментариях, а вживую.

Безопасность AI-агентов: то, о чём стоит думать заранее Временно отвлечемся от темы личной эффективности. В июне мы с Антоном Касимовым обсуждали в эфире, что изучать разработчику в 2026 году. Тогда мы много говорили о фундаментальных знаниях, инженерном мышлении и основах технологий, которые ещё много лет будут с нами. Сейчас я прихожу к тому, что этого недостаточно. Я активно экспериментирую с AI-агентами — и в разработке, и в других задачах. И почти каждый раз испытываю двойственные чувства. С одной стороны, это настоящее ощущение чуда: когда агент сам находит нужные файлы, разбирается в незнакомой кодовой базе и иногда приходит к решению быстрее, чем я успеваю понять, с какой стороны к нему подступиться. С другой стороны, в голове всё время звучит тихий вопрос: А не сделает ли он сейчас чего-нибудь лишнего? Не удалит ли нужный файл. Не отправит ли наружу данные, которые отправлять не стоило. Не выполнит ли инструкцию, которую нашёл где-нибудь на подсунутой веб-странице. Для меня AI-агент пока остаётся системой с некоторой долей хаоса. Я могу ограничить его права, посмотреть план действий и проверить результат. Но на сто процентов предсказать и объяснить каждое его действие не могу. Когда агентом пользуюсь только я, риски ещё можно удерживать в голове. Но если сотни сотрудников компании регулярно запускают агентов с доступом к коду, данным и внутренней инфраструктуре, начинает работать закон Мерфи: всё, что может пойти не так, рано или поздно пойдёт не так. Поэтому вместе с вопросом «Как получить от агентов больше пользы?» появляется второй: Как при этом не прострелить себе ногу? Как раз об этом Школа анализа данных Яндекса проводит AI Agents Security Week — бесплатный онлайн-интенсив с 27 по 31 июля. За пять дней там разберут угрозы, возникающие при работе с AI-агентами: защиту данных, безопасный доступ к инструментам и инфраструктуре, возможные уязвимости и архитектуру AI-продуктов. Будут и практические кейсы разработки агентов. Мне нравится сама постановка вопроса. Новую технологию недостаточно просто научиться использовать. Чем больше самостоятельности мы ей отдаём, тем лучше должны понимать границы, внутри которых она может действовать безопасно. Какие меры безопасности при работе с AI-агентами вы уже считаете обязательными?

Todoist не разрешал мне спать Систему посильнее я нашёл в конце 2018 года. К тому моменту «Пояса по C++» стали моей основной работой, а параллельно я пошёл на трёхмесячный тренинг по успешному успеху 🚀 Каюсь, грешен — была у меня и такая история 🙈 На тренинге я оказался среди невероятно амбициозных людей. Они каждый день запускали новые бизнесы, за две недели удваивали доход и постоянно рассказывали, какой очередной подвиг совершили. Тогда инфобизнес ещё не успел всем надоесть, и идея «смени фокус — стань богаче» казалась свежей и убедительной. К обычной работе добавились домашние задания,  новые обязательства и множество мелких дел. Держать всё это в голове уже не получалось. И кто-то из участников посоветовал мне Todoist. Сначала это было именно то, что нужно. Я записывал задачи, переставал бояться их забыть и видел перед собой понятный список. А ещё в Todoist была геймификация: можно было задать дневную и недельную норму выполненных задач. Я поставил себе цель — закрывать пять задач в день и 48 в неделю ✅ Когда выполнял норму, чувствовал себя молодцом. Todoist показывал, что день прожит не зря, а я становлюсь всё более эффективным человеком. Рано или поздно наступил вечер, когда мне давно пора было спать, а дневная норма всё ещё не была выполнена. Можно было просто лечь. Но тогда оборвалась бы серия успешных дней 😱 Поэтому я открыл список и стал искать, что ещё можно быстро закрыть. Ответил кому-то на сообщение. Будучи уставшим, сделал code review очередной задачи для курса по C++. Глубокой ночью я наконец увидел заветную галочку: цель на день достигнута. Только сейчас можно спать. Такие вечера начали повторяться. Я выбирал не самые важные задачи, а те, которые позволяли быстрее выполнить норму. Уже не Todoist помогал мне решать, что стоит сделать. Я помогал Todoist правильно оценить мой день. Если пять задач были закрыты — я молодец. Если нет — значит, облажался, оказался недостаточно эффективным и потерял накопленную серию. Инструмент, который должен был разгрузить мне голову, начал определять мою самооценку и решать, когда мне можно лечь спать. Мне потребовалось довольно много времени, чтобы отключить дневные и недельные цели. Todoist я использую до сих пор, но больше не разрешаю ему выставлять мне оценки. Потому что количество закрытых задач ничего не говорит о том, сделал ли я сегодня что-нибудь действительно важное. А у вас бывало, что счётчик или серия становились важнее самого результата?

Когда голова перестала справляться До 2017 года я вообще не интересовался личной эффективностью. Все задачи я держал в голове. Иногда что-то записывал в бумажный блокнот, но никакой системы у меня не было: ни списков задач, ни календаря, ни регулярного планирования. И это прекрасно работало! Скорее всего, причина была простой: в каждый момент времени у меня было не так много параллельных направлений. Обычно одна основная рабочая задача и ещё что-нибудь рядом. Такой объём спокойно помещался в голове. Но всё поменяла работа над «Поясами по C++». Днём я работал разработчиком в Яндексе. Параллельно мы делали большой образовательный проект: записывали лекции, готовили задания, отвечали участникам, обсуждали организационные вопросы. В основном проекте тоже становилось всё больше коммуникаций. Рабочие чаты, почта, обсуждения — всё это нужно было читать, отслеживать и не забывать. В какой-то момент голова перестала справляться. Тогда я впервые начал планировать день в Google Календаре. До работы занимаюсь «Поясами». В начале рабочего дня — пишу код. Затем выделяю отдельное время на чаты, закрываю их и снова возвращаюсь к основной задаче. Последним пунктом рабочего дня у меня стояло: «Читаю почту». И это неожиданно хорошо заработало. Я впервые почувствовал контроль над происходящим. Можно было спокойно писать код и не бояться, что я пропущу важное письмо: на почту уже выделено время. Можно было закрыть чаты, потому что я точно знал, когда открою их снова. Календарь позволял мне не держать всё в голове. У каждой важной области появилось своё место. Но проработала эта система недолго. На основном проекте началась нервотрёпка. Вокруг постоянно звучало: Мы не успеваем. Нужно быстрее. Если не успеем — нас уволят. И вот календарь говорит, что пора прекратить писать код и полчаса читать почту. Но как можно заниматься какой-то почтой, если код ещё не дописан, ревью не пройдено, а мы не успеваем? Я продолжал работать над основной задачей. Потом ещё немного. Потом пропускал чаты, почту и всю остальную инфраструктурную текучку. Работа постепенно залезла на всё остальное, а календарь превратился в список пунктов, которые я каждый день игнорировал. Сама идея была хорошей. Пока обстановка оставалась спокойной, календарь действительно помогал равномерно двигать несколько направлений. Но под тревогой и давлением система развалилась первой. Тогда я не подумал, что, возможно, никакое расписание не выдержит режима «мы не успеваем, нас уволят». Я сделал другой вывод: Значит, мне нужна система посильнее. А вам удавалось сохранить систему планирования под настоящим давлением?

В 32 года я узнал, что неэффективен В 2019 году я пошёл на программу по личной эффективности под названием «Электронный мозг». Нам рассказывали, как перенести Getting Things Done в Evernote и построить систему, в которой не потеряется вообще ничего. Нужно было выгрузить из головы все дела, разложить их по заметкам и каталогам, регулярно обнулять inbox и закрывать незавершённые циклы. Звучало разумно. Проблема была только в том, что внедрить всё это предлагалось сразу. Я сел выгружать дела из головы — и довольно быстро понял, что их невозможно выгрузить за один вечер. Новые вспоминались быстрее, чем я успевал раскладывать предыдущие. Каталоги разрастались. Inbox не обнулялся. Незакрытых циклов становилось только больше. Ещё каждому участнику назначили личного коуча. Он должен был помогать выстроить систему. Мой в основном следил, чтобы я не оставлял незавершённых задач. Одна из таких задач почему-то регулярно оказывалась покупкой следующей программы 😁 Особенно хорошо я запомнил лекцию про завершение дня. Девушка-тренер подробно описала ежедневный вечерний ритуал: разобрать входящие, подвести итоги, подготовить следующий день, ответить на все сообщения и т.д. В сумме всё это занимало часа два. Я слушал и думал: а когда, собственно, жить и работать, если два часа каждый вечер нужно тратить только на то, чтобы правильно завершить день? При этом вокруг были люди, у которых всё якобы получалось. Коллеги поддерживали пустой inbox. Участники тренингов внедряли привычки, вели дневники, ставили цели и каждое утро начинали с правильных ритуалов. А у меня не получалось. И вот здесь был парадокс. К 32 годам я окончил вуз с красным дипломом, защитил кандидатскую, дважды участвовал в финале ACM ICPC и уже много лет работал разработчиком в Яндексе. До знакомства с личной эффективностью мне казалось, что я в целом нормально справляюсь с жизнью. А потом я узнал, что, оказывается, я жутко неэффективный 😱 Я не подумал: «Возможно, эта система требует от человека слишком многого». Я решил: «Значит, мне не хватает дисциплины и правильных инструментов». Так начался мой многолетний поиск системы, которая позволит делать всё важное, ничего не упускать и больше никогда не чувствовать, что я не справляюсь. Я попробовал календари, Todoist, SMART, GTD, привычки с наказаниями и кайдзен-планирование. Почти каждый подход сначала помогал. А потом начинал требовать свою цену. Но как человек, который до этого нормально справлялся без всякой системы, вообще дошёл до такого вывода? Для ответа придётся отмотать историю на несколько лет назад.

Итак, начинаем сезон личной эффективности. Я собрал всё-всё-всё, что делал и делаю в этой теме, и разделил на 12 историй. Все они объединены двумя вопросами: — зачем растить личную эффективность? — какая у этого цена? В предыдущем опросе самыми популярными оказались варианты «больше зарабатывать» и «освободить личное время». Мне нравятся эти варианты — они самые зрелые. Спасибо всем участникам опроса. Мой ответ на него чуть другой и давайте я приступлю к тому, чтобы его раскрыть 👇

Зачем вообще быть эффективным? В опросе по следующей теме с огромным отрывом победила личная эффективность. Я на этой неделе составлял контент-план и понял, что мне есть что рассказать. Не в формате «вот вам ещё один обзор GTD, Notion, календарей, таск-трекеров и привычек». Этого и без меня в интернете достаточно. Мне интереснее другое. Почему человек вообще начинает растить личную эффективность? На первый взгляд ответ очевиден: чтобы больше успевать. Но чем дольше я в этом варюсь, тем меньше мне нравится этот ответ. Потому что «больше успевать» легко превращается в бесконечный конвейер: закрыл одну задачу — получил три новых ("ну ты же быстро их сделаешь"). Освободил вечер — занял его ещё одним проектом. Научился планировать неделю — начал запихивать в неё больше, чем раньше. И в какой-то момент возникает неприятный вопрос: А я расту в эффективности, чтобы жить лучше — или чтобы эффективнее себя эксплуатировать? У меня путь в личной эффективности продолжается до сих пор. Были периоды, когда я пытался держать всё в голове. Были периоды, когда строил сложные системы. Были моменты, когда система мне помогала, а были моменты, когда она превращалась в ещё один источник давления 😣 Поэтому я хочу сделать серию постов не про «топ-10 методов продуктивности», а про свой путь: что сработало, что сломалось, какую цену пришлось заплатить и зачем всё это вообще нужно. Но перед тем как я начну серию, хочу свериться с вами 👇

Онлайн-бронь стола в кафе в 2026. Что может быть проще? Случайно увидел, что на Яндекс Картах теперь можно бронировать столики в кафе. -- Круто! -- подумал я. -- Рай для интроверта, не надо никуда звонить! 🔥 Выбрал дату, время, количество человек, нажал "Забронировать". Приходит СМС "Ресторан получил запрос, ожидайте подтверждения". Где-то здесь я всё ещё с большим недоверием отношусь к тому, что это всё сработает. Одно дело кнопочки в интерфейсе сделать - совсем другое дело добиться того, чтобы живые люди действовали по процессу, который эти кнопочки задают. К тому же кафе я бронировал не в какой-нибудь продвинутой Москве, а в своём родном Орле. А это добавляло вероятности, что что-то может пойти не так. Но взяв телефон спустя какое-то время и увидев там второе СМС со словами "Ресторан подтвердил вашу бронь", я успокоился и решил, что столик уже точно мой. Думаю, вы догадываетесь, что случилось, когда я в назначенное время пришёл в кафе... Сотрудники в недоумении спросили: "Какая бронь? У нас её нет". К счастью, у них оставался один свободный стол, куда меня и посадили. Мораль Пока одни делают агентов, которые программируют агентов, которые будут порождать субагентов, онлайн бронь столика в кафе - всё ещё не до конца решённая задача 😔

Курс подготовки к собеседованию в HFT — почему его не будет Посты последних нескольких недель так или иначе были связаны с HFT. Это заключительный пост из этой серии — дальше я сменю тему. Чуть больше года назад ко мне через GetMentor обратилась девушка с запросом «Хочу переехать в Лондон и сменить BigTech на HFT — помоги подготовиться». Мы прозанимались более полугода и прошли большой список тем: алгоритмы, С++ concepts, RAM architecture, Ethernet/IP/TCP/UDP и т.д., и т.п. Приведу отзыв, который она оставила о нашей совместной работе: Я давно работаю в big tech и рассматривала для себя возможность перейти в HFT — из-за более высоких зарплат и, возможно, более интересных технических задач. Насколько я понимаю, у собеседований в HFT нет чёткой структуры и стандартных coding-секций, как в big tech: они сильно различаются между компаниями, и в сети не так много информации о том, что именно нужно знать и как готовиться. При этом круг тем кажется довольно широким, а моя текущая работа далека от того, что релевантно для HFT (например, low latency). Самостоятельно составить план подготовки и придерживаться его было сложно, поэтому я решила попробовать поработать с ментором. Профиль Ильи я нашла на GetMentor — он явно указывал опыт в HFT, плюс я знала его по Яндексу, так что решила, что это хороший вариант — как минимум стоит попробовать. В формате 1:1 мне понравилась гибкость — можно было договариваться по времени так, как удобно. Сначала мы встречались два раза в неделю, потом перешли на один раз в неделю, но по два часа. По темам Илья учитывал мои запросы, но также предлагал свои — из опыта работы в HFT и прохождения собеседований. Он объяснял новые вещи или помогал освежить то, что я уже знала, поэтому я могла в основном фокусироваться на практике. Между занятиями были домашние задания, Илья напоминал про них и заранее проверял. Для меня было особенно ценно получать фидбэк на решения, обсуждать спорные моменты и неоднозначные темы, например memory barriers. В результате у меня сложилась более цельная картина: какие темы нужно знать и как они связаны между собой. Илья также давал точечные рекомендации на полезные лекции и conference talks по темам, которые мы проходили. В итоге я решила достаточное количество практических задач, чтобы появилась уверенность перед собеседованиями. Когда мы завершили работу, я подумал, что из этого можно сделать неплохой курс подготовки к HFT: список тем понятен и ограничен, часть материалов удалось уже наработать. Ценность прохождения курса тоже понятна — HFT славится высокими доходами. Но понимая, что создание качественного курса — это долго и сложно («Пояса по C++» мы командой делали 3 года, «Алгоритмический фундамент программиста» я с подрядчиками делал 1 год), я сначала постарался узнать, а есть ли запрос на такой продукт. Спасибо всем подписчикам, кто откликнулся на просьбу поговорить. Вы наряду с другими респондентами дали мне понять, что ... запроса нет 🚫 Из общения я сделал такие выводы: — люди, всерьёз рассматривающие для себя HFT, предпочитают готовиться самостоятельно — они используют ChatGPT/Claude для составления roadmap подготовки и глубокой проработки каждой темы, не испытывая потребности в наставнике для этой работы — ценность во внешней экспертизе они видят только от человека, который много лет провёл внутри HFT — экономика всего этого мероприятия у меня не сошлась Так что делать курс подготовки к HFT я не буду. И по себе, и по окружающим я вижу, что в сфере наставничества нейросети всё больше отбивают себе территорию. Если в сфере обучения оффлайн навыкам позиции людей ещё весьма сильны (игра на барабанах, танцы, вождение автомобиля), то у наставников онлайн-навыков появился очень сильный и гораздо более дешёвый конкурент. И конкурировать с ним можно только своими опытом, чуйкой и интуицией. Если у вас есть запрос, связанный с C/C++ codebase, code review, PostgreSQL internals или подготовкой к интервью или публичным выступлениям, приходите поговорить через страницу на GetMentor — там полный список того, с чем я могу помочь. Отзывы тех, кто работал со мной, есть в отдельном канале.

Когда «готово на 99%» — это ноль Недавно я проходил первый этап собеседования в одну голландскую HFT-компанию. Мне заранее озвучили формат: онлайн-тест на HackerRank, 2 часа, C++. Я ожидал, что это будет именно тест на знание языка. Перед началом даже немного волновался, потому что чувствую, что отстал от C++23/26. Думал, сейчас начнутся вопросы про новые тонкости стандарта, и будет больно. Вместо была одна большая алгоритмическая задача. Перед стартом я поставил галочку, что обещаю не использовать AI-инструменты. Такой вот формальный барьер от вайбкодинга. Думаю, HackerRank ещё и таймлайн написания кода умеет показывать, так что отличить живое решение от копипасты из AI, наверное, можно. Условие оказалось длинным и мудрёным. Мне потребовалось около 20 минут, чтобы понять, что вообще дано, что надо сделать и где в этой задаче задача. Потом примерно за 10 минут я придумал решение. Сейчас, уже после разбора, я знаю, что оно было правильным. Никакого rocket science там не было. Большой leetcode medium/hard: считать данные, разложить их по структурам, переложить в другие структуры, проверить несколько условий, а потом отвечать на запросы. Через полчаса после старта у меня было решение и оставалось полтора часа на реализацию. Казалось, что времени достаточно. Но кода надо было написать много. Я писал его руками, по старинке, постепенно сверху вниз. И в какой-то момент заметил, что до конца осталось 40 минут, а код ещё не дописан. При этом ощущение было нормальное: я продвигаюсь, всё под контролем. Тестировать я начал за 15 минут до конца. И вот тут стало понятно, что 15 минут — это катастрофически мало. Сначала я исправлял ошибки компиляции. Потом оказалось, что программа не проходит даже примеры из условия 😱 Потом я понял, что она вообще ничего не выводит. За минуту до конца мне уже ничего не оставалось, кроме как отправить тот код, который есть. Код не прошёл ни одного теста 😔 После теста я спокойно разобрался, в чём была проблема. Надо было не только считывать входные данные, но и проверять их на валидность. Я чуть неправильно валидировал ввод, и из-за этой ошибки любые входные данные признавались некорректными 😕 После исправления этого места код прошёл все тесты, которые у меня были. То есть алгоритм был придуман. Решение было реализовано. Основная логика работала правильно. Мне не хватило буквально 15-20 минут на отладку парсинга. И вот это неприятное место 🤦🏻‍♂️ Нас часто учат не быть перфекционистами. Не полировать бесконечно код. Не ждать идеального состояния. Доставлять ценность итерациями. Но есть ситуации, где всё, что не 100%, — это ноль. Если программа из-за одного бага в парсинге не проходит ни одного теста, никого не волнует, что внутри у неё правильный алгоритм. Никто не будет разбираться, что там почти всё сделано. Система видит: тесты не пройдены. До свидания. Эмоционально это странный опыт. С одной стороны, очень обидно. Такое ощущение, что Акела промахнулся. Я привык проходить скрининги и воспринимал это как подтверждение, что я всё ещё в форме. С другой стороны, это не похоже на полный провал. Я не сидел два часа перед задачей, не понимая, что делать. Я понял условие, придумал решение, написал код и после теста быстро нашёл последний баг. То есть конкретная попытка провалилась. Но из этого не следует, что провалился навык. Пожалуй, главный вывод для меня такой: на timed coding task важно не просто придумать решение. Важно достаточно рано получить хоть что-то работающее и оставить себе нормальное время на отладку. Потому что между «почти решил» и «решил» иногда лежит не 1% — иногда там лежит весь результат. Вам доводилось сталкиваться с подобным?