По мотивам 21 Lessons From 14 Years at Google

Одержимость проблемами пользователей, а не технологиями

Лучшие инженеры идут от проблемы к решению, а не наоборот.
Часто разработчики влюбляются в новый фреймворк и ищут, куда бы его “прикрутить”.
Лучше “идти вглубь”: читать тикеты поддержки, общаться с пользователями и спрашивать “почему?”, пока не докопаетесь до корня проблемы.

Советы:

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

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

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

Советы:

  • Начинайте обсуждения с согласования понимания проблемы, а не сразу переходите к решениям
  • Придерживайтесь “сильных мнений, которые легко изменить” (strong opinions, weakly held)
  • Документируйте компромиссы и критерии успеха, чтобы снизить трения на этапе выполнения

Стратегические решения, принятые коллективно, реализуются эффективнее, чем те, которые навязаны самым умным в команде.

Склонность к действию (Bias towards action)

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

Советы:

  • Устанавливайте жесткие дедлайны для первого прототипа
  • Сначала сделайте, потом сделайте правильно, потом сделайте лучше
  • Используйте инструменты быстрого прототипирования и современные технологии (AI), чтобы ускорить циклы обратной связи

Импульс создает ясность; аналитический паралич не создает ничего.

Ясность - признак зрелости.

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

Советы:

  • Используйте линтеры или проводите code review с фокусом на читаемост

Пишите код так, чтобы его понял человек, которого разбудили в 2 часа ночи для исправления бага; ясность важнее элегантности.

Новизна - это кредит, который вы возвращаете сбоями и когнитивной нагрузкой

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

Советы:

  • Создайте “бюджет инноваций” для вашей команды (например, только 1-2 новых технологии на проект)
  • Перед внедрением новой технологии составьте список “стоимостей”: обучение, поиск кадров, совместимость, поддержка
  • Проведите аудит технологического стека раз в квартал, чтобы выявить и устранить избыточное разнообразие инструментов

“Лучший инструмент для работы” часто является “наименее плохим инструментом для многих задач”, потому что поддержка “технологического зоопарка” съедает всё полезное время.

Код не защищает ваши интересы, это делают люди

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

Советы:

  • Научитесь рассказывать о вашей работе в терминах бизнес-ценности, а не технических деталей
  • Пишите краткие посты/обзоры к важным внедрениям (документируйте impact).
  • Просите коллег поддержать вас в митингах и при найме - стройте внутренний бренд.

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

Лучший код - тот, который вы никогда не писали

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

Советы:

  • Перед началом нового проекта проведите сессию “анти-проектирования”, где команда мозговым штурмом определяет, что можно не делать
  • Измеряйте успех не только по количеству написанного кода, но и по количеству удаленного

Перед тем как строить, спросите: “Что будет, если мы этого не сделаем?”; если ничего страшного - не пишите код.

В масштабе даже ваши баги обретают пользователей

Если у вас миллионы пользователей, любая особенность системы (даже баг) становится зависимостью для кого-то другого.

Советы:

  • Прежде чем исправлять “баг”, исследуйте, не зависит ли от него какой-то функционал
  • Проектируйте процесс отказа от устаревших функций как миграцию с четкими сроками и инструментами
  • Мониторьте использование неочевидных возможностей вашего API, они могут быть ключевыми для некоторых пользователей
  • Планируйте вывод старых API из эксплуатации как полноценную миграцию с обучением и инструментами

Обратная совместимость - это и есть продукт.

“Медленные” команды - это обычно несогласованные команды

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

Старшие инженеры тратят больше времени на уточнение направления, интерфейсов и приоритетов, чем на “ускорение написания кода”, потому что именно здесь находится реальное узкое место.

Сфокусируйтесь на том, что вы можете контролировать и игнорируйте то, что не можете

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

Советы:

  • Создайте “матрицу влияния”: разделите задачи на 4 квадранта - то, что вы можете контролировать и не можете, и то, что важно и не важно
  • При столкновении с неопределенностью разбивайте проблемы на части и определяйте конкретные действия, доступные вам

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

Абстракции не удаляют сложность, а переносят её

Абстракция - это ставка на то, что вам не нужно знать, как всё устроено внутри; но когда она “течет” (leaks), вам всё равно придется лезть внутрь.
Старшие инженеры продолжают изучать “низкоуровневые” вещи, даже когда стеки становятся выше; не из ностальгии, а из уважения к моменту, когда абстракция даст сбой, и вы останетесь один на один с системой в 3 часа ночи.

Советы:

  • Поддерживайте минимальное понимание нижних уровней стека.
  • В документации описывайте возможные failure modes.

Даже работая на высоких уровнях, сохраняйте понимание того, как работают нижние уровни вашей системы.

Письмо заставляет мыслить ясно

Когда я объясняю концепцию другим - в документе, презентации, комментарии к коду или просто общаясь с ИИ, я обнаруживаю пробелы в собственном понимании.
Попытка объяснить концепцию другому делает это более понятным для меня самого.

