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

😢 Просто соринка в глаз попала

В этот день 10 лет тому назад мы начали работать над «Белым поясом по С++». А работа над любым проектом, как водится, начинается с создания чатика 😆

Если кто не знает, «Пояса по С++» — это 5 курсов, которые обучают языку C++ с нуля до уровня, достаточного для прохождения собеседования в BigTech (именно так мы формулировали цель курсов). Мы назвали курсы цветами поясов из карате, чтобы показать, как человек становится всё более и более зрелым спецом, проходя их один за другим.

Через 3 месяца после старта работы по моей инициативе мы выбросили весь материал на помойку и начали заново 😳 — я подробно рассказывал об этом на С++ Russia.

Это было лучшее решение. Без него у нас не получился бы продукт, через который прошли 40000+ человек. Ко мне до сих пор подходят люди со словами благодарности за те курсы — это всегда очень приятно ❤️

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

Чудесное было время, отличный получился продукт. Просто хочу поделиться с вами этой ностальгией...

Код стал дешёвым. Что осталось программисту?

Продолжаю отвечать на ваши вопросы. Сегодня разбираем вопрос

Куда идет разработка, ведь стоимость кодогенерации стремиться к нулю, на что ставим, изучаем ? Т.е. что уже понятно, а что еще нет

У меня на этот счёт довольно оптимистичный взгляд. Профессии программиста нет ещё и ста лет: одни из первых программистов ENIAC начали работать в 1945 году. Для сравнения, фотография стала коммерческой профессией ещё в 1840-х, а регулярные авиалинии появились в 1914-м. Поэтому, может быть, мы наблюдаем не смерть программирования, а наоборот — его подростковый возраст. Профессия просто впервые настолько сильно меняет форму.

Я работаю разработчиком с 2008 года, и написание кода никогда не было главной частью моей работы. Работающий код — это продукт, который производит разработчик. А его реальная работа происходит раньше.

Когда мне делали оффер в СберТех, я спросил будущих коллег, что для них важно в моей роли. Мне ответили: «90% времени надо работать головой». Так и получилось. В моей нынешней R&D-работе я иногда могу три недели почти не писать код и всё это время вполне успешно продвигаться по задаче. R&D — это, конечно, крайность, но и в любой разработке сначала нужно ответить на вопросы:
— Какую задачу мы вообще решаем?
— Зачем? Кому от этого станет лучше или перестанет быть плохо?
— Какие есть ограничения? Как решение встроится в существующую систему?
— Что мы сломаем? Как потом это поддерживать и развивать?

И только после всего этого идёт код. Поэтому мне не кажется, что нейронки обесценивают труд программиста. Скорее они его выкристаллизовывают. Последние два года я много пишу на C и так его и не полюбил: слишком много надо стучать по кнопкам, чтобы сделать простые и понятные вещи. И я счастлив, что теперь значительную часть этого может сделать coding-агент, а я потрачу освободившееся время на YouTube shorts более глубокое исследование задачи.

То же самое относится к Make, CMake, Bash, Git, GDB и куче других инструментов, которые невероятно мощны, но совершенно не приспособлены к тому, чтобы простые смертные могли легко ими пользоваться. Раньше существенная часть времени уходила на то, чтобы вспомнить хитрый флаг, раскопать синтаксис Makefile или найти нужную команду GDB. Если не пользуешься этим каждый день, детали мгновенно вымываются из головы.

Теперь мне всё меньше нужно помнить как именно попросить инструмент сделать нужную вещь. Но мне всё ещё нужно понимать, что он умеет и что именно я хочу от него получить. Можно не помнить команду GDB — но нужно понимать устройство процесса и что именно ты пытаешься проверить.

Есть и ещё одно следствие. Дешевеет не только production-код — дешевеет эксперимент. Раньше мысль «а что если сделать вот так?» могла стоить 3 дня работы, поэтому многие гипотезы я даже не проверял. Теперь можно быстро собрать прототип, попробовать несколько альтернативных решений, написать benchmark — и выкинуть всё, если идея не сработала.

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

