Где стафф инженеру брать идеи проектов

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

👉Идеи можно брать из сигналов, производимых обслуживаемой системой: инциденты и постмортемы на них, стоимость каких-то кусков инфраструктуры, сопутствующая стоимость вашей собственной работы, происходящая из-за каких-то проблем в DX.
👉Идеи можно брать от ваших пользователей, если вы делаете внутреннюю платформу – конечно, помня о классическом уроке из продакт-менеджмента про то, что фиче-реквесты не стоит воспринимать буквально: надо регулярно разговаривать с пользователями, интервьюировать их про проблемы, смотреть за тем, пытаются ли они решать с помощью ваших инструментов юзкейсы, для которых они и не бвли предназначены.
👉Очевидно важный источник сигналов – ваша организация: OKR, общая стратегия, проблемы, о которых регулярно вспоминает ваш менеджер, любые миграции между техническими стеками и платформами, которые имеют свойство никогда не заканчиваться.
👉Сигналы от индустрии: сравнивать ваши системы с SOTA того, что есть на рынке.

Новые выпуски тимлидских подкастов

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

Состояние нашей индустрии в 2026

Хороший срез основных трендов в разработке на сегодня:

👉Все меняется очень быстро – мы и раньше привыкли к довольно быстрому темпу смены технологий, но ничего даже близкого к текущей скорости еще не было.
👉Никто не пишет код руками (тут подтверждаю, я в последнее время интервьюировал десятки инженеров по всему миру, и руками хорошо если 5% работы делаются).
👉Большинство одновременно работает с несколькими агентами в параллель, и учатся справляться с когнитивным перегрузом из-за этого.
👉Количество PR за авторством агентов точно стало больше, чем человеческих. Это касается и всего GitHub, и ситуации в отдельных компаниях.
👉Скиллы стали стандартным используемым примитивом и внутри компаний, и в сообществе.
👉IDE очень-очень быстро умирают.
👉Довольно значимая часть агентских задач инициируются из Slack.
👉Все вокруг экспериментируют с разными видами автономных фабрик.
👉Большие миграции с одной технологии на другую занимают недели и месяцы, а не годы.
👉Токенмаксинг уходит в прошлое, все начинают следить за тратами на AI и искать пути сэкономить.
👉Проектная работа постепенно превращается в задачи на одного или максимум двух человек, но никак не на большую команду.
👉Инженерные специализации пропадают. Например, уменьшается спрос на iOS/Android/Frontend, но растет спрос на более универсальных инженеров.

Стартует новое исследование рынка тимлидов

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

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

Опрос анонимный, все результаты будут в открытом доступе где-то в середине декабря. Голосуйте, я потом обязательно сделаю разбор!

Синтетические митинги

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

👉В календаре появляется встреча на нужный слот
👉На мониторе показывается UI стандартного митинга, с голосами, обсуждающими заданную тему – от All Hands до звонка с разбором инцидентов
👉Выводите звук от встречи прямо на динамики, и никто к вам в офисе не подойдет, так как все будут уверены, что вы заняты

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

В разработке есть несколько источников удовольствия:

👉Сама идея, которую вы хотите реализовать
👉Превращение идеи в реальность
👉Ощущение ачивки, ради которой пришлось постараться
👉Чувство от хорошо сделанной работы
👉Удовольствие от процесса обучения
👉Удовлетворение от того, что вы смогли сделать что-то, что решило вашу проблему

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

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

Тимлидам тоже нужен апгрейд 🔄

VK приглашает руководителей команд разработки на VK JT TeamLead * — сразу в двух городах:

📍 Москва, 24 октября
📍 Санкт-Петербург, 28 октября

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

Лидерство раскрывается в действии. 

Выбирайте город и регистрируйтесь на VK JT TeamLead *. 

* VK Только Технологии для руководителей команд

Что беспокоит разработчиков

На прошлой неделе вышло сразу несколько интересных исследований, постепенно буду разбирать. Первое – State of Developers, от ребят, которые много лет делают исследования JS экосистемы.

👉Пять главных проблем, с которыми разработчики сталкивались за свою карьеру: плохой менеджмент, выгорание, проблемы с work/life balance, скука и боязнь потери работы.
👉Самый частый вид дискриминации – по возрасту, с ним сталкивались 13% опрошенных.
👉Ловите лайфхак – люди с должностью engineer получают в среднем на 65000$ больше, чем developers.
👉Среди рисков, связанных с AI, количество слоп-кода волнует больше людей, чем использование AI в военных целях😅
👉Самые частые проблемы со здоровьем – плохой сон, лишний вес, менталочка, больная спина и мигрень.

