В последнее время я читаю эссе Шона Гёдеке о том, что значит быть Staff+ engineer. Его статьи (в частности, Software engineering under the spotlight и It’s Not Your Codebase) абсолютно точны и кажутся до боли знакомым опытом для всех людей из «Big Tech».

Теоретически, я соответствую тем реалиям, которые он описывает: я Senior Staff engineer в Google. Тем не менее, его работы вызывают у меня тягостное чувство беспокойства. Сначала я списывал это на цинизм, однако, поразмыслив, я осознал, что проблема заключалась не в написанном Шоном, а моей интерпретации.

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

Вместо этого я пошёл по другому пути, на котором упор делается не на внимание руководства, а на систему, и где ты не винтик, а несёшь ответственность.

Мы живём в разных мирах

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

Насколько я понял из резюме Шона, в основном он работал в продуктовых командах¹, создающих продукты для внешних заказчиков. Цели бизнеса для них меняются каждый квартал, а успех измеряется в прибыли или MAU. В подобной среде совершенно разумно оптимизироваться под внимание руководства. Разработка продукта в крупной технологической компании — это процесс с большим количеством участников: вице-президенты, менеджеры по продукту, дизайнеры UX — у всех них есть своё мнение. Чтобы преуспеть, необходимо быть гибким и делать так, чтобы вы работали именно над тем, на что в данный момент обращено внимание руководства.

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

Заказчики моей команды — это тысячи разработчиков из Android, Chrome и разных подразделений Google². Конечные пользователи продуктов Google даже не подозревают о нашем существовании; мы сосредоточены на создании инструментов разработчиков для сбора метрик продукта и производительности, а также отладки проблем при помощи подробных трассировок.

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

Благодаря всему этому наша команда работает «снизу вверх»: не руководство говорит нам «вы должны делать X», а мы сами решаем, что принесёт наибольшую пользу нашим заказчикам, и работаем над созданием этих фич и инструментов. Руководство проверяет, что мы действительно решаем эти задачи, рассматривая наше влияние на команды, имеющие более близкое отношение к продуктам.

Выгода ответственности за систему

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

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

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

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

Возьмём для примера проект Bigtrace, которым я недавно руководил; он стал решением, возникшим только благодаря тому, что я изучал проблему достаточно долго для того, чтобы понять её истинную форму:

• Начало 2023 года (наблюдение): я начал замечать паттерн. Команды из Google собирали терабайты или даже петабайты данных трассировок производительности, но испытывали трудности с их обработкой. Разработчики писали нестабильные собственные конвейеры для парсинга данных и часто жаловались на то, насколько медленными и мучительными были итерации их анализа.

• Бóльшая часть 2023 года (исследования): я не сразу взялся за создание продакшен-системы. Вместо этого, я основную часть года тихонько прототипировал, параллельно работая над другими проектами. Я собрал отзывы тех же самых разработчиков, от которых поступали жалобы, и поскольку у нас уже давно устоялись связи, я узнал, какие требования к UX, задержке и производительности у них были, и разобрался, как их можно реализовать.

• Конец 2023 года — начало 2024 года (реализация): мы создали и выпустили Bigtrace — распределённый движок запросов big data для трассировок. Сегодня он обрабатывает более двух миллиардов трассировок в месяц, став важнейшей частью рабочего процесса для более чем ста разработчиков.

Если бы я последовал совету «оптимизироваться под заменяемость команд» (то есть если бы перешёл в 2023 году в новую команду, чтобы заняться новым проектом), то Bigtrace не существовало бы.

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

Сила слова «нет»

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

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

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

В последнее время основное внимание руководство уделяет ИИ. Все команды принуждают внедрять его. Нас уже много раз спрашивали: «Почему вы не интегрируете LLM в Perfetto?» Если бы главным для нас было внимание, то ответ был бы очевидным: мы бы написали обёртку для LLM, показали демо руководству и заявили бы что, реализовали принцип «AI first». Для моей карьеры это была бы лёгкая победа.

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

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

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

Альтернативная валюта: вклад

Чаще всего разработчики боятся потерять внимание руководства, потому что в этом случае их карьерный рост может застопориться. Логика такая: если я не выпускаю громкие фичи в Google I/O, и моя работа не находится в списке пяти самых актуальных нашего вице-президента, то как меня в таком случае повысят до Staff+?

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

Теневая иерархия

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

Я называю это теневой иерархией. Ваш вице-президент не обязан понимать тонкости вашего кода. Вам нужно доверие разработчиков уровня Staff+ Engineer в других критических организациях, которым требуются ваши инструменты.

Когда Senior Staff Engineer из Pixel говорит своему вице-президенту: «Мы в буквальном смысле не сможем отлаживать новый телефон Pixel без Perfetto», это заявление обладает огромным весом. Оно поднимается вверх по цепочке отчётности, пересекает уровень вице-президентов/директоров и возвращается к вашему менеджеру.

Подобная поддержка весома потому, что она техническая, а не политическая. Её сложно имитировать. Когда ты отвечаешь за критически важную систему, в твоём документе, обосновывающем повышение (promotion packet) появляются слова самых уважаемых разработчиков компании: «Наш успех стал возможным благодаря этому человеку».

Учёт полезности

Пока продуктовые команды стремятся к достижению показателей DAU или прибыли, нам важны метрики, отслеживающие состояние разработки:

• Полезность: каждый баг, устранённый благодаря нашим инструментам — это разработчик, которому мы пригодились. Это самая беспримесная мера полезности.

• Критичность: если команда Pixel использует Perfetto для отладки торможений, препятствующих выпуску телефона, или команда Chrome использует его для устранения утечки памяти, то наш вклад косвенно связан с их успехом.

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

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

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

Архетипы и управление

Архетипы Staff

Я далеко не первым заметил, что быть staff software engineer можно очень по-разному. В своей книге Staff Engineer Уилл Ларсон разбивает разработчиков Staff+ на четыре архетипа.

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

Дело не в удаче

Я уже предвижу критику: «Вам просто повезло, вы нашли свою команду. У большинства из нас такой роскоши нет».

Для применения советов из этого поста необходимо соблюдение двух условий. Во-первых, реализуемая мной стратегия требует, чтобы компания была достаточно прибыльной для поддержания долговременной инфраструктуры. Этот путь обычно отсутствует в стартапах или в только начавших свой рост компаниях, он оптимизирован под Big Tech.

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

Кроме того, по моему опыту, наша команда не особо уникальна: только в одном подразделении Android есть ещё пять таких команд⁴. Да, у них могли меняться директор или вице-президент, но фундаментальная миссия и команда разработчиков оставались стабильными.

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

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

Заключение

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

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

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

2. И этот список неполон: Perfetto опенсорсный, и нам важны внешние разработчики, но платят нам не за это. С точки зрения компании, время, потраченное на баги опенсорса, «потрачено впустую», но мы устраняем их, потому что мы верим в миссию опенсорса. Я говорил об этом в недавнем посте On Perfetto, Open Source, and Company Priorities.

3. Возможно, LLM даже не лучшее решение для внедрения ИИ в Perfetto: на мой взгляд, большую пользу здесь могли бы принести «олдскульные» методики машинного обучения наподобие нейросетей. Большая доля анализа трассировок — это просто сопоставление паттернов. Надеюсь глубже изучить эту тему в следующем году!

4. Android Kernel, Android System Health, Android Runtime, Android Camera HAL, Android Bionic