Стоимость написания кода стремится к нулю. Стоимость понимания задачи — нет. И всё чаще скорость разработки определяется именно скоростью этого понимания.

А какая часть вашей работы уже сейчас упирается скорее в понимание, чем в написание кода?

Senior — это не набор технологий

Продолжаю цикл постов с ответами на вопросы подписчиков.

Меня спросили, какой, на мой взгляд, skill set должен быть у middle и senior и куда вообще расти после senior: в стартап, в менеджмент, глубже в домен, математику, алгоритмы, C++?

Мне кажется, сам вопрос про skill set немного сбивает с толку. Как будто где-то существует список: middle знает пять технологий, senior — восемь и ещё три языка программирования.

Я бы разделял middle и senior по двум другим вещам: масштабу ответственности и точности действий.
Middle обычно получает на вход задачу. Понятно, какого результата нужно достичь, и хотя бы примерно виден путь. Внутри остаётся много пространства для инженерных решений: разобраться в коде, выбрать алгоритм, собрать дополнительные данные, решить, как именно реализовать нужное поведение. Хороший middle — надёжный разработчик: ему поставили задачу, а он принёс работающий результат, в идеале доведённый до прода.

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

Вторая характеристика — точность. Senior много раз проходил весь этот путь и поэтому лучше понимает, где нужно глубоко разобраться и всё отполировать, а где достаточно собрать из 💩 и палок. Какие инструменты использовать, где можно безопасно срезать угол, а где ошибка потом обойдётся очень дорого. Это не обязательно означает, что senior быстрее middle пишет код: middle, который каждый день сидит в IDE, запросто может печатать быстрее. Речь про экономность всего пути от проблемы до результата.

Поэтому я не верю в skill set вида «senior обязан знать три языка». Я считаю себя senior-разработчиком, при этом очень хорошо знаю C++, приемлемо Python — и всё. Зато я уверен, что при необходимости освою новый язык за несколько месяцев. На мой взгляд, гораздо важнее очень хорошо знать хотя бы один язык и глубоко понимать фундамент своей области. Алгоритмы, устройство систем, базы данных, ОС — набор зависит от специализации.

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

А дальше единого роадмапа уже нет. Стартап может отлично прокачать широту, скорость и ответственность: нужно быстро собрать решение из множества технологий и получить результат. Корпорация может дать другую мышцу — глубину, фундаментальное понимание сложной системы и навык делать очень точные изменения там, где ошибка дорого стоит. Оба пути имеют обратную сторону. После стартапа может не хватать глубины. После многих лет в большой корпорации — широты и привычки брать на себя область целиком. IC и менеджмент — ещё одна развилка, и я точно не стану утверждать, что один путь «выше» другого.

Поэтому мой универсальный роадмап гораздо скучнее: постепенно брать на себя чуть больше ответственности, чем у вас есть сейчас. Не в режиме «сейчас я отвечу вообще за всё», а брать проблему, путь к решению которой вы примерно видите, хотя ещё не знаете всех деталей. Дальше вы неизбежно найдёте по дороге десяток граблей, о существовании которых не подозревали. И именно на них middle постепенно и превращается в senior.

Какая из двух senior-мышц у вас сейчас сильнее: ответственность за результат или точность инженерных решений?

Как я потратил 3 часа на анимации, которые пришлось выкинуть

Привет! Я обещал ответить на вопросы подписчиков. Сегодня отвечу на

Как ты готовишь технические презентации для публичных выступлений? Дизайн, структуру

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

Начну с истории — 2017 год, готовлюсь к докладу на C++ Russia (сам доклад, я там в конце мультик про Вольтрона показал). Я сразу придумал, что код в моих слайдах будет с анимациями — тогда я ни у кого такого не видел, и это не только выглядело круто, но и делало доклад понятнее. Идея мне так понравилась, что я первым делом стал делать эти анимации в PowerPoint. Мне казалось важным показать их уже на первом прогоне: «Смотрите, как красиво меняются блоки кода!»