Как в Anthropic делают code review

Ежемесячное количество PR в Claude Code выросло с с 2500 в мае до 30000 в сентябре. Еще раз, тысяча PR в день! Конечно, код такими темпами читать они не будут. Вместо этого вот как они подходят к code review:

1️⃣Локальные проверки, которые выполняет сам агент: прогон тестов, проверка дизайна на соответствие гайдлайнам, агентское ревью для поиска багов.
2️⃣AI ревью на PR. Один агент находит проблемы, другие их перепроверяют, а самые важные уходят на аппрув человеку.
3️⃣Автоматическое security ревью, которое может заблочить PR.
4️⃣Автоматические чеки – линтеры, куча тестов, тайпчеки и все в этом духе.
5️⃣Самое интересное – risk-based человеческое ревью. Тривиальные, либо закрытые фичефлагом изменения вообще его не требуют; средний риск ревьюит один человек; высокий риск - два человека. При этом это разделение касается только списка доверенных авторов. Например, изменения людей из других команд обязательно ревьюятся человеком.
6️⃣Все эти автоматические чеки прогоняются еще раз после того, как подходит очередь слить PR в мастер. Дальше фича обычно раскатывается на аудиторию постепенно.

Если суммировать, то люди чаще всего подключаются к следующим решениям:

👉Надо ли вообще делать какую-то фичу, плюс разные решения по скоупу
👉Изменения в хай риск коде вроде биллинга
👉Архитектура, которая с большой вероятностью может быть повторена где-то еще
👉Ревью свидетельств того, что агент сделал работу – скриншоты, тесты, трейсы

Еще одна эвристика для боттлнека в code review

Продолжаем обсуждать, как справляться с однозначно выросшим количеством кода, который нужно ревьюить. Как и в примере с Claude Code, в этой статье основная идея тоже крутится вокруг того, чтобы определять подмножество PR, которые можно не ревьюить. Для этого CI автоматически помечает часть PR как small-change при выполнении следующих условий:

👉Меньше 1000 строк.
👉Автоматическое ревью не нашло проблем с высоким приоритетом.
👉Автор PR слил хотя бы 10 других изменений, затрагивающих изменяемый модуль. Если PR трогает сразу несколько модулей, проверка опыта запускается для каждого.
👉Затрагивает не больше, чем N отдельных сервисов или приложений. Во фронтовой монорепе N=1, в бэкендной N=3.
👉Не затрагивает общие библиотеки.
👉Не затрагивает файлы, прописанные в отдельном конфиге, для которых обязательно ревью от человека.

Вот с такой эвристикой 10% всех PR попадают под этот фильтр и мерджатся автоматически.

Вы просто неправильно используете фреймворк

Если вы попробовали внедрить модный подход, и у вас не получилось, то самой частой реакцией от его апологетов будет "ну вы просто использовали его неправильно". Да что уж там, я таким же был – ходил по конференциям, рассказывал, как мы в Авито прекрасно жили с OKR, а когда кто-нибудь рассказывал про свой неудачный опыт, то бросался объяснять, что он просто не разобрался, как правильно.

Проблема тут не в том, что OKR не работают или вредны. Как и в случае большинства других подходов (ну кроме холократии конечно), есть много компаний, которым такой подход к целеполаганию полезен.

Ошибка состоит в другом, и мне нравится, как автор статьи ее определяет:

I call this the “Precision Fallacy”: the belief that a more precise understanding or implementation would have worked, where the precision in question is undefined, or so intricate that it’s impossible to follow, and thus it’s an un-dis-provable excuse.

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

Должен ли руководитель делать команду счастливой

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

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

Ошибка периферийного примера

Я принес новое когнитивное искажение в вашу копилку, чтобы вы могли эффективнее отбривать своих оппонентов в спорах. Суть в следующем:

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

Несколько примеров, чтобы было понятнее:

1️⃣Мартин Лютер Кинг сидел в тюрьме, а и значит он плохой человек.
2️⃣Генетическая инженерия это евгеника, а значит неэтична.
3️⃣Дублирование одной и той же функции в двух классах нарушает DRY, а значит – говнокод, и вредит системе.

Не используйте такие аргументы, пожалуйста, и не давайте использовать другим.