Почему ЭКСПЕРТОВ нужно душить в зародыше? – применимо не только к разработке

Посмотрел провокационный доклад от Егора Бугаенко: https://youtu.be/1-NJc2Q5a0U?si=GFbiIig6ExH_Aye-

Основной тезис: В проекте не должно быть людей, которые накапливают все знания

Идея очень здравая, и я полностью ее поддерживаю. Люди, которые знают о проекте ВСЕ, делают его unmaintainable. Им не нужно поддерживать документацию в актуальном состоянии, они и так все помнят. Другие члены команды полагаются на ЭКСПЕРТА во всех решениях – он должен подробно объснить им что нужно делать и как. В итоге вся команда скатывается в зависимость от эксперта. А он только укрепляет свою власть за счет беспомощности других. У людей просто нет других каналов получения информации, кроме "спросить лично у эксперта". Это самораскручивающаяся спираль.

Но выводы из таких предпосылок у Егора очень смелые – запретить митинги!

Каждое решение, отраженное в проекте, должно иметь публичную мотивацию. Должен быть заведен тикет, все обсуждения – в рамках него. Не понятно, почему коллега сделал именно так? – не иди в чат – заводи Issue! Пусть пишет документацию, переделывает понятно или объясняет там! Другие люди с таким же запросом должны найти ваше обсуждение, а не дергать ЭКСПЕРТА повторно. Тогда каждая часть вашего проекта будет иметь какую-то мотивацию за собой, которую можно легко найти самостоятельно.

Это буквально то, как работает OpenSource, но тут есть свои нюансы. Это банально сложно.

Я стремлюсь развивать экспертность других членов проекта. Но я и тут косячу – развиваю их экспертность не через публичные каналы😢

Проблемы FastStream сейчас
– нет публичного таск-треккера (кроме Issue, но это немного другое)
– нет публичного родмапа
– плохой гайд по онбордингу
– часть задач проходит в обход Issue
– часть коммуникаций идет в чатах телеги вместо публичного обсуждения на гите
– нет внутренней документации модулей
– появились созвоны для развития экспертизы только тех людей, что есть на проекте сейчас

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

Такое себе оправдание, конечно... Ну и ладно, будет работать над собой и становиться лучше!

В полку AI IDE прибыло –Amazon выпустили своего конкурента Cursor https://kiro.dev/

UPD: я упустил еще одну IDE'шку https://www.trae.ai/🤯

Теперь у нас есть на выбор Cursor, Windsurf, Kiro, Trae, Codebuddy, Claude Code, Aider.

Посмотрим, как рынок поделится через год (когда у меня истечет подписки на Cursor😂). Но вовлеченность бигтехов в эту движню намекает на перспективность направления.

Например, вот тут
https://research.google/blog/ai-in-software-engineering-at-google-progress-and-the-path-ahead/

Google репортит, что уже около 50% их кодовой базы пишется AI – либо через автокомплиты (они меряют рейт принятия комплитов от AI и попадания этого кода в финальный коммит), либо полностью агентами.

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

К слову, отмазы про "у нас тут NDA и мы не дадим коду утечь" тоже больше не работают. На днях релизнули Kimi K2

https://moonshotai.github.io/Kimi-K2/

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

AI держит меня в заложниках. Теперь официально.

На выходных послушал свой любимый подкаст Podlodka – и там снова говорили про AI (гостем был @denissexy)

Но на этот раз не для написания кода, а... Черт его знает. Просто AI для всего на свете. Там и про советы в путешествиях, и AI-медицинский ассистент, и контент-мейкер, и заказывальщик БАДов. В общем, я снова вдохновился и пошел пробовать всякое.

Например, Google AI Studio. Оказалось, это действительно оч крутой инструмент. Закинул в него всю выгрузку с канала с простым запросом: "Проанализируй контент, определи стиль автора, основные темы и предложи контент-план для роста". Словил пару инсайтов, но ничего такого, чего я не знал ("продолжай писать о FastStream и продуктивности", ага).

Но с одного пункта я прям выпал

Контент-план на 5 постов

Пост 1: Практическое применение TDD (Экспертный / Программирование)