Правда после первого прогона я понял, что часть кода показывать вообще не надо, а часть надо переписать. А значит, и снова переделать анимации 🤦🏻‍♂️ 2-3 часа работы впустую. В масштабе подготовки одного доклада это много.

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

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

В следующем посте обсудим, кто такие современные мидлы и сеньоры — про это от вас тоже был вопрос.

Season finale: моя скучная система личной эффективности

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

Начинается всё с входящих. Здесь у меня почти классический GTD: всё, что возникло в голове и что нельзя просто сразу сделать и забыть, я стараюсь немедленно зафиксировать. Пришла идея — пишу теми словами, которые пришли в голову. Кто-то попросил прислать файл — сразу появляется «отправить Васе такой-то файл». В этот момент мне не нужно правильно формулировать задачу или понимать, куда она относится. Нужно только не потерять.

Для этого у меня два inbox. Основной — входящие в Todoist. Второй — «Избранное» в Telegram с отдельным ярлыком: туда попадает то, что естественно возникло прямо в Telegram. А вот inbox в почте я вообще не разбираю. Там сейчас около 6000 писем, и никакого желания героически сводить их к нулю у меня нет. Оказалось, что система вполне может работать и без ритуальной пустоты всех входящих.

Потом входящие надо превратить в задачи. Здесь я сильнее всего опираюсь на «Джедайские техники» Максима Дорофеева. У него есть важная для меня мысль: между срочным и важным мозг всегда выбирает понятное. Отсюда и образ обезьянки немедленного удовольствия: если для задачи ещё надо остановиться и сообразить, что именно делать, шанс заняться чем-нибудь попроще резко растёт.
Поэтому я стараюсь формулировать задачи «обезьянопонятно». Прочитал — и сразу понятно, как начать делать. Это удобно ещё и тем, что разделяет думание и исполнение: я думаю, когда разбираю входящие и формулирую следующий шаг, а во время работы уже не открываю мини-проект «понять, что здесь вообще надо сделать».

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

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

Рядом с inbox в GTD есть weekly review — регулярный обзор всей системы. Его я так и не научился делать. Мне тяжело встроить в жизнь рутину, которую надо стабильно выполнять раз в неделю. Поэтому обзор у меня получается скорее по необходимости: вижу, что во входящих накопилось пять-шесть пунктов или система начала расползаться, — сажусь и разбираю. Не идеально, но пока так работает.

Остаётся исполнение — и вот здесь я до сих пор в поисках. Довольно долго я размечал день блоками в Google Calendar: большая часть под основную работу, отдельные куски под чтение книги по PostgreSQL, этот канал и другие проекты. У этой схемы есть важный плюс: календарь заранее защищает время для того, что иначе легко вытеснить.

Продолжение в первом комментарии

━━━━━━━
Вся серия «Зачем быть эффективным?»:
1. Зачем вообще быть эффективным?
2. В 32 года я узнал, что неэффективен
3. Когда голова перестала справляться
4. Todoist не разрешал мне спать
5. Ты делаешь на десять. Делай на пять
6. Путь джедая мне не помог
7. 50 отжиманий за поздний отбой
8. Почему мои системы ломались одинаково
9. Сначала проблема, потом инструмент
10. Фокус — это то, чего ты не делаешь
11. 40 безответственных минут в день
12. Зачем мне сейчас быть эффективным
👉 13. Season finale: моя система неэффективности

Зачем мне сейчас быть эффективным

Когда я начинал заниматься личной эффективностью, мне казалось очевидным, зачем она нужна: чтобы быть крутым и много зарабатывать.

