Дембельский аккорд из Яндекса
3…2…1…🎬 мотор!
Ну что, я тут закрутился и пропустил, что вышел мой последний подкаст, записанный в Яндексе:
Как устроена техплатформа в IT-компаниях: опыт Яндекса
Блин, по ощущениям это было невероятно давно!
Посмотрел с удовольствием, заметил даже, как изменились мои суждения за это время, я явно стал еще более зрелым (внезапно, такое совсем не ожидал, слишком мало времени прошло).
О чем поговорили:
1.
С Ромой Елизаровым (ex руководитель разработки популярного языка Kotlin) о том, что такое тот самый Developer Experience.
-как улучшать опыт разработчика
-почему это важно для каждой крупной технической компании.
2.
С Сашей Червяковым о том, почему платформа/экосистема CRM продуктов в платформе и какую пользу она приносит.
Завидую Саше в том, что в его части платформы легко понять cost to value на каждом шаге.
И, в целом, ребята делают очень крутые штуки: активно внедряют LLM, обслуживают огромное количество запросов.
С Сашей много общались: очень крутой C-level руководитель!
3.
С Ильей Дежиным о сервисах биллинга и поиска исполнителя.
Тут, конечно, у ребят сложные математические алгоритмы, которые помагают выбрать лучшего курьера для вас и построить оптимальные маршруты.
И биллинг: что может быть важнее, чем уметь корректно считать свои расходы?)))
В общем, выпуск строго рекомендую к просмотру.
Очень крутые ребята собрались, с уникальным опытом.
🎧 Смотрите и слушайте новый эпизод на платформах:
🟢 Яндекс Музыка
🟢 VK Видео
🟢 Ютуб
Гоу опрос замутим? Я мало верю, что люди реально смотрят))))
😎 - если забрал и реально посмотришь
🦄 - если сохранил себе, но сам знаешь, что смотреть не будешь
🔥 - даже не планировал смотреть
3…2…1…🎬 мотор!
Ну что, я тут закрутился и пропустил, что вышел мой последний подкаст, записанный в Яндексе:
Как устроена техплатформа в IT-компаниях: опыт Яндекса
Блин, по ощущениям это было невероятно давно!
Посмотрел с удовольствием, заметил даже, как изменились мои суждения за это время, я явно стал еще более зрелым (внезапно, такое совсем не ожидал, слишком мало времени прошло).
О чем поговорили:
1.
С Ромой Елизаровым (ex руководитель разработки популярного языка Kotlin) о том, что такое тот самый Developer Experience.
-как улучшать опыт разработчика
-почему это важно для каждой крупной технической компании.
2.
С Сашей Червяковым о том, почему платформа/экосистема CRM продуктов в платформе и какую пользу она приносит.
Завидую Саше в том, что в его части платформы легко понять cost to value на каждом шаге.
И, в целом, ребята делают очень крутые штуки: активно внедряют LLM, обслуживают огромное количество запросов.
С Сашей много общались: очень крутой C-level руководитель!
3.
С Ильей Дежиным о сервисах биллинга и поиска исполнителя.
Тут, конечно, у ребят сложные математические алгоритмы, которые помагают выбрать лучшего курьера для вас и построить оптимальные маршруты.
И биллинг: что может быть важнее, чем уметь корректно считать свои расходы?)))
В общем, выпуск строго рекомендую к просмотру.
Очень крутые ребята собрались, с уникальным опытом.
Гоу опрос замутим? Я мало верю, что люди реально смотрят))))
😎 - если забрал и реально посмотришь
🦄 - если сохранил себе, но сам знаешь, что смотреть не будешь
🔥 - даже не планировал смотреть
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥38😎25🦄9❤7👍2
Короче, вот вам гарантированно работающий прием.
🤔Кейс
вам нужно спланировать какую-нибудь миграцию крупную: с одной платформы на другую, с одной базы на другую и прочее и прочее.
🤜Решение
Все вот эти вот: подумайте, спланируйте и прочее очень плохо работают. Практически не выявляются гэпы между новым и старым решением, технологические развилки проходят по столько по скольку. Те, кто пилят новое решение сильно оторваны от того, что реально нужно.
Те, кто отвечают за старое решение мыслят: «ой, да оно там сейчас само уляжется и будет жить как жили».
🆘А работает вот это
С 1 декабря на старом все доработки запрещаем, все новые сервисы только на новой платформе, а если требуется сделать доработку старой, то, внезапно, тоже сразу переносите на новое.
И вот тут то вы и узнаете все нужные блокеры и проблемы.
И чем раньше вы так сделаете, тем будет лучше.
🤔Кейс
вам нужно спланировать какую-нибудь миграцию крупную: с одной платформы на другую, с одной базы на другую и прочее и прочее.
🤜Решение
Все вот эти вот: подумайте, спланируйте и прочее очень плохо работают. Практически не выявляются гэпы между новым и старым решением, технологические развилки проходят по столько по скольку. Те, кто пилят новое решение сильно оторваны от того, что реально нужно.
Те, кто отвечают за старое решение мыслят: «ой, да оно там сейчас само уляжется и будет жить как жили».
🆘А работает вот это
С 1 декабря на старом все доработки запрещаем, все новые сервисы только на новой платформе, а если требуется сделать доработку старой, то, внезапно, тоже сразу переносите на новое.
И вот тут то вы и узнаете все нужные блокеры и проблемы.
И чем раньше вы так сделаете, тем будет лучше.
💯51🔥16❤8😁2👎1
6 причин, почему вам, возможно, не нужен SRE-отдел
(и да, это нормально)
SRE - близкая и любимая мной тема. Если помните, то карьеру свою я начинал с того, что занимался надежностью платформы Сбербанк онлайн.
И я считаю SRE практики супер важными, но нужными далеко не всем компаниям. И да, вам, с вероятностью 90% они не нужны.
Не верите мне?
А что если один из авторов этой книжки напишет, что вам этот SRE нафиг не нужен?😉
1. Вы не Google - даже не Google 2004
У Google в 2004 было две сверх способности:
Нерешаемые проблемы. Никто не строил кластеры на сотни тысяч машин, никто не мониторил такие объемы, не деплоил такие нагрузки. Prometheus? Docker? Terraform? Их еще даже не было в скетчбуках.
Безлимитный бюджет. Можно было строить всё своё - от дата-центров до шедулеров.
Мы с вами живем в другой реальности. Хотите глобально-консистентную, шардированную базу? Платите и получаете. Хотите балансировщик уровня Google? Покупаете. Хотите CI/CD с автоскейлом? Берете SaaS.
И главный вывод:
👉🏼 Оценка «нужен ли SRE» должна быть вашей, а не импортированной из книжки
Если вам предлагают завести SRE «потому что так делают большие», бегите. Это не стратегия, это карго-культ.
2. Вы не так уж сильно цените надежность
Все компании любят говорить, что reliability - это важно.
Но реально ли?
Если ваш CEO не готов жертвовать фичами ради надежности - как это делали в Google - то говорить про «культуру SRE» бессмысленно.
Спросите себя честно:
Нужно ли вам 99.99% аптайма или и 5 минут падений раз в месяц никто и не заметит?
Что стоит выше: новый фичерелиз или инвестиции в Error Budget?
С вероятностью 90% вы выберите фичи.
SRE-команда лишь создаст краси́вую иллюзию контроля.
3. Вы сами не знаете, чем будет заниматься SRE
Самая частая причина провала SRE-инициатив - туманность мандата.
Формулировка «SRE отвечает за надежность» - это то же самое, что сказать «DevX отвечает за счастье разработчиков». Вроде звучит, но вообще непонятно, что делать руками.
Если вы не можете за 2 предложения описать:
что именно SRE делает;
где проходит граница «девы делают это, SRE делает то»;
что SRE не делает при любых обстоятельствах, то команда обречена стать помойкой для всего неудобного.
4. Вы хотите спрятать неудобные истины
SRE часто создают как костыль под культуру, а не под инженерные задачи.
Потому что главный неудобный факт звучит так:
👉🏼 Ответственность за надежность лежит на продуктовых командах. Всегда.
Но гораздо приятнее нанять «команду взрослых», чтобы они:
починили ваши алерты,
писали ваши runbook’и,
закрывали ваши пробелы в инженерной культуре,
принимали огонь за ваши архитектурные компромиссы.
SRE превращается в «группу спасателей», а продуктовые команды в пассажиров.
Это не модель Google.
Это модель «спрятать технический долг под ковер».
5. SRE может стать идеальным оправданием бездействия
Есть в индустрии комичная схема:
«Пусть SRE сделают платформу надежной… когда-нибудь… мы потом…»
Это идеальный рецепт нескончаемого технического долга.
SRE-команда очень быстро превращается в:
место, куда «сливают» задачи без дедлайна,
группу, которую обвиняют в любом падении,
удобный аргумент, чтобы не менять процессы в продуктовых командах.
А затем наступает финальный твист:
Если бы SRE не было, то нельзя было бы на них сваливать ответственность.
Но они есть и значит, можно.
6. Вы просто испугались большого падения
Самая честная причина появления SRE в компаниях:
🔥 произошла просадка, все перепугались, бросили деньги в сторону „надежности“.
появляется SRE,
нанимаются люди,
им дают туманный мандат,
им не дают полномочий,
через год спрашивают: «А почему у нас все еще проблемы?»
Потому что SRE-команда - это не операция "пожар потушили".
Это культурный слой, который нужно выращивать. А не покупать.
Что точно не работает:
❌ копировать Google 2004 года в условиях 2025.
❌ заводить SRE, чтобы кто-то другой решал ваши проблемы.
❌ делать SRE заглушкой для незрелости.
Мы живем в мире, где надежность покупается, CI/CD не пишется руками.
А вы знали про SRE?
😎 - я и есть SRE
🔥 - у нас 99.99 и команды сами это драйвят
❤️ - чувак, нам вот не до надежности!
(и да, это нормально)
SRE - близкая и любимая мной тема. Если помните, то карьеру свою я начинал с того, что занимался надежностью платформы Сбербанк онлайн.
И я считаю SRE практики супер важными, но нужными далеко не всем компаниям. И да, вам, с вероятностью 90% они не нужны.
Не верите мне?
А что если один из авторов этой книжки напишет, что вам этот SRE нафиг не нужен?😉
1. Вы не Google - даже не Google 2004
У Google в 2004 было две сверх способности:
Нерешаемые проблемы. Никто не строил кластеры на сотни тысяч машин, никто не мониторил такие объемы, не деплоил такие нагрузки. Prometheus? Docker? Terraform? Их еще даже не было в скетчбуках.
Безлимитный бюджет. Можно было строить всё своё - от дата-центров до шедулеров.
Мы с вами живем в другой реальности. Хотите глобально-консистентную, шардированную базу? Платите и получаете. Хотите балансировщик уровня Google? Покупаете. Хотите CI/CD с автоскейлом? Берете SaaS.
И главный вывод:
👉🏼 Оценка «нужен ли SRE» должна быть вашей, а не импортированной из книжки
Если вам предлагают завести SRE «потому что так делают большие», бегите. Это не стратегия, это карго-культ.
2. Вы не так уж сильно цените надежность
Все компании любят говорить, что reliability - это важно.
Но реально ли?
Если ваш CEO не готов жертвовать фичами ради надежности - как это делали в Google - то говорить про «культуру SRE» бессмысленно.
Спросите себя честно:
Нужно ли вам 99.99% аптайма или и 5 минут падений раз в месяц никто и не заметит?
Что стоит выше: новый фичерелиз или инвестиции в Error Budget?
С вероятностью 90% вы выберите фичи.
SRE-команда лишь создаст краси́вую иллюзию контроля.
3. Вы сами не знаете, чем будет заниматься SRE
Самая частая причина провала SRE-инициатив - туманность мандата.
Формулировка «SRE отвечает за надежность» - это то же самое, что сказать «DevX отвечает за счастье разработчиков». Вроде звучит, но вообще непонятно, что делать руками.
Если вы не можете за 2 предложения описать:
что именно SRE делает;
где проходит граница «девы делают это, SRE делает то»;
что SRE не делает при любых обстоятельствах, то команда обречена стать помойкой для всего неудобного.
4. Вы хотите спрятать неудобные истины
SRE часто создают как костыль под культуру, а не под инженерные задачи.
Потому что главный неудобный факт звучит так:
👉🏼 Ответственность за надежность лежит на продуктовых командах. Всегда.
Но гораздо приятнее нанять «команду взрослых», чтобы они:
починили ваши алерты,
писали ваши runbook’и,
закрывали ваши пробелы в инженерной культуре,
принимали огонь за ваши архитектурные компромиссы.
SRE превращается в «группу спасателей», а продуктовые команды в пассажиров.
Это не модель Google.
Это модель «спрятать технический долг под ковер».
5. SRE может стать идеальным оправданием бездействия
Есть в индустрии комичная схема:
«Пусть SRE сделают платформу надежной… когда-нибудь… мы потом…»
Это идеальный рецепт нескончаемого технического долга.
SRE-команда очень быстро превращается в:
место, куда «сливают» задачи без дедлайна,
группу, которую обвиняют в любом падении,
удобный аргумент, чтобы не менять процессы в продуктовых командах.
А затем наступает финальный твист:
Если бы SRE не было, то нельзя было бы на них сваливать ответственность.
Но они есть и значит, можно.
6. Вы просто испугались большого падения
Самая честная причина появления SRE в компаниях:
🔥 произошла просадка, все перепугались, бросили деньги в сторону „надежности“.
появляется SRE,
нанимаются люди,
им дают туманный мандат,
им не дают полномочий,
через год спрашивают: «А почему у нас все еще проблемы?»
Потому что SRE-команда - это не операция "пожар потушили".
Это культурный слой, который нужно выращивать. А не покупать.
Что точно не работает:
❌ копировать Google 2004 года в условиях 2025.
❌ заводить SRE, чтобы кто-то другой решал ваши проблемы.
❌ делать SRE заглушкой для незрелости.
Мы живем в мире, где надежность покупается, CI/CD не пишется руками.
А вы знали про SRE?
😎 - я и есть SRE
🔥 - у нас 99.99 и команды сами это драйвят
❤️ - чувак, нам вот не до надежности!
❤45🔥15👍9😎9🤔3❤🔥2
Разработчики теряют 2–3 часа в день только из-за переключения контекста
Продолжая тему СДВГ 🤣🤣🤣
Есть вещи, которые мы легко замечаем и понимаем их влияние на скорость разработки:
прод лежит, CI умер, релиз горит, все бегают.
А есть то, что делает то же самое, но тихо.
Медленно.
Незаметно.
И это контекстные переключения.
Вот эти:
«А глянь плз»,
«У тебя минутка?»,
«Привет, а что по той задаче?»,
«Скинь ссылку»,
«Проверишь PR?»
и, конечно, вечное: Tg → Jira → IDE → CI → документация → обратно Tg.
По отдельности все это мелочи жизни. А потом ррраз и нет недели.
🤯 Почему одно переключение это не “минутка”, а 10–30 минут возвращения в контекст ?
Статья шикарно подчеркивает простую мысль:
👉 Чтобы вернуться в поток, мозгу нужно заново собрать весь контекст.
Не просто «вернуться к работе». А вспомнить всю модель задачи:
данные, зависимости, состояние, код, ограничения.
Каждый пинг = выкинули всю эту модель в мусорку.
Снова загрузка.
Снова компиляция в голове.
Снова попытка понять «а что я вообще делал?».
Если разработчик в день переключается десятки раз, он работает не в «процессе разработки», а в «процессе возвращения к работе».
И мы такие сидим на демо:
- А почему так долго фича делалась?
- Ну… сложная… много нюансов…
Нет, ребята.
Просто нас дергали 40 раз, и мы 35 раз «загружали контекст» с нуля.
Сложная фича тут вообще ни при чем.
🔥 Где скрыт основной ад?
Статья выделяет самые токсичные места и я прям подпишусь каждым.
1) Tg, как фабрика отвлечения!
Каждое сообщение звучит как "супер пупер важно".
Но реальность - 70% можно было не писать.
2) Jira как генератор лишних прыжков
Прыгаешь туда не за реальной пользой, а чтобы обновить статус «для кого-то».
3) Code Review, которое не асинхронное
«А посмотри прям щас» - лучший способ убить поток.
4) Фрагментированная экосистема
Система не помогает, а создаёт ещё один набор кнопок, которые надо помнить.
5) Микротаски, которые выглядят безобидно
Но если задача меньше одного переключения, то она уже убыточна.
🧠 А теперь важное: мозг разработчика работает как CPU
Переключение контекста = context switch
Каждая вкладка - новый процесс
Каждое уведомление - interrupt
Каждый звонок - non-maskable interrupt
И пока CPU загружается, фреймворк в голове крутит idle.
Какой уж тут DevEx.
🏗️ Что реально нужно делать компаниям (но почти никто не делает)
И вот где статья прям бьёт точно в точку:
1. Убрать мультиканальность
Один канал поддержки.
Один SLA.
Один источник правды.
2. Делать платформу не «набором сервисов», а единым пространством работы
Не «идите в этот UI».
А «вы там живёте».
Пока нет единой точки входа переключения будут расти как плесень.
3. Закрыть рутину автоматизацией
Автогенерация конфигов, автозапуск окружений, автофиксы, autoPR — всё, что убирает “мелочи, на которые жалко внимание”.
4. Проектировать CJM, которые не ломают поток
Любая дыра в CJM - это прямой билет в Tg.
Tg = контекстное самоубийство.
5. Давать инженерам длинные непрерывные слоты
Хочешь velocity?
Давай тишину и uninterrupted time.
🎯 Итог, который нужно написать крупным шрифтом в офисе
Самая дорогая вещь в разработке не compute и не storage.
Самая дорогая вещь - это внимание инженеров.
И пока его продолжают дробить на осколки, никакие SLO, DevOps практики и LLM-ассистенты не поднимут скорость.
Продолжая тему СДВГ 🤣🤣🤣
Есть вещи, которые мы легко замечаем и понимаем их влияние на скорость разработки:
прод лежит, CI умер, релиз горит, все бегают.
А есть то, что делает то же самое, но тихо.
Медленно.
Незаметно.
И это контекстные переключения.
Вот эти:
«А глянь плз»,
«У тебя минутка?»,
«Привет, а что по той задаче?»,
«Скинь ссылку»,
«Проверишь PR?»
и, конечно, вечное: Tg → Jira → IDE → CI → документация → обратно Tg.
По отдельности все это мелочи жизни. А потом ррраз и нет недели.
🤯 Почему одно переключение это не “минутка”, а 10–30 минут возвращения в контекст ?
Так, читатель, перестань отвлекаться и вернись сюда
Статья шикарно подчеркивает простую мысль:
👉 Чтобы вернуться в поток, мозгу нужно заново собрать весь контекст.
Не просто «вернуться к работе». А вспомнить всю модель задачи:
данные, зависимости, состояние, код, ограничения.
Каждый пинг = выкинули всю эту модель в мусорку.
Снова загрузка.
Снова компиляция в голове.
Снова попытка понять «а что я вообще делал?».
Если разработчик в день переключается десятки раз, он работает не в «процессе разработки», а в «процессе возвращения к работе».
И мы такие сидим на демо:
- А почему так долго фича делалась?
- Ну… сложная… много нюансов…
Нет, ребята.
Просто нас дергали 40 раз, и мы 35 раз «загружали контекст» с нуля.
Сложная фича тут вообще ни при чем.
🔥 Где скрыт основной ад?
Статья выделяет самые токсичные места и я прям подпишусь каждым.
1) Tg, как фабрика отвлечения!
Каждое сообщение звучит как "супер пупер важно".
Но реальность - 70% можно было не писать.
2) Jira как генератор лишних прыжков
Прыгаешь туда не за реальной пользой, а чтобы обновить статус «для кого-то».
3) Code Review, которое не асинхронное
«А посмотри прям щас» - лучший способ убить поток.
4) Фрагментированная экосистема
Система не помогает, а создаёт ещё один набор кнопок, которые надо помнить.
5) Микротаски, которые выглядят безобидно
Но если задача меньше одного переключения, то она уже убыточна.
🧠 А теперь важное: мозг разработчика работает как CPU
Переключение контекста = context switch
Каждая вкладка - новый процесс
Каждое уведомление - interrupt
Каждый звонок - non-maskable interrupt
И пока CPU загружается, фреймворк в голове крутит idle.
Какой уж тут DevEx.
🏗️ Что реально нужно делать компаниям (но почти никто не делает)
И вот где статья прям бьёт точно в точку:
1. Убрать мультиканальность
Один канал поддержки.
Один SLA.
Один источник правды.
2. Делать платформу не «набором сервисов», а единым пространством работы
Не «идите в этот UI».
А «вы там живёте».
Пока нет единой точки входа переключения будут расти как плесень.
3. Закрыть рутину автоматизацией
Автогенерация конфигов, автозапуск окружений, автофиксы, autoPR — всё, что убирает “мелочи, на которые жалко внимание”.
4. Проектировать CJM, которые не ломают поток
Любая дыра в CJM - это прямой билет в Tg.
Tg = контекстное самоубийство.
5. Давать инженерам длинные непрерывные слоты
Хочешь velocity?
Давай тишину и uninterrupted time.
🎯 Итог, который нужно написать крупным шрифтом в офисе
Самая дорогая вещь в разработке не compute и не storage.
Самая дорогая вещь - это внимание инженеров.
И пока его продолжают дробить на осколки, никакие SLO, DevOps практики и LLM-ассистенты не поднимут скорость.
Средняя продолжительность рабочего дня:
8 часов (480 минут)
Прерывания в день: ~155 прерываний
Время восстановления после прерывания: 23 минуты
Конечно, прерывания не накладываются друг на друга идеально (некоторые происходят до того, как вы полностью восстановитесь после предыдущего), но даже по самым скромным оценкам разработчики теряют 2–3 часа в день только из-за переключения контекста.
4💯49👏14🤔11❤7🔥5
#пятничное
🔥 - демпинговал и продолжу демпинговать
🐳 - продалбывался и продолжу
❤️ - давайте уже это, после праздников разберетесь!
🔥 - демпинговал и продолжу демпинговать
🐳 - продалбывался и продолжу
❤️ - давайте уже это, после праздников разберетесь!
❤134🔥69🐳23
Проблемы всех стратегий
Рисую я тут стратегию и хочу поделиться одной мыслью
Проблема всех стратегий в том, что их готовят оптимисты, а значит, они не реалистичны по своей природе.
Почему оптимисты?
Потому что менеджеры по природе своей такие.
Что делать, если вы хотите реалистичную стратегию?
Пусть ее пишут пессимисты!
А вы к кому себя относите?
😎 - я оптимист
👍 - я реалист
🔥 - я пессимист
Рисую я тут стратегию и хочу поделиться одной мыслью
Проблема всех стратегий в том, что их готовят оптимисты, а значит, они не реалистичны по своей природе.
Почему оптимисты?
Потому что менеджеры по природе своей такие.
Что делать, если вы хотите реалистичную стратегию?
Пусть ее пишут пессимисты!
Но хотите ли вы такую?
А вы к кому себя относите?
😎 - я оптимист
👍 - я реалист
🔥 - я пессимист
😎79👍67🔥51🫡4❤1🥴1
Одно из лучших решений, которые срабатывают второй раз - поставить открытый книжный шкаф на видном месте.
Мы это делали с Демычем - пацан, просто, невероятно обожает читать.
А вот и Тея - регулярно лазит в книжный шкаф себе что-то выбрать.
Правда, на данном фото она «ищет папе книгу побольше»😁
Мы это делали с Демычем - пацан, просто, невероятно обожает читать.
А вот и Тея - регулярно лазит в книжный шкаф себе что-то выбрать.
Правда, на данном фото она «ищет папе книгу побольше»😁
🔥44❤27👍4💯3👎1
AI и 100 тыс. разработчиков в исследованиях от Егора Денисова
Это исследование противоположно тому, что сделали в METR: тут наблюдали 100 тыс. разработчиков из 600 компаний.
Че по результатам?
AI действительно помогает, но не так, как нам обещали в промо-роликах. Средние +15–20% - это не революция. Всё упирается в зрелость кода, тип задач и размер вашей кодовой помойки.
Откуда я это все взял?
Посмотрел 20-минутное выступление Егора Денисова-Бланша из Stanford - и это, пожалуй, один из самых аккуратных, честных и приземлённых разборов реальной продуктивности инженеров под воздействием LLM.
1. Почему все предыдущие замеры продуктивности - так себе авантюра?
Потому что:
1) Исследования финансируют сами вендоры.
OpenAI и прочие ребята очень стараются показать, что вырастили «+как минимум 2x productivity». Но выборка перекошена, метрики подкрашены - всё как обычно.
2) Коммиты и PR - плохая метрика.
Бум output, но линия качества - вниз.
Можно удвоить количество строк кода, не трогая полезность ни на йоту.
3) Greenfield-эффект.
На игрушечных проектах LLM выглядит богом.
А в реальной компании 90% задач - это старый код, грязь, зависимости и боль. Ну и куча требований безопасности, надежности.
4) Опросы?
«Кажется, я стал продуктивнее» ≠ «стал».
Самооценка - круто для well-being, но не для метрик.
2. Как Стэнфорд это мерил?
1) Подключили настоящие git-репы компаний.
Не игрушки, а живой корпоративный код.
Контекст команд - сохранён.
2) Собрали пул архитекторов и заставили их руками ставить оценки.
10–15 экспертов на качество, сложность, поддерживаемость.
И оценки очень хорошо коррелировали - то есть разметка надёжная.
3) Натренировали ML-модель, чтобы она воспроизводила экспертную оценку.
С высокой корреляцией.
То есть дальше можно масштабировать без сумасшедшей стоимости ревью.
4) Классифицировали типы изменений:
- добавление фичи
- удаление
- рефакторинг
- rework (переделка свежего кода) ← важный индикатор «кажется, ИИ ошибся, давайте исправим».
5) Прогнали всё ретроспективно за 2019–2025.
От COVID до появления LLM - чёткое сравнение «до» и «после».
3. Что показало исследование? Здесь многие ахнут
1) Сырой прирост кода: +30–40%.
Но туда же входит и мусор.
2) Реальная продуктивность: +15–20%.
После вычета багфиксов и rework.
И это среднее - иногда намного хуже.
3) На сложных задачах: почти ноль.
И огромная дисперсия.
Иногда AI даже замедляет.
4) Картинка в начаое поста хорошо иллюстрирует это: сложность × зрелость проекта
5) Язык имеет значение.
Популярные - выиграли.
Эзотерика - страдает, потому что моделей просто не на чем было учить.
6) Размер репозитория работает против вас.
Рост выгоды падает логарифмически.
Причины: шум, coupling, ограничения контекста.
Чем больше кодовая база - тем хуже LLM понимает, «что тут вообще происходит».
4. Че делать то, со всем этим?
1) Определите сложность типовых задач и зрелость своего проекта.
Если у вас legacy-монолит - чудес не будет.
2) Используйте популярные технологии.
LLM по ним лучше обучены → подсказки лучше.
3) На больших старых системах начинайте с пилота.
Маленький модуль, короткий эксперимент.
«Из коробки» Cursor или Copilot может не давать прироста.
4) Следите за долей rework.
Если вдруг резко вырос объём кода - это не рост продуктивности, а рост переделок.
5) Комбинируйте количественные сигналы git с качественным ревью.
Не сводите всё к «команда довольна/недовольна».
А вот тут по ссылочке можно найти презу.
А у вас в компании как с AI в разработке?
🔥 - активные эксперименты и уже многое в проде
🦄 - пробуем тестируем, но не активно и не верим
💊 - мы явно на другом уровне
Это исследование противоположно тому, что сделали в METR: тут наблюдали 100 тыс. разработчиков из 600 компаний.
Че по результатам?
AI действительно помогает, но не так, как нам обещали в промо-роликах. Средние +15–20% - это не революция. Всё упирается в зрелость кода, тип задач и размер вашей кодовой помойки.
Откуда я это все взял?
Посмотрел 20-минутное выступление Егора Денисова-Бланша из Stanford - и это, пожалуй, один из самых аккуратных, честных и приземлённых разборов реальной продуктивности инженеров под воздействием LLM.
1. Почему все предыдущие замеры продуктивности - так себе авантюра?
Потому что:
1) Исследования финансируют сами вендоры.
OpenAI и прочие ребята очень стараются показать, что вырастили «+как минимум 2x productivity». Но выборка перекошена, метрики подкрашены - всё как обычно.
Ну вы же сами работаете в корпорациях, не мне вам рассказывать)))
2) Коммиты и PR - плохая метрика.
Бум output, но линия качества - вниз.
Можно удвоить количество строк кода, не трогая полезность ни на йоту.
3) Greenfield-эффект.
На игрушечных проектах LLM выглядит богом.
А в реальной компании 90% задач - это старый код, грязь, зависимости и боль. Ну и куча требований безопасности, надежности.
4) Опросы?
«Кажется, я стал продуктивнее» ≠ «стал».
Самооценка - круто для well-being, но не для метрик.
Это ваще супер важная штука, когда регулярно занимаешься DevEx понимаешь, что есть большая разница между реальной производительностью и тем, как она ощущается. По сути, тут совпадает с ощущением многозадачности, как у менеджера: весь день делал кучу вещей, вроде, молодец, но есть ли результат?
2. Как Стэнфорд это мерил?
1) Подключили настоящие git-репы компаний.
Не игрушки, а живой корпоративный код.
Контекст команд - сохранён.
2) Собрали пул архитекторов и заставили их руками ставить оценки.
10–15 экспертов на качество, сложность, поддерживаемость.
И оценки очень хорошо коррелировали - то есть разметка надёжная.
3) Натренировали ML-модель, чтобы она воспроизводила экспертную оценку.
С высокой корреляцией.
То есть дальше можно масштабировать без сумасшедшей стоимости ревью.
4) Классифицировали типы изменений:
- добавление фичи
- удаление
- рефакторинг
- rework (переделка свежего кода) ← важный индикатор «кажется, ИИ ошибся, давайте исправим».
5) Прогнали всё ретроспективно за 2019–2025.
От COVID до появления LLM - чёткое сравнение «до» и «после».
3. Что показало исследование? Здесь многие ахнут
1) Сырой прирост кода: +30–40%.
Но туда же входит и мусор.
2) Реальная продуктивность: +15–20%.
После вычета багфиксов и rework.
И это среднее - иногда намного хуже.
3) На сложных задачах: почти ноль.
И огромная дисперсия.
Иногда AI даже замедляет.
4) Картинка в начаое поста хорошо иллюстрирует это: сложность × зрелость проекта
5) Язык имеет значение.
Популярные - выиграли.
Эзотерика - страдает, потому что моделей просто не на чем было учить.
6) Размер репозитория работает против вас.
Рост выгоды падает логарифмически.
Причины: шум, coupling, ограничения контекста.
Чем больше кодовая база - тем хуже LLM понимает, «что тут вообще происходит».
Тут ожидаемый эффект, конечно)
4. Че делать то, со всем этим?
1) Определите сложность типовых задач и зрелость своего проекта.
Если у вас legacy-монолит - чудес не будет.
2) Используйте популярные технологии.
LLM по ним лучше обучены → подсказки лучше.
3) На больших старых системах начинайте с пилота.
Маленький модуль, короткий эксперимент.
«Из коробки» Cursor или Copilot может не давать прироста.
4) Следите за долей rework.
Если вдруг резко вырос объём кода - это не рост продуктивности, а рост переделок.
Мы, кстати, часто такое обсуждаем а ребятами, потому что рост объема кода, это, конечно, скорее вред.
5) Комбинируйте количественные сигналы git с качественным ревью.
Не сводите всё к «команда довольна/недовольна».
А вот тут по ссылочке можно найти презу.
А у вас в компании как с AI в разработке?
🔥 - активные эксперименты и уже многое в проде
🦄 - пробуем тестируем, но не активно и не верим
💊 - мы явно на другом уровне
🔥20👍11🦄10💊10❤4
251114_AIECS Presentation vFinal.pdf
2.4 MB
Короче, утром познакомился с Егором из стенфорда, списались)
Ловите слайды из его доклада, про который писал утром !
Ловите слайды из его доклада, про который писал утром !
🔥12⚡2❤1👍1
Проект Аве Мария
Вот представь себе, ты проснулся в помещении, один, рядом с тобой никого, не считая компьютера и его манипуляторов, который задает тебе простой вопрос: «Как тебя зовут?», но ты совершенно ничего не помнишь!
Ты видишь оборудование вокруг, понимаешь для чего оно и можешь сделать вывод, что ты ученый.
Но зачем ты здесь и что от тебя хотят?
Заинтриговал?
А еще вот отдельный кайф, как вы будете изучать язык другой формы жизни?
Нам сложно выучить иностранный язык, но мы по крайней мере одна форма жизни с общими потребностями: еда, вода, туалет и прочее.
А что на счет совершенно иной формы жизни?
Я уже писал про похожий вопрос вот тут.
🚀 Проект Аве Мария
Если «Марсианин» (тут мой авторский обзор) - история выживания упёртого ботана на Марсе, то «Аве Мария» - история, где школьный учитель биологии внезапно становится единственным человеком, способным спасти человечество.
Но это же Вейер: значит опять будет куча науки, куча инженерного колхоза и столько шуток, что любой инженер узнает в них себя.
💥 Основная идея книги
Человечество замерзает. Солнце выдыхается.
И вот один человек - не герой, не астронавт, а школьный учитель биологии - просыпается в космосе, не помня ни задачи, ни миссии.
Но миссия простая: «Выжить. Разобраться. Решить».
🤝 Рокки - лучший тиммейт в истории sci-fi
Инопланетянин-инженер, похожий на паука, но более практичный, чем все наши продуктовые команды вместе взятые.
Ноль сарказма.
Сто процентов логики.
И бесконечное «я чинить».
Их дружба - это вообще отдельная магия.
Никаких пафосных речей.
Просто два ботана строят космическую лабораторию в условиях, где любое движение может закончиться взрывом.
🔧 Почему книга для инженеров?
Потому что каждая глава - это «инцидент» уровня критикал:
• течёт топливная линия → фиксим
• астрофаг убежал из контейнера → фиксим
• корабль сейчас умрёт → фиксим
• Рокки говорит «проблема?» → значит будет фиксить и он, и ты, и вся галактика
Это буквально учебник по поведению в критических ситуациях, только в космосе и с коньяком из метанола (ну почти).
🤣 Шутки
1) Когда Грейс понимает масштаб проблемы
«Ну окей. Я один в другой звёздной системе. Человечество вымирает. Двоих моих коллег рядом я уже не разбудил («они умерли»).
Всё нормально. Пятница же.»
Это такой уровень спокойствия, который можно развесить как плакат в любой DevOps-команде.
2) Когда он понимает, что астрофаг - идеальное топливо
«Он жрёт всё, что светится.
Звучит как я в универе, когда нашёл столовку, где раздают бесплатно.»
3) Его инженерный подход к опасности
«Это может взорваться.
Это скорее всего взорвётся.
Но если не взорвётся - будет круто.
Делаем.»
Вот представь себе, ты проснулся в помещении, один, рядом с тобой никого, не считая компьютера и его манипуляторов, который задает тебе простой вопрос: «Как тебя зовут?», но ты совершенно ничего не помнишь!
Ты видишь оборудование вокруг, понимаешь для чего оно и можешь сделать вывод, что ты ученый.
Но зачем ты здесь и что от тебя хотят?
Заинтриговал?
А еще вот отдельный кайф, как вы будете изучать язык другой формы жизни?
Нам сложно выучить иностранный язык, но мы по крайней мере одна форма жизни с общими потребностями: еда, вода, туалет и прочее.
А что на счет совершенно иной формы жизни?
Я уже писал про похожий вопрос вот тут.
🚀 Проект Аве Мария
Если «Марсианин» (тут мой авторский обзор) - история выживания упёртого ботана на Марсе, то «Аве Мария» - история, где школьный учитель биологии внезапно становится единственным человеком, способным спасти человечество.
Но это же Вейер: значит опять будет куча науки, куча инженерного колхоза и столько шуток, что любой инженер узнает в них себя.
💥 Основная идея книги
Человечество замерзает. Солнце выдыхается.
И вот один человек - не герой, не астронавт, а школьный учитель биологии - просыпается в космосе, не помня ни задачи, ни миссии.
Но миссия простая: «Выжить. Разобраться. Решить».
🤝 Рокки - лучший тиммейт в истории sci-fi
Инопланетянин-инженер, похожий на паука, но более практичный, чем все наши продуктовые команды вместе взятые.
Ноль сарказма.
Сто процентов логики.
И бесконечное «я чинить».
Их дружба - это вообще отдельная магия.
Никаких пафосных речей.
Просто два ботана строят космическую лабораторию в условиях, где любое движение может закончиться взрывом.
🔧 Почему книга для инженеров?
Потому что каждая глава - это «инцидент» уровня критикал:
• течёт топливная линия → фиксим
• астрофаг убежал из контейнера → фиксим
• корабль сейчас умрёт → фиксим
• Рокки говорит «проблема?» → значит будет фиксить и он, и ты, и вся галактика
Это буквально учебник по поведению в критических ситуациях, только в космосе и с коньяком из метанола (ну почти).
🤣 Шутки
1) Когда Грейс понимает масштаб проблемы
«Ну окей. Я один в другой звёздной системе. Человечество вымирает. Двоих моих коллег рядом я уже не разбудил («они умерли»).
Всё нормально. Пятница же.»
Это такой уровень спокойствия, который можно развесить как плакат в любой DevOps-команде.
2) Когда он понимает, что астрофаг - идеальное топливо
«Он жрёт всё, что светится.
Звучит как я в универе, когда нашёл столовку, где раздают бесплатно.»
3) Его инженерный подход к опасности
«Это может взорваться.
Это скорее всего взорвётся.
Но если не взорвётся - будет круто.
Делаем.»
❤26🔥12👍5❤🔥1
Плохой Project Артём Арюткин
Проект Аве Мария Вот представь себе, ты проснулся в помещении, один, рядом с тобой никого, не считая компьютера и его манипуляторов, который задает тебе простой вопрос: «Как тебя зовут?», но ты совершенно ничего не помнишь! Ты видишь оборудование вокруг,…
upd
Ну и как менеджеру мне доставляет отдельное удовольствие читать о том, как один человек сумел объединить все страны мира и заменджерил такой сложный проект, как: анализ причин угрозы вымирания, строительство космического корабля, поиск исполнителей, управление рисками. Отлично показано, как принимаются решения в условиях наличия единой ключевой метрики - максимизация выживания человека!
Ну и как менеджеру мне доставляет отдельное удовольствие читать о том, как один человек сумел объединить все страны мира и заменджерил такой сложный проект, как: анализ причин угрозы вымирания, строительство космического корабля, поиск исполнителей, управление рисками. Отлично показано, как принимаются решения в условиях наличия единой ключевой метрики - максимизация выживания человека!
❤13🔥10
Ну это топ песня этого года, конечно!
Еще и снежок выпал!
P.S. что ж, мне стало понято значение слова «имбовый» 🤣
Еще и снежок выпал!
P.S. что ж, мне стало понято значение слова «имбовый» 🤣
❤4😁2🤣1
Forwarded from Илюша | Голос поколения
Илюша - С новым имбовым!
Готовимся к имбовым праздникам, добавляем себе в новогодние плейлисты по ссылочке:
https://zvonko.link/Snovimimbovim
Всем майнкрафта, всем лабубу, всем горячий бабл ти!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤4
Ахахахаххаха
Че у вас там по команде?
😎 - все «белке в глаз с 1 выстрела»
🔥 - один я там все вывожу
🦄 - да риалли дрим тим прямо собралась!
#пятничное
Че у вас там по команде?
😎 - все «белке в глаз с 1 выстрела»
🔥 - один я там все вывожу
🦄 - да риалли дрим тим прямо собралась!
#пятничное
🦄66😎46😁36🔥19🤣9💯3
Пуф. Кажется, пора рассказать, что там после Яндекса произошло
Спойлер: я в Авито уже 3 месяца.
Сейчас я делаю как всегда то, что умею и от чего кайфую: строю продуктовую стратегию платформы (ну это вот всякие языковые фреймворки, observability, PAAS, DBAAS, IAAS) и превращаю её в реальность. Не презентациями, а решениями (ладно, кого я обманываю, куда уж без презентаций😁). Параллельно - растим команду технических продуктовых менеджеров. Тех самых, которые отвечают не за roadmap в Confluence, а за то, насколько тяжело инженеру проживать свой день.
Команда - топ. Мы с ребятами давно на одной волне и одинаково плохо переносим бессмысленную сложность.
План простой (хорошо делай, плохо не делай😁): - меньше шума; - меньше переключений контекста; - меньше «активности ради активности».
Почему у нас получится?
Потому что уже невероятно крутая база - одна из лучших платформ на рынке.
И потому что всей командой мы верим, что должны дать разработчику максимум времени, когда разработчик просто заходит в поток и делает то, ради чего вообще пришёл в профессию - строит классные сервисы.
И мы знаем, что созвоны, алерты, процессы, инструменты должны помогать, а не перегружать.
Что по деталям?
Ну тут уж лучше всего говорят не планы, а результаты. Так что давайте ка подождем немного.
Маленький спойлер: ключевой вопрос на который нужно ответить сегодня - «Как будет выглядеть рабочий день инженера в 2029 году».
Спойлер: я в Авито уже 3 месяца.
Сейчас я делаю как всегда то, что умею и от чего кайфую: строю продуктовую стратегию платформы (ну это вот всякие языковые фреймворки, observability, PAAS, DBAAS, IAAS) и превращаю её в реальность. Не презентациями, а решениями (ладно, кого я обманываю, куда уж без презентаций😁). Параллельно - растим команду технических продуктовых менеджеров. Тех самых, которые отвечают не за roadmap в Confluence, а за то, насколько тяжело инженеру проживать свой день.
Команда - топ. Мы с ребятами давно на одной волне и одинаково плохо переносим бессмысленную сложность.
План простой (хорошо делай, плохо не делай😁): - меньше шума; - меньше переключений контекста; - меньше «активности ради активности».
Почему у нас получится?
Потому что уже невероятно крутая база - одна из лучших платформ на рынке.
И потому что всей командой мы верим, что должны дать разработчику максимум времени, когда разработчик просто заходит в поток и делает то, ради чего вообще пришёл в профессию - строит классные сервисы.
И мы знаем, что созвоны, алерты, процессы, инструменты должны помогать, а не перегружать.
Что по деталям?
Ну тут уж лучше всего говорят не планы, а результаты. Так что давайте ка подождем немного.
Маленький спойлер: ключевой вопрос на который нужно ответить сегодня - «Как будет выглядеть рабочий день инженера в 2029 году».
❤58🔥54⚡11👍3😁1
Короче, че то я устал сегодня, так что забирайте просто мем)
❤️ - если у тебя такой же опыт
🔥 - если ты не такой и набрал сил на всю неделю
🎄 - давайте уже после праздников решим
#пятничноеневпятницу
❤️ - если у тебя такой же опыт
🔥 - если ты не такой и набрал сил на всю неделю
🎄 - давайте уже после праздников решим
#пятничноеневпятницу
❤115🎄97💯11🔥10🤝1
“Task Interruption in Software Development Projects: What Makes some Interruptions More Disruptive than Others?”
Так-с, нашел для вас исследование о влиянии прерываний и переключений задач на разработку ПО.
Что происходит, когда разработчиков прерывают?
Традиционно считается, что внешние прерывания (сообщение, митинг, запрос от менеджера) хуже влияют на продуктивность, чем когда мы сами решаем переключиться на другую задачу.
Но данные из реального мира говорят иначе.
В своей статье исследователи провели два больших анализа:
Анализ логов задач
- 4 910 записей работы 17 профессиональных разработчиков.
Опрос 132 разработчиков
- реальные практики, опыт и восприятие прерываний.
Цель - понять не просто что прерывает разработку, а что именно делает переключение задач более разрушительным.
Главные выводы
⚠️ 1. Самопрерывания (self-interruptions) хуже, чем внешние
Хотя большинство разработчиков считают внешние прерывания более деструктивными, данные показывают обратное:
🔹 самопрерывания приводят к большей потере эффективности и ухудшают последующую работу над задачей.
Это может быть из-за когнитивной нагрузки:
Мы теряем контекст,
Теряем «поток»,
Требуется больше времени на возврат к задаче.
2. Момент, когда происходит переключение важнее характеристик самой задачи
Традиционные параметры задачи приоритет, уровень сложности, стадия влияют на её прерываемость. Но контекст и обстоятельства, при которых происходит переключение, оказывают куда более сильное влияние. К ним относятся:
✔️ тип прерывания (сам/внешнее)
✔️ время дня
✔️ тип текущей и следующей задачи
✔️ контекст проекта и среды работы
Это означает:
👉 работа над задачей в спокойный час с минимальными внешними отвлекающими сигналами менее подвержена разрушительному влиянию, чем та же задача на пике отвлекающих факторов.
3. Переключения имеют когнитивную цену
Разработчики часто не возвращаются к прерванной задаче или делают это с большим «ценой»:
Контекстное переключение требует восстановления рабочей памяти,
Увеличиваются задержки и риск ошибок,
Частые переключения фрагментируют рабочий день.
Практические выводы для команд
✅ Ограничивайте самопрерывания - поощряйте завершение текущих задач прежде чем начинать новые.
✅ Разграничивайте рабочие периоды с высокой концентрацией: вводите «фокус-часы» без прерываний.
✅ Управляйте внешними раздражителями: настройте правила коммуникации (телеграмм, почта, встречи).
✅ Понимайте контекст переключения: важно не только что делаешь, но когда и в какой ситуации.
Почему это важно для инженерной эффективности?
Эта работа - вызов для нас, с точки зрения процессов продуктивности. Она показывает, что традиционные представления о продуктивности часто неверны или неполны.
Если ваша цель сократить время восстановления фокуса, уменьшить когнитивную нагрузку и повысить качество релизов, то понимание природы прерываний и умение управлять ими становится ключевым навыком современной инженерной команды.
Так-с, нашел для вас исследование о влиянии прерываний и переключений задач на разработку ПО.
Что происходит, когда разработчиков прерывают?
Традиционно считается, что внешние прерывания (сообщение, митинг, запрос от менеджера) хуже влияют на продуктивность, чем когда мы сами решаем переключиться на другую задачу.
Но данные из реального мира говорят иначе.
В своей статье исследователи провели два больших анализа:
Анализ логов задач
- 4 910 записей работы 17 профессиональных разработчиков.
Опрос 132 разработчиков
- реальные практики, опыт и восприятие прерываний.
Цель - понять не просто что прерывает разработку, а что именно делает переключение задач более разрушительным.
Главные выводы
⚠️ 1. Самопрерывания (self-interruptions) хуже, чем внешние
Хотя большинство разработчиков считают внешние прерывания более деструктивными, данные показывают обратное:
🔹 самопрерывания приводят к большей потере эффективности и ухудшают последующую работу над задачей.
Это может быть из-за когнитивной нагрузки:
Мы теряем контекст,
Теряем «поток»,
Требуется больше времени на возврат к задаче.
2. Момент, когда происходит переключение важнее характеристик самой задачи
Традиционные параметры задачи приоритет, уровень сложности, стадия влияют на её прерываемость. Но контекст и обстоятельства, при которых происходит переключение, оказывают куда более сильное влияние. К ним относятся:
✔️ тип прерывания (сам/внешнее)
✔️ время дня
✔️ тип текущей и следующей задачи
✔️ контекст проекта и среды работы
Это означает:
👉 работа над задачей в спокойный час с минимальными внешними отвлекающими сигналами менее подвержена разрушительному влиянию, чем та же задача на пике отвлекающих факторов.
3. Переключения имеют когнитивную цену
Разработчики часто не возвращаются к прерванной задаче или делают это с большим «ценой»:
Контекстное переключение требует восстановления рабочей памяти,
Увеличиваются задержки и риск ошибок,
Частые переключения фрагментируют рабочий день.
Практические выводы для команд
✅ Ограничивайте самопрерывания - поощряйте завершение текущих задач прежде чем начинать новые.
✅ Разграничивайте рабочие периоды с высокой концентрацией: вводите «фокус-часы» без прерываний.
✅ Управляйте внешними раздражителями: настройте правила коммуникации (телеграмм, почта, встречи).
✅ Понимайте контекст переключения: важно не только что делаешь, но когда и в какой ситуации.
Почему это важно для инженерной эффективности?
Эта работа - вызов для нас, с точки зрения процессов продуктивности. Она показывает, что традиционные представления о продуктивности часто неверны или неполны.
Если ваша цель сократить время восстановления фокуса, уменьшить когнитивную нагрузку и повысить качество релизов, то понимание природы прерываний и умение управлять ими становится ключевым навыком современной инженерной команды.
1❤18👍9🔥6👎2😁1
Вчера была новогодняя встреча CPO&CTO CLUB!
Люблю встречи этого клуба:
1. Дофига народа о кого можно обстучать свои идеи.
2. Много супер качественного общения в сжатом пространстве.
3. Предновогодние особенный кайф, потому что до конца нового года остался всего 1 спринт - 2 недели и, кажется, у народа начинает менеджерская мышца расслабляться, прессинг спадать и все двигается в строну рефлексии о прошедшем.
P.S. ну все, из корпоративов осталось еще 2 и Добби свободен 😁
Люблю встречи этого клуба:
1. Дофига народа о кого можно обстучать свои идеи.
2. Много супер качественного общения в сжатом пространстве.
3. Предновогодние особенный кайф, потому что до конца нового года остался всего 1 спринт - 2 недели и, кажется, у народа начинает менеджерская мышца расслабляться, прессинг спадать и все двигается в строну рефлексии о прошедшем.
P.S. ну все, из корпоративов осталось еще 2 и Добби свободен 😁
1🔥27❤10🤗5
🔥 - если ты ждешь не дождешься
❤️ - поддержать всех бедолаг
🎄 - давайте уже после нового года!
#пятничное
❤️ - поддержать всех бедолаг
🎄 - давайте уже после нового года!
#пятничное
🎄109🔥57❤38😁7💯1