Советы:

  • После освоения новой технологии или подхода напишите краткое объяснение для коллег
  • Ведите технический блог или внутреннюю вики с заметками о том, чему вы научились
  • Используйте принцип “объяснения пятилетнему ребенку” для проверки глубины вашего понимания

Если вы думаете, что понимаете тему - попробуйте её преподать или описать просто; обучение - это дебаггинг собственных ментальных моделей.

“Склеивающая” работа (Glue work) бесценна, но невидима

Координация команд, написание документации, менторство - это “клей”, без которого всё развалится. Но если делать это незаметно, ваша карьера может забуксовать.

Советы:

  • Устанавливайте временные рамки для “клейкой” работы (например, не более 20% рабочего времени)
  • Создавайте артефакты вместо одноразовых действий: документы, шаблоны, автоматизация
  • Явно указывайте “клейкую” работу в своих достижениях, измеряйте её влияние и делитесь результатами

Бесценное и невидимое - опасное сочетание для вашей карьеры; делайте эту работу видимой и ограниченной.

Если вы выигрываете в каждом споре, вы копите сопротивление

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

Советы:

  • После “легкой победы” в дискуссии специально ищите мнения тех, кто мог скрыть свое несогласие
  • Практикуйте публичное признание ошибок и изменение позиции, когда получаете новые данные
  • Создавайте психологическую безопасность в командах, поощряя инакомыслие и уважительно относясь к возражениям

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

Когда метрика становится целью, она перестает быть хорошей метрикой

Люди всегда будут “хакать” показатели, если от них зависит их оценка.
Если вы отслеживаете количество строк кода, вы получите больше строк. Если вы отслеживаете скорость выполнения задач, вы получите раздутые оценки.

Советы:

  • На каждую метрику скорости предлагайте парную метрику качества или риска
  • Фокусируйтесь на интерпретации трендов, а не на поклонении пороговым значениям

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

Признание того, чего вы не знаете, создает больше безопасности, чем притворство, что вы знаете

Старшие инженеры, которые говорят “я не знаю”, не демонстрируют слабость - они создают разрешение; когда лидер признает неопределенность, это сигнализирует, что в комнате безопасно делать то же самое для других.
Альтернатива - культура, где все притворяются, что понимают, и проблемы остаются скрытыми, пока не взорвутся.

Советы:

  • На встречах моделируйте фразы “я не знаю, давайте проверим” или “это гипотеза”.
  • Создайте практику post-mortem без поиска виноватых.
  • Поощряйте junior-инженеров задавать вопросы публично.

Моделируйте любопытство, а не всезнание.

Ваша сеть контактов живет дольше, чем любая работа

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

Советы:

  • Относитесь к нетворкингу с искренним любопытством и щедростью, а не как к транзакционному обмену.
  • Поддерживайте отношения после смены работы - поздравляйте с достижениями, делитесь полезными ресурсами

Ваша работа не вечна, но ваш нетворкинг - да; когда придет время двигаться дальше, именно отношения часто открывают двери.

Прирост производительности чаще идет от удаления лишнего

Когда системы начинают работать медленно, первым желанием становится увеличение скорости за счёт дополнительных уровней кэширования, параллельной обработки и более сложных алгоритмов.
Но иногда стоит сначала спросите: “А нужно ли нам вообще делать это вычисление?”.

Советы:

  • Перед оптимизацией всегда задавайте вопрос “а нужно ли это вообще?”
  • Измеряйте не только скорость выполнения, но и количество операций, необходимых для достижения результата

Самый быстрый код - тот, который никогда не запускается.

Процесс нужен для снижения неопределенности, а не для бюрократии

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

Советы:

  • Для каждого процесса установите регулярный аудит с вопросом “этот процесс по-прежнему оправдан?”
  • Автоматизируйте рутинное документирование там, где это возможно
  • Начинайте с минимально необходимых процессов и добавляйте сложность только когда сталкиваетесь с конкретными проблемами

Хороший процесс делает ошибки дешевле; плохой - служит для поиска виноватых.

В конце концов время становится дороже денег

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

Советы:

  • Раз в полгода проводите “аудит времени” - сопоставляйте, как вы тратите время с вашими долгосрочными целями
  • Учитесь говорить “нет” проектам, которые не соответствуют вашим приоритетам, даже если они привлекательны для карьеры

Многие сеньоры выгорают в погоне за лишними процентами к зарплате; знайте, на что вы идете ради повышения, и делайте это осознанно.

Коротких путей нет, но есть сложный процент

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

Советы:

  • Выделяйте регулярное время для глубокого обучения
  • Документируйте уроки из неудач в формате, доступном для команды
  • Инвестируйте в навыки, которые будут иметь долгосрочную отдачу (фундаментальные концепции, а не конкретные фреймворки)

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

Комментарии в Telegram-группе!