Примерно так это и работало. Вокруг были люди, которые успевали запустить бизнес, выполнить все задания тренинга, поддерживать пустой inbox, вести дневник успехов, ставить правильные цели и растить доход x2 каждый год. Я смотрел на них и хотел быть таким же. Нормальным, полноценным, успешным человеком, который со всем справляется. К тому же на работе постоянно говорили, что для роста надо «хорошо работать» и «лучше перформить». Личная эффективность была ключом к лучшей жизни 🔑

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

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

Как у меня сейчас
Сейчас у меня всё устроено наоборот. Сначала я сам для себя решил, что считаю важным. Я хочу хорошо делать основную работу. Хочу заниматься спортом. Хочу регулярно читать и развиваться профессионально. Хочу экспериментировать с новыми способами увеличить доход.
Это не список того, что должен делать «эффективный человек». Это мой список.

И только после этого появился вопрос личной эффективности: хорошо, а как сделать так, чтобы всё это действительно происходило?

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

Именно поэтому в этом году я снова обратился к книгам Дорофеева. Не потому, что захотел наконец правильно выполнять «Джедайские техники». Мне нужна была помощь в конкретной задаче: я выбрал несколько важных для себя направлений и хотел научиться достаточно регулярно двигать их одновременно, не развалив систему через две недели.
Поэтому на этот раз сначала была моя жизнь и мои задачи, а уже потом — Дорофеев, Todoist, маленькие шаги, отказы и всё остальное. Инструменты перестали отвечать на вопрос «правильно ли я живу?» и начали делать то, что инструменты вообще-то должны делать: помогать мне получать нужный результат.

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

Личная эффективность для меня сейчас — не искусство делать больше. Это способность не потерять важное среди всего остального.

На этом основная история заканчивается.
Но остался бонус-трек: после всех календарей, GTD, Todoist, SMART, отжиманий, кайдзена и двух заходов на Дорофеева мне интересно рассказать, как моя система устроена сейчас.

━━━━━━━
Вся серия «Зачем быть эффективным?»:
1. Зачем вообще быть эффективным?
2. В 32 года я узнал, что неэффективен
3. Когда голова перестала справляться
4. Todoist не разрешал мне спать
5. Ты делаешь на десять. Делай на пять
6. Путь джедая мне не помог
7. 50 отжиманий за поздний отбой
8. Почему мои системы ломались одинаково
9. Сначала проблема, потом инструмент
10. Фокус — это то, чего ты не делаешь
11. 40 безответственных минут в день
👉 12. Зачем мне сейчас быть эффективным
13. Season finale: моя система неэффективности

На собеседовании тоже надо делать на пять, а не на десять

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

Первая: я прикладывал усилия на 10 баллов из 10 там, где достаточно было сделать на 5. Вторая: когда система не срабатывала, я принимался чинить себя, а не систему. И вот, точно так же люди готовятся к секции System Design.

Готовятся на десять. Читают Клеппмана, читают Алекса Сю, разбирают внутренности Kafka, смотрят чужие собеседования. Читать всё это полезно, спору нет. Только на секции дают 50 минут, и за них надо успеть собрать требования, прикинуть нагрузку, описать API и данные, нарисовать схему и объяснить, чем вы заплатили за каждое решение.

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

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

Тема урока: Как пройти секцию System Design за 50 минут
Дата: 27 августа в 19:00 мск

Олег сам проходил System Design в крупнейших бигтехах, а в Авито давал эту секцию как интервьюер, то есть видел её с обеих сторон.

Плюс два года отвечал за платформу аутентификации для 150 внутренних сервисов с SLA 99.9%, от ADR и моделей данных до согласований с ИБ и выката в прод, поэтому опыт в построении систем у него есть)

Кому будет полезно:
- метите на грейд выше, а рост упёрся в System Design, с которым на работе мало сталкивались
- уже готовитесь к секции: теорию знаете, а как уложиться в отведённое время и ничего не упустить, непонятно
- уже пробовали проходить секцию и получили отказ

