Признаки того, что кодовая база вас тормозит

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

Аудит кодовой базы за несколько git команд

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

👉Посмотреть на топ самых часто изменяемых файлов. Если среди них есть те, за которые никто не хочет отвечать, это ваши точки отказа.
👉Посмотреть на коммитеров, ответственных за большую часть кода. Если кто-то один написал больше 60%, он ваш бас фактор. Другой важный сигнал – как много из изначальных авторов системы продолжают коммитить до сих пор, или ее поддерживают другие люди.
👉Какие файлы чаще всего попадают в коммиты с "bug" в названии. Хорошо сравнивать со списком файлов из первого шага.
👉Увеличивается ли количество коммитов, остается на плато или падает со временем. Периодические пики могут сигнализировать о кранчах перед релизами, а постепенный спад активности – на замедление команды и чей-то уход.
👉Насколько часто встречаются коммиты со словами "hotfix"/"revert". Это хороший прокси-показатель того, насколько много команда борется с пожарами.

Как качество агентского кода деградирует на дистанции

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

Для того, чтобы оценить качество результата, в бенчмарке смотрят на два показателя – количество лишнего или дублированного кода и нечто под названием structural erosion, что можно приблизительно представить как излишнюю сложность решения. И все довольно плохо. В 80% случаев сложность растет, в 90% случаев растет количество лишнего кода.

Что еще интересно – в коде, написанном человеком, эти метрики со временем остаются на одном уровне, а в агентском ухудшаются от итерации к итерации.

Как менеджеры пытаются показать свою власть

Многие из этих антипаттернов проявляются неосознанно, поэтому проверьте себя на всякий случай:

👉Считают себя самым умным человеком в комнате – говорят первыми, сразу бросаются в область решений, перебивают других.
👉Скрывают часть информации, либо выдавая ее порционно, либо вообще говоря разным людям разные вещи.
👉Используют страх как инструмент мотивации – угрожают последствиями, намекают на плохой перфоманс ревью или будущее команды, используют фразы вроде "да с этой задачей любой новичок справится" или "незаменимых у нас нет".
👉Забирают всю славу себе, но сваливают вину на других.
👉Постоянно говорят о том, насколько они заняты встречами, перегружены и как ценно их время, используя это как символ статуса и повод, чтобы опаздывать на встречи и продалбывать обещания.
👉Микроменеджерят под видом заботы о качестве – ревьюят каждый документ, придираются к мелочам, заставляют аппрувить любое мелкое решение.

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

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

Вот эти кластера:

👉Галера – аутсорс и студии разработки. Тут давление создается клиентами. Благодаря этому тут правит результат, все работают с большой скоростью, но с малой глубиной.
👉Машина – продуктовый бизнес и бигтех. Давление идет от пользователей и метрик. Вы винтик в большом механизме, работаете вглубь, и можете годы посвящать одному узкому домену.
👉Крепость – госуха, банки, энтерпрайз. Давление идет со стороны регламентов и безопасности. Царство стабильности, ценится предсказуемость, выживают лучшие дипломаты. Драйв становится дестабилизирующим фактором.
👉Цех – IT в непрофильной компании. Давление – внутренний заказчик. Ваша команда тут становится кост центром, и нужно оправдывать ее существование. Стабильность высокая, но технологический потолок очень низкий.
👉Стартапы. Давление идет от выживаемости. Любая роль становится человеком-оркестром, нужно принимать на себя кучу рисков, нет никаких правил. Нужно уметь отличать хаос роста от хаоса распада, в первом растет опыт, во втором энтропия.

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

Важно помнить, что смена кластера – это очень дорого. Вы теряете много накопленного поведенческого опыта, и из-за несоответствия ожиданиям можете получить даунгрейд.

Как прикинуть окупаемость вашей команды

Команда из восьми инженеров где-то в Европе стоит около 1 миллиона евро в год – иначе говоря, 90000 евро в месяц и 4000 евро в день. Ожидания по окупаемости отличаются в зависимости от типа команды.