Цель: Выполнить обещание, данное в постах №53, 54, 58, и предоставить аудитории ценный практический материал.

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

Мне пора начинать писать пост про TDD, пока мой AI-ассистент не начал ставить задачки в Jira😱

UPD: часть поста сгенерирована в Google AI Studio. Попробуете угадать, какая?🌚

#AI #aistudio

Продолжаю разбирать тему продуктивности и наткнулся на классную статью, которая раскладывает "эффективность" на простую и понятную формулу.

Эффективность = Результат / Затраты

Казалось бы, очевидно. Но дьявол, как всегда, в деталях.

Что такое "Результат"?
Это не просто "сделанная задача". Это ценность и влияние, которое она принесла. Запилить фичу за час — круто. Но если этой фичей никто не воспользуется, ее ценность, а значит и ваш результат, равны нулю. Эффективность тоже.

Что такое "Затраты"?
И вот тут главный инсайт. Мы привыкли мерить затраты только временем. Но это лишь верхушка айсберга. На самом деле мы тратим:

🧠 Мыслетопливо (привет, Дорофеев!)
💪 Физические силы
🧘‍♂️ Эмоции (привет, выгорание!)
🎯 Внимание
💰 Деньги

Главная ошибка, на которой попадаются все: мы отчаянно пытаемся уменьшить знаменатель (в основном время), забывая про числитель. Мы учимся делать бесполезные вещи очень быстро, сжигая все свое мыслетопливо. Итог - выгорание и нулевой результат.

Как быть эффективным на самом деле?

1. Прокачать числитель (Результат):
- Спрашивать "Зачем?": Постоянно задавать себе вопрос, какую реальную ценность принесет эта задача. Это тот самый навык, который отличает синьора от джуна
- Бить в самое важное: Применять правило Парето. Находить те 20% действий, которые дадут 80% результата, и фокусироваться на них

2. Уменьшить знаменатель (Затраты):
- Автоматизировать рутину: Все, что можно автоматизировать, должно быть автоматизировано.
- Не делать лишнего: Самый эффективный способ сделать задачу - понять, что ее делать не нужно.
- Выгружать все из головы: Использовать внешние системы (календарь, таск-менеджер), чтобы не тратить драгоценное мыслетопливо на запоминание.

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

В общем, всячески рекомендую оригинал к прочтению: https://bryzgalova.ru/effectiveness

#продуктивность #карьера #Дорофеев

Перебирал заметки по "Джедайским техникам" и наткнулся на фразу, которая мне безумно нравится своей очевидностью:

"Почему все тянут до последнего, чтобы сделать через жопу? Если сделать через жопу сразу, то останется время все улучшить"

Это просто квинтэссенция борьбы с перфекционизмом в нашей работе.

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

А ведь можно было сделать "хоть что-то" в самый первый день. К слову, TDD так и работает. Мы идем маленькими шагами по улучшению системы от самых тупых кусков кода к космолету.

Да, это был бы неидеальный код. Возможно, с парой "тупых" решений.

Но у нас было бы главное:
- Рабочий прототип. Что-то, что можно пощупать и показать.
- Обратная связь. От коллег, от системы, от самого себя.
- Время на итерации. Целая неделя, чтобы превратить решение "через жопу" в элегантное и надежное.

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

Возможно, наш главный враг — это не технический долг, а страх создать его на время?

#программирование #продуктивность #tdd #дорофеев

Сегодня совершенно неожиданно для меня вышли сразу два видоса по FastStream!🤯

От Никиты Соболева: https://www.youtube.com/watch?v=Qf4r8xV-YNk

От Сурена: https://youtu.be/GqC29YuuuGk?si=ZPip3SZbzQU2aYB5

С каждого обязательно по просмотру и лайку! И огромное спасибо самым народным ютуберам за интерес к проекту❤️

Наконец-то снова техническая тема. Переслушивал доклад про NATS – и это натолкнуло меня на размышления, которыми хочу поделиться с вами.

Back Pressure: почему упасть иногда важнее, чем работать

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

Чтобы этого не происходило, умные системы используют механизм обратного давления (back pressure). Это не просто ограничение, это встроенный в протокол или архитектуру способ для потребителя сказать производителю: "Эй, я не успеваю, притормози!".