Что будет на уроке:
🔍разбор реальной задачи с собеседования: сервис уведомлений на 2 млн отправок в сутки
🔍что интервьюер оценивает на самом деле, и почему это обычно не то, что кажется кандидату
🔍какие вопросы задать в начале, чтобы размытая формулировка превратилась в задачу, которую реально закрыть за 50 минут
🔍расчёт нагрузки и хранения руками: 2 млн в сутки, вечерний пик х5, запас на год, и на выходе цифры, под которые дальше рисуется схема
🔍углублённые вопросы, на которых ломаются заученные решения: потери, дубли, тормозящий провайдер
🔍в конце Олег подробно расскажет про свой курс по System Design, заточенный как раз под прохождение секции

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

Урок открытый и бесплатный, ссылка на него будет в канале Олега👇

Перейти в канал с уроком

P.S. Урок уже в этот четверг, записи не будет 😉

Сорок безответственных минут в день

После прошлого поста остаётся вопрос: я оставил меньше фокусов, но как теперь системно двигать важные вещи так, чтобы они не проигрывали каждый день чему-нибудь срочному? Например, срочным и важным рабочим задачам 🤯🔥

Я сейчас читаю книгу Хиронобу Судзуки The Internals of PostgreSQL и стараюсь регулярно выделять на неё 40 минут рабочего дня. Это напрямую связано с моей работой, но почти никогда не помогает закрыть задачу, которая лежит передо мной прямо сейчас.

И довольно часто эти 40 минут ощущаются почти безответственно 🤦‍♂️ Есть конкретная рабочая задача, коллеги ждут результата, я вполне могу продолжить её делать. Но вместо этого открываю книгу и читаю про WAL, vacuum или shared buffers.

Внутри сразу включается знакомое: «Люди ждут, работа не закончена, а ты тут книжки читаешь 😡. Давай сначала сделаем всё нужное, а потом уже спокойно займёмся самообразованием». Проблема только в том, что этого «потом» почти никогда не наступает. После текущей задачи появится следующая, кто-нибудь напишет в чат. Потом что-нибудь сломается. Срочная работа отлично умеет занимать всё пространство, которое ей отдаёшь.

То же самое я недавно заметил в другой ситуации. Мне часто приходится рано вставать, чтобы отвести дочку в детский сад или на секцию. Из-за этого иногда в середине рабочего дня меня начинает сильно клонить в сон. Раньше я пытался это состояние перетерпеть. Как можно посреди рабочего дня лечь в кровать? Люди работают, задачи стоят, а я спать собрался. В итоге я сидел за компьютером уставший, с трудом собирал мысли и испытывал вину уже одновременно за две вещи: что плохо работаю и что хочется спать.

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

Обе эти истории для меня демонстрируют широко известный принцип — люди переоценивают краткосрочные последствия своих решений и недооценивают долгосрочные.

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

Забавно, насколько это отличается от моего отношения к эффективности несколько лет назад. В Todoist один пропущенный день казался поражением, и я мог не ложиться спать, чтобы любой ценой закрыть дневную норму. Сейчас даже если из двадцати рабочих дней книгу я почитал в шестнадцать — это отличный результат. Четыре пропуска почти ничего не значат, если практика продолжается месяцами.

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

Об этом — в следующий раз.

━━━━━━━
Вся серия «Зачем быть эффективным?»:
1. Зачем вообще быть эффективным?
2. В 32 года я узнал, что неэффективен
3. Когда голова перестала справляться
4. Todoist не разрешал мне спать
5. Ты делаешь на десять. Делай на пять
6. Путь джедая мне не помог
7. 50 отжиманий за поздний отбой
8. Почему мои системы ломались одинаково
9. Сначала проблема, потом инструмент
10. Фокус — это то, чего ты не делаешь
👉 11. 40 безответственных минут в день
12. Зачем мне сейчас быть эффективным
13. Season finale: моя система неэффективности