Если это платформенная команда, которая делает какой-то внутренний продукт, то только для выхода на самоокупаемость она должна экономить другим командам минимум 1400 часов в месяц, что в компании на 100 инженеров означает экономию каждому трех часов в месяц. Но считать только самоокупаемость не очень честно – реалистичные ожидания от такой команды это 3-5 кратный выигрыш.

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

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

Работаете с облачной инфраструктурой?

Apple Hills Digital проводит исследование облачных платформ: использование, выбор, сценарии внедрения.

Сейчас — быстрый отбор участников (~3 минуты).
Анкета короткая*, далее — основной опрос и розыгрыш iPhone


* Принимая участие в опросе Вы становитесь участником розыгрыша под наименованием «Если ты работаешь в IT, пройди опрос и выиграй iPhone 17 Pro». Информация об организаторе розыгрыша, сроках проведения, правилах проведения розыгрыша, количестве призов, сроках, месте, порядке получения призов размещена по ссылке

Честный опыт написания сложного проекта с агентами

Опытный техлид из Google рассказывает, как с помощью AI агентов реализовал сложный проект, который прокрастинировал восемь лет до этого – парсер для SQLite запросов и набор девтулов поверх него.

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

Лучше всего пост подбивает вот эта цитата:

The takeaway for me is simple: AI is an incredible force multiplier for implementation, but it’s a dangerous substitute for design. It’s brilliant at giving you the right answer to a specific technical question, but it has no sense of history, taste, or how a human will actually feel using your API. If you rely on it for the “soul” of your software, you’ll just end up hitting a wall faster than you ever have before.

Как анализировать организацию работы в команде

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

1️⃣Собираем матрицу распределения работ – табличку, где по вертикали идут имена членов команды, по горизонтали – полный перечень функций и задач.
2️⃣В этой матрице отмечаем, кто какую из работ на самом деле выполняет, в том числе тип участия по RACI.
3️⃣Анализируем распределение и выполнение работ. Идем по каждой строке и проверяем, выполняется ли кем-то работа вообще, очевидно ли, кто должен ее выполнять в каждом случае, нет ли дублирования ролей, является ли количество исполнителей минимально достаточным, отвечает ли кто-то за конечный результат, согласована ли работа между всеми участниками, понятны ли критерии успеха, дает ли работа ожидаемый эффект.
4️⃣Анализируем каждый столбец: понятна ли роль участника команды, можно ли выделить и оценить его вклад в общее дело, ясны ли границы его зоны ответственности, соответствует ли нагрузка его компетенциям, соответствует ли объем работы его возможностям, и сбалансирована ли она относительно остальных коллег, нет ли избыточной зависимости от других участников, не страдает ли он от переключений контекста, отвечает ли за какой-то результат от начала до конца.

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

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

💥 22 апреля в 20:00 (мск) лаборатория навыков коммуникации Софт Скиллз Лаб проведет открытое занятие, на котором вы за 1,5 часа узнаете:

▫️ Как заранее налаживать контакт с руководителем, чтобы потом было проще просить поддержку?
▫️ Как менять динамику отношений, если сейчас они не складываются?
▫️ Как запрашивать обратную связь, чтобы лучше понимать ожидания руководителя?

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

Весь материал разберете на реальных кейсах, вы сможете отправить свою ситуацию в анонимную гугл-форму.

🗣️ Спикер — Анна Мигунова, ведущий тренер Софт Скиллз Лаб, преподаватель НИУ ВШЭ и Сколково, директор по продукту в «заря.диджитал», системный аналитик в Kaspersky.

Встреча пройдет в Zoom, поэтому вы сможете задать Анне любые вопросы.

👉🏻 Запустите бота, чтобы получить ссылку на конференцию!

Закрывшиеся стартапы продают свои внутренние данные

Обанкротившиеся стартапы начали продавать все внутренние архивы корпоративных переписок компаниям, тренирующим AI модели, и получают за это что-то вроде сотен тысяч долларов.

