Написание кода несложно, сложно — работать с «людьми» и «сложностью». Опытный инженер Google делится 14-летним опытом, от мышления пользователя до командной работы, эти 21 золотых правила помогут вам построить более глубокую карьеру.
(Предыстория: Официальный запуск мгновенного перевода Google для всех брендов наушников: более 70 языков, запуск в США, Мексике и Индии на Android-устройствах)
(Дополнительный фон: Google официально запускает «Gemini 3»! Вершина мировых умных ИИ-моделей, в чем особенности?)

Содержание статьи

• 1. Ведущие инженеры увлечены решением пользовательских проблем
• 2. «Доказательство своей правоты» — бесполезно, важна совместная работа для достижения правильной цели
• 3. Действуй. Запускай! Ты можешь исправлять плохие страницы, но не можешь исправлять пустую страницу
• 4. Опытность проявляется в ясности, ум — в ответственности
• 5. «Новизна» — это высокорискованный заем у ремонта, найма и когнитивной нагрузки
• 6. Код не будет за тебя говорить, люди — да
• 7. Лучший код — это тот, который ты никогда не напишешь
• 8. Когда масштаб достаточно велик, даже твои баги имеют пользователей
• 9. Большинство «медленных» команд — это на самом деле «отвлеченные» команды
• 10. Сосредоточься на том, что ты можешь контролировать, игнорируй остальное
• 11. Абстракция не устраняет сложность, она лишь переносит ее
• 12. Писательство принуждает к ясности, обучение — самый быстрый способ учиться
• 13. Сделать возможным другие работы — бесценно, но невидимо
• 14. Если ты побеждаешь каждую дискуссию, ты, возможно, накапливаешь безмолвное сопротивление
• 15. Когда индикатор превращается в цель, он перестает быть хорошим индикатором
• 16. Признание «я не знаю» создает больше безопасности, чем притворство
• 17. Твой контекст долговечнее любой работы
• 18. Большинство улучшений производительности — это «удаление работы», а не «умные алгоритмы»
• 19. Существование процессов — для уменьшения неопределенности, а не для создания документации
• 20. В конечном итоге время ценнее денег, действуй исходя из этого
• 21. Нет коротких путей, есть эффект сложных процентов

• Последняя мысль

Директор AI Google Cloud Addy Osmani — опытный разработчик и мыслитель, почти 14 лет руководил командой разработчиков Chrome, участвовал в проектах DevTools, Lighthouse и Core Web Vitals. Сейчас он координирует работу команд Google DeepMind, инженерных, продуктовых и связных с разработчиками.

3 дня назад он опубликовал в своем блоге глубокий разбор профессиональных уроков. Объединив свой многолетний опыт работы в Google и профессиональную этику, он сформулировал 21 ценное совет по коммуникации, выбору технологий и планированию карьеры, которые мы подготовили для вас:

Когда я примерно 14 лет назад присоединился к Google, я думал, что эта работа — писать идеальный код. Я был частично прав. Чем дольше я работал, тем больше понимал, что успешные инженеры — это не те, кто пишет лучший код, а те, кто умеет управлять всем, что выходит за рамки кода: межличностными отношениями, политикой, согласованием мнений и неопределенностью.

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

Я делюсь этим, потому что много получил от тех инженеров, которые готовы помогать новичкам. Это мой вклад.

1. Ведущие инженеры увлечены решением пользовательских проблем

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

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

2. «Доказательство своей правоты» — бесполезно, важна совместная работа для достижения правильной цели

Можно выиграть каждую техническую дискуссию, но проиграть весь проект. Я видел умных инженеров, которые постоянно хотят быть самыми умными, и в итоге накапливают невидимую обиду. Эта цена проявляется как «таинственные проблемы с выполнением» или «непонятное сопротивление».

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

3. Действуй. Запускай! Ты можешь исправлять плохие страницы, но не можешь исправлять пустую страницу

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

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

4. Опытность проявляется в ясности, ум — в ответственности

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

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

5. «Новизна» — это высокорискованный заем у ремонта, найма и когнитивной нагрузки

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

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

6. Код не за тебя говорит, люди — да

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

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

7. Лучший код — это тот, который ты никогда не напишешь

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

Перед началом спроси себя: «А что, если мы вообще ничего не сделаем?» Иногда ответ — «ничего плохого не случится», и это — твое решение. Вопрос не в том, что инженеры не умеют писать код или AI, а в том, что мы так хорошо умеем писать, что забываем спросить: «А нужно ли это вообще писать?»

8. Когда масштаб достаточно велик, даже твои баги имеют пользователей

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

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

9. Большинство «медленных» команд — это на самом деле «отвлеченные» команды

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

10. Сосредоточься на том, что ты можешь контролировать, игнорируй остальное

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

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

11. Абстракция не устраняет сложность, она лишь переносит ее

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

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

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

Объяснение другим делает понимание яснее и для меня. Это не только щедрый обмен знаниями, а — эффективный способ учиться. Если кажется, что ты все понял, попробуй объяснить просто. Там, где застрял — там слабое понимание. Обучение — это отладка (debugging) твоей ментальной модели.

13. Сделать возможным другие работы — бесценно, но невидимо

«Работа связующего звена» — документация, onboarding, межкомандное взаимодействие, процессы — очень важны. Но если делать это автоматически и без осознанности, это мешает профессиональному росту и вызывает усталость. Ловушка — считать это «помощью», а не сознательным, границами ограниченным и видимым вкладом. Ограничивайте время, делайте по очереди, превращайте в результат (документы, шаблоны, автоматизацию).

Воспринимайте это как влияние, а не как личностную черту.

14. Если ты побеждаешь каждую дискуссию, ты, возможно, накапливаешь безмолвное сопротивление

Я научился сомневаться в своей уверенности. Когда я легко побеждаю, что-то не так. Люди перестают спорить не потому, что согласны, а потому что сдаются — они выражают свое несогласие в действиях, а не в обсуждениях. Истинное согласие требует времени.

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

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

Каждый показатель, который вы показываете руководству, в итоге «подгоняется». Это не злонамеренно, а — закономерность: люди оптимизируют то, что измеряют (закон Гудхарт). Если считать строки кода, их станет больше. Если считать скорость, она раздуется.

Опытные практики: для каждого показателя запрашивайте пару — один для скорости, другой для качества или риска. Стойте на «тренде», а не на порогах. Цель — инсайты, а не контроль.

16. Признание «я не знаю» создает больше безопасности, чем притворство

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

17. Твой контекст долговечнее любой работы

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

18. Большинство улучшений производительности — это «удаление работы», а не «умные алгоритмы»

Когда система тормозит, инстинкт — добавлять кеши, параллелизм, более умные алгоритмы. Иногда это правильно, но я видел больше улучшений, задавая вопрос: «Что мы считаем лишним?» Удаление ненужных задач почти всегда эффективнее, чем ускорение выполнения нужных. Самый быстрый код — это тот, который не запускается.

19. Существование процессов — для уменьшения неопределенности, а не для создания документации

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

20. В конечном итоге время ценнее денег, действуй исходя из этого

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

21. Нет коротких путей, есть эффект сложных процентов

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

Последняя мысль

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

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

Если ты только начинаешь — знай, что со временем это станет все интереснее. А если уже много лет — надеюсь, что несколько правил найдут отклик в твоем опыте.