Фокус — это то, чего ты не делаешь

В одном из прошлых постов я рассказывал, как Максим Дорофеев на тренинге заставлял участников вычёркивать задачи из списков. Не переносить на потом и не складывать в «когда-нибудь», а просто признать: этого я делать не буду. Тогда мне это казалось одной из техник работы со списком задач. Сейчас кажется, что это едва ли не самая важная часть личной эффективности.

Причём удалять приходится не только мелкие задачи из Todoist. Только за этот год я закрыл несколько вполне нормальных вещей, каждая из которых могла бы продолжаться дальше.
1️⃣ Я вышел из предпринимательского мастермайнда, в котором провёл несколько месяцев. В какой-то момент посмотрел на время, которое туда вкладываю, и понял, что отдача этого уже не оправдывает.
2️⃣ После полутора лет ежемесячной работы я завершил работу с коучем-наставником. Не потому, что она перестала приносить пользу. Наоборот, к этому моменту основную пользу я уже получил. Продолжать просто потому, что мы давно работаем вместе, было бы странным основанием.
3️⃣ Я вышел из проекта «Выше вилки».
4️⃣ А ещё прекратил работу с личным ассистентом. Здесь ситуация была особенно забавной: вместо того чтобы ассистент экономил моё время, мне регулярно приходилось думать, чем её нагрузить. В какой-то момент стало понятно, что я обслуживаю ещё один процесс, который сам же когда-то создал.
5️⃣ В конце прошлого года примерно по той же причине я закрыл «Алгоритмический фундамент программиста». Проект много лет был важной частью моей жизни, но в какой-то момент я решил, что больше не хочу отдавать ему внимание просто потому, что уже отдал очень много.

Это всё довольно плохо сочетается с моей старой установкой «начатое надо доводить до конца». Я долго считал способность не бросать одним из своих достоинств. Но у неё есть обратная сторона: можно годами продолжать хорошее дело только потому, что оно хорошее и в него уже много вложено. Хотя на его месте давно могло появиться что-то более важное.

Забавно — когда-то мы с Пашей Филоновым сделали целый тренинг про отказы с названием «Нет». Тогда я воспринимал отказ скорее как отдельный коммуникативный навык: не соглашаться на лишнюю работу, защищать своё время, уметь сказать человеку «нет». Сейчас я бы смотрел шире. Чтобы появилось место для нескольких действительно важных направлений, недостаточно хорошо ими управлять. Нужно регулярно закрывать остальные.

И я всё ещё этому учусь. Более того, моя нынешняя система личной эффективности периодически играет со мной злую шутку. Она действительно стала лучше: я меньше забываю, лучше понимаю, что делать дальше, умею понемногу двигать несколько направлений одновременно. И в какой-то момент мозг делает вполне логичный вывод: о, теперь-то мы умеем справляться со всем этим — давай добавим ещё. Я добавляю.

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

Фокус — это не состояние, которого один раз достиг и дальше спокойно живёшь. Это регулярная работа по удалению лишнего из собственной жизни. А когда важных направлений наконец осталось немного, возникает следующая проблема: как двигать их достаточно регулярно, если каждый отдельный день постоянно предлагает заняться чем-нибудь более срочным. Об этом — в следующий раз.

━━━━━━━
Вся серия «Зачем быть эффективным?»:
1. Зачем вообще быть эффективным?
2. В 32 года я узнал, что неэффективен
3. Когда голова перестала справляться
4. Todoist не разрешал мне спать
5. Ты делаешь на десять. Делай на пять
6. Путь джедая мне не помог
7. 50 отжиманий за поздний отбой
8. Почему мои системы ломались одинаково
9. Сначала проблема, потом инструмент
👉 10. Фокус — это то, чего ты не делаешь
11. 40 безответственных минут в день
12. Зачем мне сейчас быть эффективным
13. Season finale: моя система неэффективности