Это фундаментальный принцип построения отказоустойчивых систем. Давайте посмотрим на два примера.

⚡️ Back Pressure в HTTP: паттерн Circuit Breaker

В мире синхронных HTTP-запросов для обеспечения back pressure принято использовать паттерн Circuit Breaker ("Автоматический выключатель").

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

Что сделает наивный Сервис А?
Он будет долбиться в Сервис Б снова и снова, возможно, с ретраями. Если экземпляров Сервиса А много, они создадут "грозовую толпу" (thundering herd), которая окончательно добьет больной Сервис Б, не давая ему ни шанса на восстановление.

Как работает Circuit Breaker?

На самом деле это очень простой переключатель с тремя состояниями:

- Closed (Замкнут): Все хорошо, запросы свободно уходят в Сервис Б.

- Open (Разомкнут): Счетчик ошибок превысил порог (например, 5 ошибок за 10 секунд). "Пробка вылетает". В течение следующих 30 секунд Сервис А даже не пытается отправить запрос в Сервис Б, а сразу возвращает ошибку. Это и есть back pressure! Мы даем Сервису Б время на восстановление, не заваливая его запросами.

- Half-Open (Полуоткрыт): Через 30 секунд выключатель переходит в это состояние и пропускает один-два "пробных" запроса. Если они проходят успешно — цепь замыкается (Closed). Если нет — снова размыкается (Open) еще на 30 секунд.

🌊 Back Pressure в брокерах: NATS JetStream

Представьте, у вас есть сервис, который генерирует события (например, клики пользователей), и второй сервис, который их обрабатывает (считает аналитику, отправляет в БД). Продюсер может генерировать 10 000 сообщений в секунду, а консьюмер — разгребать только 1000.

Что произойдет без back pressure?
Сообщения будут копиться в очереди брокера, потребитель не будет успевать их разгребать. Отставание в обработке будет накапливаться – минуты, час, дни. В итоге вся система будет выполнять уже не актуальную работу и приносить ровно 0 пользы. А потом и память брокера переполнится – и умрет совсем все

Как решает проблему NATS JetStream?
У стримов в NATS есть две важные опции: max_msgs (`max_bytes`) и DiscardPolicy. Используя эти настройки можно добиться разного поведения, но здесь нас интересует DiscardPolicy.NEW

from faststream.nats import DiscardPolicy, JStream

stream = JStream(
    "stream",
    discard=DiscardPolicy.NEW,
    max_msgs=1000,
    # max_bytes=1024 * 1024 * 1024,
)

Когда стрим заполняется до указанного предела, продюсер при попытке сделать publish() получит ошибку. Это и есть наш back pressure!

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

🛡️ Итог

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

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

#архитектура #распределенные_системы #backend #nats #devops

НАКОНЕЦ-ТО! Этой ночью мы смогли релизнуть FastStream 0.6.0 (пока как release candidate) – https://github.com/ag2ai/faststream/releases/tag/0.6.0rc0

Это была огромная работа и мой публичный позор как разработчика, мейнтейнера, руководителя😢

Вот этот PR: https://github.com/ag2ai/faststream/pull/1779

- 23 контрибьютора приняли участие в подготовке этого релиза
- было сделано 400+ коммитов (а это еще были сквоши при мерже)
- затронуто 2000+ файлов
- больше 60 000 изменений кодлайнов
- почти ГОД работы!

Мы переписали проект изнутри практически целиком (снова). Нет ни одной строчки кода, которую мы бы не затронули. Обновили документацию, тесты, CONTRIBUTING гайд, мигрировали на новые подходы к работе с репой как локально, так и в CI... Практически удвоили тестовое покрытие фреймворка.

Изменения не должны быть такими большими. Они не должны доставляться до потребителя ТАК ДОЛГО.

За это я прошу у вас прощения🙏

Но также это большая радость и облегчение для меня – теперь мы снова разблокируем добавление новых брокеров! На очереди поддержка MQTT и SQS! А еще новая структура проекта позволит нам добавить еще больше классных и нужных фич. Постараемся делать следующие релизы гораздо быстрее (попробую уложиться в сроки до 3ех месяцев на мажор). Но пока я хотел бы взять небольшую паузу и просто выдохнуть.

