21 урок за 14 лет в Google
Я прочитала заметку Адди Османи — «21 урок за 14 лет в Google».
Источник: https://addyosmani.com/blog/21-lessons/
Многие уроки отозвались, поэтому сохраню перевод здесь, чтобы иметь возможность вернуться к тексту и использовать "уроки" на ретроспективах команды, в объяснениях своих подходов и аргументации выдвигаемых решений.
Когда я пришёл в Google примерно 14 лет назад, мне казалось: работа инженера — это писать отличный код. Это правда… но только частично. Чем дольше я работал, тем яснее видел: в больших компаниях “выстреливают” не обязательно самые сильные программисты. Чаще всего — те, кто умеет ориентироваться вокруг кода: в людях, в неформальных правилах, в согласовании позиций, в неоднозначности.
Эти 21 урок — то, что я хотел бы знать раньше. Некоторые сэкономили бы мне месяцы раздражения. Другие заняли годы, чтобы по-настоящему “дойти”. И почти ничего из этого не про конкретные технологии — они меняются слишком быстро. Это про повторяющиеся закономерности: проект за проектом, команда за командой. Я делюсь этим, потому что когда-то другие инженеры сделали то же самое для меня. Пусть это будет моим “передать дальше”.
1) Лучшие инженеры одержимы не технологией, а проблемой пользователя
Очень легко влюбиться в технологию — и начать искать, куда бы её “пристроить”. Я так делал. Так делали почти все. Но те, кто создаёт максимальную ценность, идут в обратную сторону: они до упора вникают в проблему пользователя, и уже из понимания проблемы вырастает решение.
“Одержимость пользователем” — это не лозунг, а рутина: читать обращения в поддержку, разговаривать с пользователями, наблюдать, где и почему им тяжело, задавать “почему?” снова и снова, пока не дойдёте до основания, до первопричины. И удивительная вещь: когда вы действительно поняли проблему, элегантное решение часто оказывается гораздо проще, чем ожидали все вокруг.
А инженер, который начинает с готового решения, обычно строит сложность — чтобы потом оправдать, зачем оно вообще было нужно.
2) Быть правым — дёшево. Прийти к правильному вместе — вот настоящая работа
Вы можете выиграть все технические споры — и проиграть проект. Я видел, как блестящие инженеры копили вокруг себя тихую обиду просто потому, что “всегда были самыми умными в комнате”. И расплата приходила позже — в виде “странных проблем с исполнением”, “пассивного сопротивления”, “необъяснимой пробуксовки”.
Навык не в том, чтобы быть правым. Навык — входить в обсуждение так, чтобы согласовать понимание проблемы, дать пространство другим и сохранять здоровое сомнение в собственной уверенности.
Мне нравится формула: “сильные убеждения — но держать их легко”. Не потому что у вас нет позиции, а потому что решения в условиях неопределённости не стоит приваривать к собственной личности.
3) Делайте. Выпускайте. Пустоту нельзя отредактировать
Погоня за совершенством парализует. Я видел, как инженеры неделями спорили об “идеальной архитектуре” для того, чего они ещё даже не построили. Но идеальное решение редко рождается из размышлений. Оно рождается из контакта с реальностью — и инструменты на базе искусственного интеллекта сейчас во многом помогают быстрее перейти к этой реальности.
Хорошая последовательность звучит грубо, но работает: сначала сделать, потом сделать правильно, потом сделать лучше. Показать пользователям неуклюжий прототип. Написать первый, “грязный” вариант проектного документа. Выпустить минимальную версию, которая вам чуть-чуть неловка. Неделя реальной обратной связи даёт больше, чем месяц теоретических дебатов.
Движение создаёт ясность. Паралич анализа не создаёт ничего.
4) Ясность — это уровень старшинства. “Хитрость” — это накладные расходы
Желание писать “хитро” почти универсально. Это ощущается как доказательство компетентности.
Но разработка программ — это то, что происходит, когда к вашему коду добавляется время и другие программисты. В этой реальности ясность — не “вкус” и не “стиль”. Это снижение операционных рисков.
Представьте: ваш код — это записка-стратегия для незнакомых людей, которые будут сопровождать систему в два часа ночи во время аварии. Оптимизируйте не под собственную элегантность, а под их понимание. Лучшие старшие инженеры снова и снова выбирают ясность вместо “хитрости”.
5) Новизна — это займ, который вы возвращаете авариями, наймом и перегрузкой головы
Относитесь к выбору технологий так, будто у организации есть маленький бюджет “жетонов инноваций”. Потратили один — когда взяли что-то заметно нестандартное. Много таких жетонов у вас нет.
Смысл не в “никогда не инновационировать”. Смысл в другом: инновации стоит делать только там, где вам за них действительно платят уникальной ценностью. Во всём остальном лучше выбирать “скучное”: у скучного известны типовые поломки и способы лечения.
И ещё неприятная правда: “лучший инструмент для задачи” часто проигрывает “наименее плохому инструменту для многих задач”. Потому что управление “зоопарком” технологий становится настоящим налогом на скорость и надёжность.
6) Ваш код сам за вас не выступит. За вас выступают люди
Раньше я думал: если работа отличная — её заметят. Ошибка. Код тихо лежит в репозитории. А вот руководитель упоминает вас на встрече — или не упоминает. Коллега рекомендует вас в проект — или рекомендует кого-то другого.
В больших организациях решения принимаются на встречах, куда вас не позвали; по кратким пересказам, которые писали не вы; людьми, у которых пять минут и двенадцать приоритетов. Если никто не может сформулировать ваш вклад, когда вас нет в комнате, ваш вклад становится “по желанию” — то есть его легко обойти.
И это не только про саморекламу. Это про то, чтобы цепочка ценности была понятной всем — включая вас самих.
7) Лучший код — тот, который не пришлось писать
В инженерной культуре принято праздновать создание. Почти никто не получает признание за удаление кода — хотя удаление нередко улучшает систему сильнее, чем добавление. Каждая строка, которую вы не написали, — это строка, которую вы никогда не будете отлаживать, сопровождать и объяснять.
Перед тем как строить, доведите до конца вопрос: “А что будет, если мы просто… не будем этого делать?” Иногда ответ: “ничего плохого”. И это и есть решение.
Проблема не в том, что инженеры не умеют писать код (и не в том, что теперь есть инструменты, которые помогают писать быстрее). Проблема в том, что мы настолько хорошо умеем писать, что забываем спросить: “А надо ли?”
8) На большом масштабе даже ваши ошибки обретают пользователей
Когда пользователей достаточно много, любое наблюдаемое поведение становится зависимостью — независимо от того, что вы “обещали”. Кто-то автоматизирует ваши странности, кто-то строит свои скрипты вокруг ваших особенностей, кто-то полагается на то, что вы считали ошибкой.
Отсюда вывод уровня “меняет карьеру”: нельзя считать совместимость “обслуживанием”, а новые функции — “настоящей работой”. Совместимость — это часть продукта.
Поэтому вывод из эксплуатации старых решений нужно проектировать как миграцию: с временем, инструментами и уважением к тем, кто зависит от вас. И часто “дизайн программного интерфейса” — это на деле “пенсия программного интерфейса”.
9) Большинство “медленных” команд на самом деле не медленные — они несогласованные
Когда проект тянется, хочется обвинить исполнение: “не хватает людей”, “технология плохая”, “работают недостаточно”. Но чаще это не корень проблемы.
В больших компаниях команда — это единица параллельной работы. Но стоимость координации растёт очень быстро, когда команд становится больше. И многие задержки — это провал согласования: люди делают не то; или делают то, но несовместимыми способами.
Старшие инженеры поэтому и тратят больше времени не на “писать быстрее”, а на прояснение направления, границ между частями системы и приоритетов — потому что именно там настоящее “узкое место”.
10) Сфокусируйтесь на том, что вы можете контролировать. Остальное — отпустите
В крупной компании бесконечное число факторов вне вашего контроля: организационные перестройки, решения руководства, рыночные повороты, смена курса продукта. Если жить в этом — вы получите тревогу без влияния.
Те, кто остаётся эффективным и психически устойчивым, держатся своей “зоны влияния”. Вы не контролируете, будет ли перестройка. Но вы контролируете качество своей работы, реакцию на изменения и то, чему вы учитесь. Когда вокруг неопределённость, дробите её на части и ищите конкретные действия, доступные вам прямо сейчас.
Это не пассивное “смирение”. Это стратегический фокус: энергия, потраченная на неизменяемое, украдена у того, что можно улучшить.
11) Абстракции не убирают сложность. Они переносят её на день вашего дежурства
Каждая абстракция — это ставка на то, что вам не придётся понимать, что под ней. Иногда ставка выигрывает. Но что-то обязательно “протечёт”, и когда это случится, нужно понимать, на чём вы стоите.
Старшие инженеры продолжают учить “нижние уровни” даже тогда, когда технологические “этажи” становятся всё выше. Не из ностальгии — из уважения к моменту, когда абстракция ломается, а вы остаётесь один на один с системой глубокой ночью. Пользуйтесь своим стеком решений — но держите в голове рабочую модель того, как он ломается.
12) Письмо рождает ясность. А попытка научить — самый быстрый тест понимания
Пока мысль в голове — она кажется ясной. Как только вы пытаетесь изложить её в документе, выступлении, комментарии на проверке кода (или даже в разговоре с инструментом на базе искусственного интеллекта) — вдруг обнаруживаются дырки. Делая мысль понятной другим, вы делаете её понятнее себе.
Конечно, это не значит, что можно стать хирургом, “объясняя хирургию”. Но в разработке программ принцип работает очень часто.
И это не только про щедрость. Это личный приём обучения: если кажется, что вы что-то поняли — попробуйте объяснить просто. Где запнётесь — там и глубина понимания пока мала. Обучение — это отладка собственных ментальных моделей.
13) Работа, которая делает возможной работу других, бесценна — и при этом невидима
“Клейкая” работа — документация, адаптация новичков, координация между командами, улучшение процессов — жизненно важна. Но если делать её бессознательно, можно одновременно остановить технический рост и выгореть. Ловушка в том, что вы делаете это “из полезности”, а не как осознанный, ограниченный по времени и видимый вклад.
Что помогает: ограничивать по времени, ротировать, превращать в артефакты (документы, шаблоны, автоматизацию) и делать вклад “читаемым” — как результат, а не как черта характера.
Бесценное и невидимое — опасное сочетание для карьеры.
14) Если вы выигрываете каждый спор — скорее всего, вы копите тихое сопротивление
Я научился подозрительно относиться к собственной уверенности. Когда я слишком легко “побеждаю”, обычно что-то не так. Люди перестают спорить не потому, что вы их убедили, а потому, что они устали пытаться. И тогда несогласие проявится не на встрече, а в исполнении.
Настоящее согласование занимает больше времени: нужно реально понять чужие взгляды, впитать обратную связь, иногда публично изменить мнение.
Краткое удовольствие от того, что вы правы, стоит гораздо меньше, чем долгосрочная реальность — строить вещи с союзниками, которые делают это по собственной воле.
15) Когда показатель становится целью — он перестаёт измерять
Любой показатель, который вы показываете руководству, рано или поздно начнут “оптимизировать”. Не обязательно из злого умысла — просто люди всегда стремятся улучшать то, что измеряют.
Считаете строки кода — получите больше строк. Меряете “скорость” — получите раздутые оценки.
Ход старшего уровня: на любой запрос “дайте показатель” отвечать парой. Один — про скорость. Второй — про качество или риск. И настаивать на чтении тенденций, а не поклонении порогам. Цель — понимание, а не надзор.
16) “Я не знаю” создаёт больше безопасности, чем притворство
Старшие инженеры, которые спокойно говорят “не знаю”, не демонстрируют слабость — они создают разрешение. Когда лидер признаёт неопределённость, он сигнализирует: задавать вопросы безопасно. Альтернатива — культура, где все изображают понимание, а проблемы прячутся до взрыва.
Я видел команды, где самый старший человек никогда не признавался в непонимании — и я видел ущерб: вопросы не задаются, предположения не проверяются, младшие молчат, потому что им кажется, что “все и так понимают”.
Смоделируйте любопытство — и получите команду, которая действительно учится.
17) Сеть отношений переживёт любую вашу работу
В начале карьеры я концентрировался на задачах и недооценивал отношения. Теперь считаю это ошибкой. Те, кто инвестировал в связи внутри и вне компании, получали отдачу десятилетиями.
Они раньше узнавали о возможностях, быстрее строили мосты, их рекомендовали на роли, с ними запускали совместные проекты — потому что доверие собирается годами.
Работа не навсегда, а сеть отношений — да. Относитесь к ней с любопытством и щедростью, а не как к сделке. И когда придёт время перехода — часто именно отношения откроют дверь.
18) Большинство побед в производительности — от удаления работы, а не от добавления “умных” слоёв
Когда система тормозит, первая реакция — добавить: уровни кэширования, параллельность, более “хитрые” алгоритмы. Иногда это верно. Но я чаще видел успех там, где задавали другой вопрос: “Что мы вообще считаем, хотя могли бы не считать?”
Удаление лишней работы почти всегда сильнее, чем ускорение необходимой. Самый быстрый код — тот, который не запускается.
Перед оптимизацией спросите: должна ли эта работа существовать вообще?
19) Процесс нужен, чтобы снижать неопределённость, а не чтобы оставлять бумажные следы
Лучший процесс делает координацию проще, а ошибки — дешевле. Худший процесс — бюрократический театр: он существует не чтобы помочь, а чтобы потом назначить виноватого.
Если вы не можете объяснить, как именно процесс снижает риск или повышает ясность, скорее всего это просто накладные расходы.
А если люди тратят больше времени на документирование работы, чем на работу, — значит, где-то всё пошло глубоко не туда.
20) Рано или поздно время становится дороже денег — и вести себя нужно соответственно
В начале карьеры вы обмениваете время на деньги — и это нормально. Но в какой-то момент расчёт переворачивается: вы начинаете понимать, что время — ресурс невозобновляемый.
Я видел старших инженеров, которые выгорали, гоняясь за следующей ступенью, выжимая ещё несколько процентов дохода. Кто-то достигал. Многие потом спрашивали себя: “А стоило ли это того, что я отдал?”
Вывод не в “не работать усердно”. Вывод в другом: понимать, на что вы меняете время, и делать этот обмен осознанно.
21) Коротких путей нет. Но есть накопительный эффект
Экспертность рождается из осознанной практики: выходить чуть за предел текущего навыка, размышлять, повторять. Годами. Сжатой версии нет.
Но есть хорошая новость: обучение накапливается, когда оно создаёт новые возможности, а не просто добавляет факты. Пишите — не ради охватов, а ради ясности. Делайте повторно используемые “кирпичики”. Собирайте опыт ошибок в понятные “плейбуки”.
Инженер, который относится к карьере как к сложному проценту, а не как к лотерее, обычно оказывается гораздо дальше.
Финальная мысль автора
Двадцать один урок звучит как много, но в сущности они сводятся к нескольким опорам: сохранять любопытство, оставаться скромным и помнить — работа всегда про людей. Про пользователей, для которых вы строите, и про команду, с которой вы строите.
Карьера в инженерии достаточно длинная, чтобы наделать ошибок и всё равно прийти в плюс. Самые сильные инженеры — не те, кто всегда был прав, а те, кто учился на ошибках, делился находками и продолжал появляться “на дистанции”.