Почему мои системы ломались одинаково

Подведём итоги первой части сериала о личной эффективности (начало тут).

Я довольно долго считал, что мои эксперименты с личной эффективностью проваливались по разным причинам. Календарь не выдержал рабочего аврала. В Todoist я слишком увлёкся счётчиками. Методики Дорофеева попытался применять целиком и полностью. Привычки с наказаниями просто не закрепились.

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

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

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

Последний раз я довольно ярко наступил на эти грабли в 2025 году. Я посмотрел большое видео Маргулана Сейсембаева про кайдзен-планирование. Методика обещала примерно всё, чего мне хотелось: двигать несколько проектов одновременно, меньше уставать и испытывать меньше стресса. Там были действительно полезные идеи. Например, большие проекты нужно дробить на совсем маленькие действия. Эту штуку я использую до сих пор.

Но саму систему меня хватило поддерживать примерно две недели. Каждый день предлагалось начинать с «кайдзен-часа» — целого часа планирования. И вот я сижу, раскладываю задачи, декомпозирую проекты, а внутри растёт тревога: работы полно, люди ждут результата, а я уже час занимаюсь тем, как правильно заниматься работой. Методика, которая должна была уменьшить стресс, сама стала источником стресса.

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

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

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

И забавно, что после этого я снова вернулся практически к тем же идеям Дорофеева, которые уже однажды мне «не помогли». Только на этот раз начал совсем с другого конца.

И дальше мы поговорим о том, к чему я пришёл сейчас.

━━━━━━━
Вся серия «Зачем быть эффективным?»:
1. Зачем вообще быть эффективным?
2. В 32 года я узнал, что неэффективен
3. Когда голова перестала справляться
4. Todoist не разрешал мне спать
5. Ты делаешь на десять. Делай на пять
6. Путь джедая мне не помог
7. 50 отжиманий за поздний отбой
👉 8. Почему мои системы ломались одинаково
9. Сначала проблема, потом инструмент
10. Фокус — это то, чего ты не делаешь
11. 40 безответственных минут в день
12. Зачем мне сейчас быть эффективным
13. Season finale: моя система неэффективности

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. Если я ложился позже, то должен был наказать себя отжиманиями. Причём их количество зависело от того, насколько позже я лёг. Если ложился после полуночи, по моей формуле могло набежать около пятидесяти отжиманий. Я их делал.

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

Сейчас я понимаю, что неправильно поставил диагноз. С «Алгоритмическим фундаментом» проблема была не в недостатке дисциплины, а в максимализме и желании сделать слишком много сразу. А в Яндекс.Браузере я просто не прижился и постепенно полностью демотивировался. Только пока продолжал там работать, я этого не понимал.
Никакой дополнительный нажим не мог помочь мне там преуспеть.

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

━━━━━━━
Вся серия «Зачем быть эффективным?»:
1. Зачем вообще быть эффективным?
2. В 32 года я узнал, что неэффективен
3. Когда голова перестала справляться
4. Todoist не разрешал мне спать
5. Ты делаешь на десять. Делай на пять
6. Путь джедая мне не помог
👉 7. 50 отжиманий за поздний отбой
8. Почему мои системы ломались одинаково
9. Сначала проблема, потом инструмент
10. Фокус — это то, чего ты не делаешь
11. 40 безответственных минут в день
12. Зачем мне сейчас быть эффективным
13. Season finale: моя система неэффективности

Путь джедая мне не помог

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

Но как всё это совместить? В этот момент мне попался тренинг Максима Дорофеева. Его сайт тогда назывался «Многосделал.ру» — уже из названия следовало, что именно там мне сейчас объяснят, как делать больше и наконец обрести счастье. Я пошёл.

Это был живой тренинг в Москве. Его содержание позже почти полностью легло в основу второй книги Дорофеева — «Путь джедая». На тренинге было много принципов, упражнений и инструментов для работы с задачами. Но одну сцену я запомнил особенно хорошо.