Так что, если вам когда-то казалось, что создавать кучу тикетов в Jira, писать статей в Notion, и переписываться в Slack – это бесполезная работа, то вы просто еще не поняли, что это новое золото!

Про будущее Figma

На прошлой неделе Anthropic выпустили Claude Design – агента, который умеет готовить дизайн с полным знанием всей дизайн-системы и конвенций в вашей кодовой базе. Акции Figma, которые и так очень сильно падали весь последний год, упали еще сильнее. В статье – хороший анализ, почему Figma вообще постепенно становится нерелевантной тому, как развивается индустрия:

👉Вся Figma построена на закрытом проприетарном формате. Его сложно интегрировать со сложной кодовой базой, он отсутствует в обучающих сетах для моделей, с ним тяжело работать программно. В то же время, с кодом наоборот становится работать все проще – поэтому баланс сил в уравнении того, где находится источник правды, начинает быстро уезжать из дизайна в код.
👉Поддержа двух источников правды и синк их друг с другом требовал огромной дополнительной сложности и ресурсов. При этом, все равно реальный продукт отличался от того, что было в Figma.
👉Решение любой тривиальной задачи по дебагу или изменению происходящего в сложном Figma-файле – довольно сложная задача. В 2026 люди хотят отдавать такое агентам, а они тут не помогут.

AI вредит нашей способности учиться

Еще одно исследование про вред, который AI оказывает на наше мышление – на этот раз про упорство, тенденцию быстро сдаваться и работать самостоятельно – ключевые качества для обучения. Что конкретно обнаружили:

👉После того, как участники эксперимента поработали над задачами с AI, они гораздо хуже работали без него – быстрее сдавались и показывали хуже результаты.
👉Самые сильные негативные эффекты проявились среди тех, кто запрашивал от AI решения конкретных задач. С теми, кто обращался просто за подсказками или объяснениями все лучше.
👉Эти эффекты повторялись вне зависимости от домена задачи – и в чтении, и в математике.

Новые выпуски менеджерских подкастов

👉"Три тимлида заходят в бар" про обучение менеджеров: как много нужно учиться, чему конкретно и какими способами.
👉Бреслав и Ложечкин: продолжение предыдущего выпуска про спецификации вообще и новый язык программирования для AI в частности.
👉КОДА КОДА про сложные переговоры: какие инструменты и практики использовать, чтобы договариваться о важных вещах

Высокоамплитудная несговорчивость

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

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

Подход к AI-native интервью

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

Держите кейс компании, которая переработала этот процесс так, чтобы он лучше отражал, как они работают на самом деле.

Основная часть – онсайт интервью. Оно состоит из следующих этапов:

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

Помимо такого очного интервью, проводятся еще два этапа. Один – стандартное system design собеседование, второй – взять готовый PR для существующей кодовой базы, подебажить его и улучшить.

Продолжим тему AI-native собеседований. В июне в Podlodka AI Engineers Club я планирую организовать стрим про то, как меняются процессы интервью в разных компаниях с учетом того, насколько сильно поменялась рабочая рутина разработчиков. Если вы в вашей компании делали с собеседованиями что-то интересное в этом направлении, отпишитесь в Google Form – я ищу еще пару участников, и буду рад позвать кого-то из подписчиков!

👉Гуглоформа тут

Как слышать других

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

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

Как нанимать людей, которые сильнее вас

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

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

В чем секрет устойчивости Selectel?

За 17 лет на рынке в Selectel научились быстро реагировать на изменения, видеть в кризисах возможности и объединять усилия команды, чтобы вместе добиваться большего.

Это подтверждают и цифры по итогам 2025 года:

✔️ 33 000 клиентов — +5 100 за год
✔️ 50+ продуктов — +9 за год
✔️ 18,3 млрд рублей выручки — +39% год к году
✔️ 1 300 сотрудников — +155 за год

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

Спойлер: собственная ИТ-инфраструктура — это, конечно, база, но секрет не только в ней 😉

В конце исследования — розыгрыш легендарных Тирексов! 🦖

Реклама. АО "Селектел". erid:2W5zFHVc2am