Написати програму не складно, але складність полягає у взаємодії з «людьми» та «складністю». Досвідчені інженери Google мають 14 років досвіду — від мислення користувача до командної роботи — ці 21 золоте правило допоможуть вам досягти глибшої кар’єри.
(Синопсис: Google Real-time Translate офіційно відкриває всі бренди навушників: 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. Коротких шляхів немає, але існує ефект складних відсотків

• Трохи роздумів

Директор Google Cloud AI Едді Османі — досвідчений інженер-програміст і мислитель, який майже 14 років очолює відділ досвіду розробників у Chrome, працюючи над такими проєктами, як DevTools, Lighthouse та Core Web Vitals. Сьогодні він координує роботу між Google DeepMind, інженерними, продуктовими та командами взаємодії з розробниками.

3-го числа він опублікував детальну статтю про досвід роботи на своєму особистому блозі. Поєднуючи багаторічний досвід роботи в Google із професіоналізмом, він підсумував 21 цінну пропозицію щодо комунікації, вибору технологій та планування кар’єри, зібраних і організованих наступним чином:

Коли я приєднався до Google близько 14 років тому, я думав, що все зводиться до написання ідеального коду. Я був лише частково правий. Чим довше я залишався, тим більше розумів, що інженери, які досягають успіху, не обов’язково найкращі в програмуванні, а ті, хто навчається це робитиОрієнтуйтеся на все, що виходить за межі кодуЛюди: включаючи міжособистісні стосунки, політику на робочому місці, узгодження консенсусу та невизначеність.

Ці переживання я хотів би зрозуміти раніше. Деякі рятували мене місяцями розчарування, інші — роками, щоб це усвідомити. Усе це не має нічого спільного з конкретною технологією: технології змінюються надто швидко і не мають значення. Вони про закономірності, які повторюються в різних проєктах і командах.

Я ділюся цим, бо отримав величезну користь від інженерів, які готові підтримувати молодше покоління. Ось моя маленька думка.

1. Топові інженери одержимі розв’язанням проблем користувачів

Дуже спокусливо закохатися в певну технологію і шукати сценарії застосування. Я це робив, усі це робили. Але інженери, які створюють найбільшу цінність, працюють «навпаки»: вони одержимі глибоким розумінням проблеми користувача і дозволяють вирішенню природно виникати з цього розуміння.

Користувачі одержиміЦе означає витрачати час на дослідження заявок на обслуговування клієнтів, спілкування з користувачами, спостереження за їхніми операційними дилемами та постійні питання «чому», поки вони не дійдуть до суті. Інженери, які справді розуміють проблему, часто виявляють, що елегантні рішення виявляються простішими, ніж очікувалося.Інженери, які починають із рішення, часто додають зайву складність для раціоналізації власних рішень.

2. «Доводити свою правоту» — це марно, і ключ у тому, щоб разом досягти правильної мети

Ви можете виграти всі технічні дебати і програти весь проєкт. Я бачив, як розумні інженери накопичують мовчазну образу, бо завжди хочуть бути найрозумнішими в кімнаті. Ця ціна потім проявляється у вигляді «загадкових проблем із виконанням» або «незрозумілого опору».

Навичка полягає не в тому, щоб бути «правим», а в тому, щоб брати участь у дискусіях, щоб узгодити проблеми, створити простір для інших і сумніватися у власній впевненості. Сильна наполегливість, відкритий розум– Це не через брак віри, а тому, що рішення, прийняті в невизначених ситуаціях, не повинні бути пов’язані з твоєю самооцінкою.

3. Орієнтована на дії. Виходьте в ефір! Ви можете редагувати погану сторінку, але не можете редагувати порожню сторінку

Прагнення до досконалості може призвести до паралічу. Я бачив, як інженери тижнями обговорювали ідеальну архітектуру для чогось, чого ніколи не будували. Ідеальна схема рідко виникає з чистого мислення — вона виникає з зіткнення з реальністю. ШІ може допомогти багатьма способами.

**Спочатку роби це, потім роби правильно, і нарешті зроби краще.**Виставляйте некрасиві прототипи перед користувачами. Запишіть перший чернетковий варіант заплутаного дизайн-документа. Опублікуйте той MVP, який змушує вас почуватися трохи ніяково. Ви можете дізнатися більше за тиждень реального зворотного зв’язку, ніж за місяць теоретичних аргументів.Імпульс приносить ясність, а параліч аналізу — ні до чого.

4. Старшинство відображається у ясності, а інтелект — у тягарі

Інстинкт писати «розумний» код майже універсальний для інженерів, і це відчувається як доказ компетентності. Але програмна інженерія — це хімічна реакція «часу» плюс «інших програмістів». У такому контексті чіткість — це не стиль;Зменшення операційного ризику。

Ваш код — це стратегічне повідомлення для незнайомців, які можуть виправляти збій о другій ночі. Оптимізуйте їхнє розуміння, а не своє відчуття благодаті. Старші інженери, якими я найбільше захоплююся, завжди обирають обмін «розумним» на «зрозумілий».

5. «Новизна» — це лихварство, запозичене з підтримки, набору та когнітивного навантаження

Думайте про свої технологічні вибори як про компанію з обмеженим бюджетом «інноваційного токену». Якщо ви використовуєте досить нестандартну технологію, витрачайте одну. Ви не можете дозволити собі багато платити. Суть не в тому, щоб «ніколи не впроваджувати інновації», аІнновуйте лише там, де отримуєте унікальну оплату」。

Все інше за замовчуванням має бути «нудним», бо нудьга означає, що його режим відступу відомий. «Найкращий інструмент для роботи» часто є «інструментом, який найкраще виконує кілька завдань»- Бо керування технічним зоопарком стане справжнім тягарем.

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

На початку кар’єри я думав, що хороша робота говорить сама за себе. Я помилявся. Код тихо залишається на складі. Важливо, чи згадує ваш керівник вас на зустрічах і чи рекомендують колеги брати участь у проєкті.

У великих організаціях рішення приймаються на зустрічі, на яку вас не запросили, людина, яка мала лише п’ять хвилин на роботу над дванадцятьма пріоритетами, на основі резюме, яке ви не написали. Якщо ніхто не може сказати тобі про свій вплив, коли тебе немає, то твій вплив замінний. Це не зовсім самореклама, це проЗробіть ланцюг створення цінності видимим для всіх, включаючи себе。

7. Найкращий код — це рядок, який ти ніколи не писав

Інженерна культура святкує творення. Ніхто не отримує підвищення через видалення коду, хоча видалення зазвичай краще оптимізує систему, ніж її збільшення. Кожен рядок коду, який ви не пишете, — це те, що вам ніколи не потрібно налагоджувати, підтримувати чи пояснювати.

Перед тим, як будувати, ретельно задайте собі питання: "**Що буде, якщо ми взагалі цього не зробимо?**Іноді відповідь — «нічого поганого», і це ваше рішення. Проблема не в тому, що інженери не вміють писати код або не вміють писати за допомогою ШІ, а в тому, що ми настільки добре пишемо, що забуваємо запитати: «Чи варто мені це писати?»

8. Коли він достатньо великий, навіть у вашого комахи є користувачі

Коли користувачів достатньо, будь-яка спостережувана поведінка стає залежністю — незалежно від того, що ви спочатку обіцяли (закон Гірама). Хтось скрапить ваш API, автоматизує ваші складні функції та кешує ваші баги.

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

9. Більшість «повільних» команд насправді є «не в фокусі»

Коли проєкт застрягає, інстинкт підказує звинувачувати виконання: недостатня людська сила, неправильний вибір технологій. Зазвичай це не основні питання. У великій компанії команда — це ваш конкурентний одиниця, але вартість координації зростає експоненційно зі збільшенням кількості команди. Насправді найповільнішіВирівнювання не вдалося— Люди створюють щось не те або правильне у несумісний спосіб. Старші інженери більше часу витрачають на уточнення напрямків, інтерфейсів і пріоритетів, а не на «швидше написання коду», бо саме там криється справжня вузька перешкода.

10. Зосередься на тому, що можеш контролювати, і ігноруй те, що не можеш

У великих компаніях існує безліч змінних, які неможливо контролювати — реструктуризація організацій, управлінські рішення, зміни на ринку, зміни продуктів. Хвилювання через це викликає тривогу, але не допомагає. Інженери, які залишаються розсудливими та ефективними, зосередяться на нихКоло впливу。

Ви не можете контролювати реструктуризацію, але можете контролювати якість своєї роботи, реакції та те, що дізнаєтеся. Коли стикаєтеся з невизначеністю, розкладіть проблему на частину і знайдіть конкретні дії, яких ви можете зробити. Це не про пасивне прийняття, а про стратегічну концентрацію. Енергія, витрачена на те, що не можна змінити, крадеться з того, що ти можеш змінити.

11. Абстракція не усуває складність, вона лише переносить її

Кожна абстракція — це азартна гра, і ви не повинні розуміти основні принципи. Іноді ти виграєш, але абстракція завжди просочується. Коли він не працює, потрібно знати, що відбувається всередині. Старші інженери продовжують опановувати знання «знизу вгору», навіть коли технологічний стек стає все вищим і вищим. Це не з ностальгії, а з поваги до моменту абстрактного провалу.Використовуйте свій інструмент, але опануйте ментальну модель його основного режиму невдач.

12. Письмо є нав’язливим і зрозумілим, а викладання — найшвидший спосіб навчитися

Письмо змушує тебе думати. Коли я пояснюю концепцію іншим — чи то в документації, промовах, коментарях до перегляду коду, чи просто спілкуючись із ШІ — я знаходжу прогалини у своєму розумінні.

Процес пояснення контенту для інших також зробить його зрозумілішим для мене. Йдеться не лише про щедрий обмін знаннями, а й проТехніки егоїстичного навчання。 Якщо ви думаєте, що щось зрозуміли, спробуйте пояснити це просто. Де ти застрягаєш, там ти розумієш поверхнево.Урок присвячений налагодженню власної ментальної моделі.

13. Робота, яка робить можливими інші професії, безцінна, але невидима

«Клеєва робота» — документація, адаптація, міжкомандна координація, покращення процесів — є надзвичайно важливою. Але якщо робити це бездумно, це може завадити вашому технічному розвитку і виснажити. Пастка полягає в тому, щоб бачити це як «корисне», а не як такеСвідомі, межі, видимі внески。 Обмежуйте час, обертайте виконання, конвертуйте його у вихідні дані (документи, шаблони, інструменти автоматизації).

Нехай це сприймається як вплив, а не риса характеру.

14. Якщо ви виграєте всі суперечки, ви можете накопичувати мовчазний опір

Я навчився сумніватися у своїй впевненості. Коли я «виграю» занадто легко, зазвичай щось іде не так. Люди перестають сперечатися не тому, що ви переконані, а тому, що перестають намагатися — вони висловлять це заперечення на виконанні, а не на зустрічах. Справжнє вирівнювання займає більше часу.

Потрібно дійсно розуміти точку зору інших, враховувати зворотний зв’язок і іноді навіть відкрито змінювати свою думку. Захоплення від короткострокової перемоги у суперечці набагато менш цінне, ніж робота з партнером, який довго щасливий і переконаний.

15. Коли індикатор стає метою, він вже не є хорошим індикатором

Кожен показник, який ви показуєте керівництву, зрештою буде «маніпульований». Це не через злість, а тому, що люди оптимізують для того, що виміряється (закон Гудхардта). Якщо відстежувати рядки коду, отримаєте більше рядків. Якщо ви відстежуєте ставку, отримуєте оцінку інфляції.

Перевірений підхід: Надайте пару метрик для кожного запиту метрики. Один дивиться на швидкість, інший — на якість або ризики. НаполегливістьІнтерпретація тенденцій, а не поріг поклоніння. Мета — це проникливість, а не спостереження.

16. Визнання «я не знаю» створює відчуття безпеки більше, ніж удавати, що розумієш

Старші інженери, які кажуть «я не знаю», не показують слабкості, а створюють «дозволи». Коли лідер визнає невизначеність, це дає сигнал, що кімната безпечна і для інших. Я бачив старші команди, які ніколи не визнають плутанини, і це дуже боляче: ніхто не ставить запитань, вважає, що ніхто не кидає їм виклик, а молодші інженери мовчать, бо думають, що вони єдині, хто не розуміє. Проявіть цікавість — і ви отримаєте команду, яка справді навчиться.

17. Ваш контекст триває довше, ніж будь-яка робота, яку ви коли-небудь виконували

На початку кар’єри я зосередився на роботі і занедбав свої зв’язки. Озираючись назад, це була помилка. Колеги, які інвестують у стосунки (як всередині компанії, так і поза нею), отримують значну вигоду протягом десятиліть. Вони першими чують про можливості, швидше будують мости, отримують рекомендації щодо роботи та починають бізнес із людьми, яким довіряли роками. Робота не назавжди, але зв’язки — це назавжди. Будуйте стосунки з цікавістю та щедрістю, а не через транзакційний підхід.

18. Більшість приростів у продуктивності досягається завдяки «видаленню роботи», а не завдяки «розумним алгоритмам»

Коли система сповільнюється, виникає інстинкт до зростання: рівень кешування, паралельна обробка, розумніші алгоритми. Іноді це правда, але я бачив, що більше приростів у продуктивності приходить від запитань: "**Що ми розрахували, що нам не потрібно?**Видалення непотрібної роботи майже завжди має більший вплив, ніж швидше виконати необхідну роботу. Найшвидший код — це той, що ніколи не запускається.

19. Існують процеси для зменшення невизначеності, а не для створення документів

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

20. Зрештою, час буде ціннішим за гроші, дійте відповідно

На початку кар’єри ти обмінюєш час на гроші, і це нормально. Але в якийсь момент розрахунок змінюється навпаки. Ви зрозумієте, що час — це невідновлюваний ресурс. Я бачив, як старші інженери вигорають, намагаючись піднятися на наступний рівень і оптимізувати ці кілька відсоткових пунктів оплати. Дехто отримав його, але більшість пізніше сумнівалася, чи варта вона тієї ціни, яку вони заплатили. Відповідь не «не працюй наполегливо», аЗнайте, чим торгуєте, і торгуйте свідомо」。

21. Коротких шляхів немає, але існує ефект складних відсотків

Експертиза походить із свідомої практики — трохи більше, ніж твої поточні навички, розмірковуєш, повторюй, роками. Зменшеної версії немає. Але надія полягає в:Коли навчання створює нові вибори, а не лише фрагментарні знання, це генерує складний інтерес. Писати (для ясності), створювати багаторазові сирі групи та збирати болючі уроки у підручник. Інженери, які вважають свою кар’єру «складним відсотком», а не «лотереєю», часто йдуть набагато далі.

Остання думка

Ці 21 — це багато, але насправді є лише кілька основних ідей:Залишайтеся допитливими, залишайтеся скромними і пам’ятайте, що робота завжди про людей- Включаючи користувачів, для яких ви створюєте продукти, а також товаришів по команді, які створюють продукти разом із вами.

Інженери мають довгу кар’єру, достатньо довгу, щоб робити багато помилок і при цьому бути успішними. Інженери, яких я найбільше поважаю, — це не ті, хто ніколи не помиляється, а ті, хто вчиться на них, ділиться відкриттями і наполегливо.

Якщо ви тільки починаєте цю подорож, знайте, що з часом вона стане цікавішою. Якщо ви працюєте над цим роками, сподіваюся, деякі з них вам відгукнуться.