До 1.0.0 осталось совсем немного вещей, которые мне хотелось бы добавить во фреймворк. Теперь ломающий изменений почти не остается.

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

А пока – я прошу вас установить

faststream==0.6.0rc0

на ваши проекты, потестить и принести много-много Issue, чтобы мы могли отполировать эту версию для стабильного релиза. Гайд по миграции написан буквально в описании релиза.

А с обновленной документацией вы можете ознакомиться тут:

https://faststream.ag2.ai/0.6/

И в догонку – сегодня подошли результаты Kaicode. FastStream занял первое место и выиграл 2k$🥳

https://www.kaicode.org/2025.html

Это конкурс Open Source проектов, где оценивается качество проекта: код, работа с Issue, CI, документация и тд.

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

Поэтому рекомендую всем подавать свои фреймворки / библиотеки / библиотечки. Даже если не выиграете, то получите ценный фидбек от опытных членов жюри.

Наверное, подам на следующий год другой свой проект https://github.com/Lancetnik/FastDepends 😂

Ребят, последние дни я вспомнил, что я – автор (и мейнтейнер) крупного фреймворка.

FastStream, если кто не в курсе🌚

(А то все про продуктивность, да разработку говорили)

Для меня это уже норма жизни, но мб кому-то интересен именно этот аспект?

Что бы вы хотели спросить у меня:

- как продвигать проект? какие каналы работают, какие - нет?
- как вырабатывать идеи?
- как много времени у меня на это уходит?
- что я с этого имею?
- какие типовые задачи я решаю в Open Source'е в течении дня? Недели? Квартала?
- как вообще выглядит планирование в OSS?
- как помогает сообщество?

В общем, накидайте вопросов в комменты – обсудим. А что-то мб выльется и в отдельный пост / статью / доклад.

У меня есть идея подготовить доклад на следующий сезон "Люди и Open Source" – про поиск пользователей, поиск контрибуторов, их (и свою) мотивацию, виды задач в OSS и всякое такое.

Но мб идея тухлая и ваши вопросики направят меня в нужную сторону.

OpenSource не помогает найти работу!

А потом тебе пишут на почту с предложением работы в зарубежном стартапе на очень вкусные цифры...

Оказывается, появилась целая платформа для HR, где мониторится топ-перформеров на гите🤯

https://algora.io/profile/Lancetnik

UPD: оказывается, там есть еще и Issue-баунти. Компании назначают вознаграждение за PR'ы. Как вам 3.500$ за MCP?

В общем, бежим коммитить!

Btw, на неделе закину историю другого человека, кто нашел работу благодаря Open Source🌚 И нет, он не мейнтейнер / топ-перформер или что-то вроде

Документация для нейронок

Вот в этом посте я уже рассуждал о том, что современные инструменты должны быть адаптированы для использования нейросетями. А сегодня я узнал, что в 2024 году вышел новый формат документации сайта `llms.txt`. Его предложил Jeremy Howard (основатель Fast.ai и бывший CEO Kaggle)

Это такой аналог sitemap.xml, но для LLMs. Он позволит нейросетевым поисковикам эффективнее взаимодействовать с вашими сайтами, а также будет посадочной страницей для MCP типа Context7.

Для меня пока что звучит сомнительно, но многие крупные игроки уже поддержали стандарт:
- Cloudflare - https://developers.cloudflare.com/llms.txt
- Anthropic - https://docs.anthropic.com/llms.txt
- Docker - https://docs.docker.com/llms.txt
- Netlify - https://docs.netlify.com/llms.txt
- Stripe - https://docs.stripe.com/llms.txt
- Pydantic - https://docs.pydantic.dev/latest/llms.txt
- многие другие

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

Поэтому я хочу добавить llms.txt для документации FastStream. А вы можете помочь мне и законтрибутить это (все детали в Issue)

– https://github.com/ag2ai/faststream/issues/2417

Кстати, в репозитории FastStream уже лежит набор правил для Cursor. Он пока сыроват, но вы также можете в него коммитить!

#AI #FastStream

Прошла ровно неделя с моего начала работы над AG2, а я уже придумал, куда там затащить FastStream🌚