Максим заставлял участников вычёркивать дела из своих списков! Не переносить на следующую неделю. Не складывать в отдельный проект «Когда-нибудь». Не искать для них более правильное место в системе. Просто признать: вот это делать не нужно.

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

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

Та же история уже случалась со мной на «Электронном мозге». Там я пытался сразу внедрить GTD, разобрать все входящие, выгрузить всё из головы и выстроить ежедневные ритуалы.
Теперь поменялись автор, терминология и набор инструментов. Но пользователь системы (то есть я) остался прежним.

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

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

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

━━━━━━━
Вся серия «Зачем быть эффективным?»:
1. Зачем вообще быть эффективным?
2. В 32 года я узнал, что неэффективен
3. Когда голова перестала справляться
4. Todoist не разрешал мне спать
5. Ты делаешь на десять. Делай на пять
👉 6. Путь джедая мне не помог
7. 50 отжиманий за поздний отбой
8. Почему мои системы ломались одинаково
9. Сначала проблема, потом инструмент
10. Фокус — это то, чего ты не делаешь
11. 40 безответственных минут в день
12. Зачем мне сейчас быть эффективным
13. Season finale: моя система неэффективности

Ты делаешь на десять. Делай на пять

Вернёмся к сериалу про личную эффективность. В предыдущем посте про Todoist я рассказывал, как начал выполнять задачи ради галочек, а не ради результата. Теперь поговорим о слове, прочно осевшем в нашем лексиконе в последние годы - перфекционизме.

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

Однажды я подошёл к наставнику тренинга и спросил:
— Как мне успевать делать все задания? Ты же сам ругаешь нас за то, что мы выполняем не всё.

Он ответил:
— Ты делаешь на десять. А ты делай на пять.

Я вообще не понял, что он имеет в виду. 😳 Как это — сделать на пять, а не на десять? В школе и университете я был отличником. Потом так же относился к работе: если брался за задачу, старался глубоко разобраться, учесть детали и сделать как следует. Я умел либо сделать хорошо, либо не сделать. Осознанно выбрать другой уровень качества я не умел. Поэтому практически любую технику личной эффективности я превращал в очередной экзамен.

Например, одним из заданий на тренинге был дневник успехов. Каждый вечер нужно было записывать минимум десять успехов за день. Поначалу практика оказалась полезной. Я постепенно научился признавать успехом не только что-то масштаба «выпустил фичу, которую делал полгода», но и более обычные вещи: договорился с другом о встрече, прибрался на рабочем месте, закончил небольшую задачу.

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

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

Проблема была не просто в перфекционизме. У меня отсутствовал навык заранее определять, какого качества достаточно для конкретной задачи. Где действительно нужно сделать на десять? Где хватит пяти? А где полезнее вообще вычеркнуть задачу?

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

А у вас получается заранее определить, где достаточно сделать на 5 из 10?

P.S. Чтобы два раза не вставать: снова приглашаю вас 1 августа на конференцию Back to Back. В этом году C++ Zero Cost Conf проходит внутри неё, а я буду ведущим C++-трека.

Участие бесплатное, зарегистрироваться можно на сайте конференции.

━━━━━━━
Вся серия «Зачем быть эффективным?»:
1. Зачем вообще быть эффективным?
2. В 32 года я узнал, что неэффективен
3. Когда голова перестала справляться
4. Todoist не разрешал мне спать
👉 5. Ты делаешь на десять. Делай на пять
6. Путь джедая мне не помог
7. 50 отжиманий за поздний отбой
8. Почему мои системы ломались одинаково
9. Сначала проблема, потом инструмент
10. Фокус — это то, чего ты не делаешь
11. 40 безответственных минут в день
12. Зачем мне сейчас быть эффективным
13. Season finale: моя система неэффективности

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-агентами вы уже считаете обязательными?