Похоже, нас ждет распределенный мультигентный меш на FastStream + NATS🤯

Попробуем накидать хайповые названия в комменты?

Зачем идти в Open Source джуну?

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

На самом деле OpenSource – очень разный. Люди могут заниматься в рамках открытых проектов совсем разными задачами. И для большей части задач нужен совсем минимальный уровень экспертизы.

Хочу поделиться с вами вдохновляющей историей разработчика, который сейчас работает в команде FastAPI (вашего любимого / ненавистного фреймворка). А попал он туда очень просто – отвечал на вопросы по фреймворку на всех возможных площадках!

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

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

Времени тратил в разные периоды по-разному. Пока не было работы - часа по 4 в день, в остальное время учил что-нибудь. Когда начал работать - часов по 5-10 в неделю.

Я в основном отвечал на Stackoverflow, позже начал и на гитхаб. Брал вопрос который был интересен и начинал разбираться. Иногда сдавался. Смотрел как другие отвечают. Очень помогло пройтись по открытым пулл-реквестам с меткой BUG, часто ответом было просто 'да, это известный баг'

Даже если вы джун (или особенно), вы можете сделать очень много полезного для себя и мира в OpenSource. Работа над открытыми проектами позволит вам:

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

Последний пункт, к слову, самый важный. Это не очевидная мысль, но OpenSource – это такая же работа. А лучший способ найти работу – если тебя подтянет бывший коллега. Он уже знает, на что вы способны, как решаете проблемы, какой код пишете. Он с вами работал. Даже если работал в рамках OpenSource. Я знаю примеры, когда люди находили работу таким способом.

В общем

OpenSource – это способ зайти в IT сбоку

Не самый быстрый, не самый надежный, не самый масштабируемый. Но очень интересный😅 Так зачем биться в те же ворота, что и остальные?)

Эффективность > Продуктивность. Как перестать бежать и начать двигаться к цели

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

Когда-то я запустил серию постов по Дорофееву, где говорил о продуктивности. Но самая главная тема осталась нераскрытой – как НЕ БЫТЬ НЕЭФФЕКТИВНЫМ.

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

🏃‍♂️ Продуктивность — это про "много сделал". Это чистые действия. Можно закрыть 20 мелких багов, ответить на 50 сообщений в Slack и остаться на том же месте. Голая продуктивность — это спринт на беговой дорожке, который выжимает все соки.

🎯 Эффективность — это про "насколько я приблизился к цели". Это ЦЕЛЬ + ДЕЙСТВИЯ. Можно закрыть всего одну, но самую важную задачу, и сделать гигантский шаг вперед.

Поэтому у эффективности всего 2 простых рецепта:

1. Понять, куда ты движешься (Какая у меня цель на этот месяц/квартал?)
2. Отсечь всё, что не двигает тебя в эту сторону

Предлагаю на этой неделе провести небольшой аудит своих действий. Не глобально, а в моменте:

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

Я не говорю, что так делать не нужно. Но немного осознанности никогда не помешает...

Завтра закину полный список рецептов, которые помогли мне выбраться из выгорания и начать перформить как в лучшие годы😅

#Дорофеев #эффективность #продуктивность

Тема с "документацией для нейронок" развивается... Встречайте – AGENTS.md🤯

Это как README, только для агентов. Ну вы поняли

Примеры:
- Airflow
- Codex
- Temporal
- Pluto

Интересно, что будет следующим? mkdocs-agents, который дублирует навигацию в llms.txt?

Моя система эффективности: как я выбрался из выгорания и начал перформить

Как и обещал вчера, делюсь своим списком "рецептов", которые помогают мне быть не просто продуктивным, а именно эффективным. Это не волшебная таблетка, а система, которую я выстраивал через пробы и ошибки. И восстанавливал, когда она рухнула😢

Вся система держится на одном главном принципе, который я до сих пор в себе воспитываю:

🎯 Принцип №1: Искать 80% результата за 20% усилий.
Мой главный враг — перфекционизм. Я могу потратить кучу времени, чтобы довести задачу до 100% идеала. Но правда в том, что эти последние 20% улучшений часто не нужны никому, кроме меня. Научиться говорить себе "стоп, этого уже достаточно" — главный скилл для сохранения энергии.

А дальше — более тактические вещи, которые помогают этому принципу работать.

Генерация "мыслетоплива"
Нельзя быть эффективным на пустом баке. Поэтому сначала — заправка.

- Больше спорта. Особенно игрового (у меня это теннис), где мозг полностью переключается с работы на движение. Плюс немного ЛФК, чтобы спина не отвалилась.
- Холодный душ каждое утро. Звучит как пытка, но это лучший способ быстро "перезагрузить" систему и получить заряд бодрости на несколько часов.

Защита "мыслетоплива"
Мало генерировать энергию, нужно перестать сливать ее впустую. Это мой самый важный блок.

- "Zero Inbox" как стиль жизни. Отписался от всех рассылок, настроил фильтры. Теперь почта всегда пустая, и я трачу на нее 2 минуты в день, а не живу с вечным чувством "там что-то важное".
- Цифровая гигиена в чатах. Вышел из десятков чатов, оставил самый минимум. Не вступаю в бессмысленные дискуссии — это прямое применение принципа 80/20 к общению.
- Информационная диета. Резко сократил количество мусорного контента: фоновая музыка, "видосики" на YouTube, бесконечные сериалы. Мозг тоже устает от переваривания информации.
- Правило бойскаута для рабочего (и жилого) места. Бардак высасывает энергию. Вместо того чтобы раз в месяц делать "героическую" уборку, я просто убираю за собой по мелочи сразу. "Оставь место чище, чем оно было до тебя".

Осознанный отдых
Эффективность — это не про работу 24/7, а про качественные спринты и качественный отдых.

- ОТДЫХ ВНЕСЕН В ПЛАН. Это ключевое. Я прямо в таск-менеджер вписываю: "12:00 - 12:45 - Прогулка" или "Почитать книгу 30 минут". Это легализует отдых и убирает чувство вины.
- "Помидорки" на отдых без самобичевания. Если у меня перерыв 5 минут, я честно отдыхаю, а не думаю о работе. Раньше я тратил эти 5 минут на то, чтобы корить себя за то, что я не работаю. Глупость несусветная.

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

Продолжать тренировать мышцу "80/20". Перфекционист во мне очень силен😅 Это постоянная борьба, но она того стоит.

Теперь жду ваших историй об эффективности, чтобы стащить пару "рецептов"🌚

#эффективность #продуктивность #выгорание #карьера

Гайд по OpenSource

Как-то я совсем профукал, что у Github есть ГАЙДИЩЕ по OpenSource – https://github.com/github/opensource.guide

Там есть клевые статьи о том:
– как контрибутить
– как запустить свой OSS
– как мейнтейнерам не выгорать
– как искать пользователей

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

А еще на Github есть оч крутой список Community Standarts (прям в Insights проекта), который помогает превратить ваш репозиторий из "сделано на коленке" в "выглядит сурьезно".

В общем, мне нравится, насколько Github ориентирован на OpenSource. Надеюсь, вся эта движня с Microsoft не испортит мою любимую платформу😢

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

Кажется, AGI будет не в этом году😅

Зарубежные блогеры тоже по чуть-чуть подтягиваются и начинают освещать FastStream

Arjan включил FS в список "неизветные либы, которые вам стоит знать": https://youtu.be/F09EK4ztG34?si=zMi-wiKQhV9e_DET
Обидно, что не осветили вообще никакие фичи фреймворка. Кажется, он сам не особо вчитывался даже в README. Возможно, стоит пересмотреть README, чтобы подсвечивать все важное с первых строк.

А вот у Eduardo более вдумчивый подход – https://www.youtube.com/watch?v=_78VJCs-8DQ

Чувак пилит полноценные двухчасовые стримы, изучает все фичи, готовит примеры кода, делает слайды, разбавляет это своими примерыми и доп материалам, объясняет почему это важно и круто. Кажется, он даже в истрию "двух библиотек" залез. Но я все равно ничего не понял, т.к. стрим на португальском и перевести у меня не получилось😢 Но формат у него крутой

В общем, медленно, но верно растем. Глядишь, скоро 5к звезд наберем