«Я не могла знайти свою машину в гаражі і забувала цілі розмови»: як робота в Google пошкодила мені мозок

На початку 2015 року розробниця Кетлін Гадд прийшла до Google. Її взяли в команду V8 як одного з перших авторів специфікації до WebAssembly. У цій статті вона розповість частину історії про те, що у підсумку пішло не так і завдало непоправної шкоди її здоров’ю.

Передаємо слово Кетлін.

Редакція Highload публікує переклад матеріалу.

Перекладено бюро перекладів у Києві «Профпереклад».

Сподіваюся, що моя розповідь навчить людей розпізнавати токсичну культуру на робочому місці. Або хоча б допоможе новим співробітникам побудувати кар’єру в Google трохи краще.

Будь-яка історія про WebAssembly буде упередженою — історія самого проєкту дуже непроста. Моя розповідь — не виняток. Намагатимуся викласти якомога точніше, незважаючи на погану пам’ять.

Як все починалося

До приходу в команду V8 я кілька років пропрацювала на підтримці транспайлера, що конвертує .NET-додатки в ефективний JavaScript. Проєкт запустили одночасно з Emscripten — саме ця програма спочатку стала стандартом, а потім надихнула команду на створення WebAssembly. Мені пощастило попрацювати зі творцем asm.js Елоном Закаї (Alon Zakai), і я багато чого в нього навчилася. Завдяки цьому досвіду я ідеально підходила до команди WebAssembly.

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

Тим не менш, Google — найгірша компанія, в якій мені довелося працювати. Це місце буквально пошкодило мій мозок.

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

У WebAsembly був грандіозний потенціал. Mozilla і Google вкалували щосили, щоб asm.js став механізмом, що забезпечує роботу додатків у мережі. Вони вирішили більшість технічних проблем, але стало зрозуміло, що деякі з них занадто важко усунути. Так почалася робота над WebAsembly.

Потрібно було вивчити сильні сторони asm.js та одночасно розібратися зі слабкими. А потім створити специфікацію, яку можна легко реалізувати в нинішніх runtime JavaScript з використанням їх генераторів коду, debugging та іншої інфраструктури.

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

Всі були водночас і менеджерами, і юристами, і програмістами. І Дж.Ф. Бастьєн (JF Bastien ), і Люк Вагнер, і Елон Закаї, і Бен Тітзер, і багато інших старанно працювали, створюючи основу того, що потім використовуватимуть мільярди людей.

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

Для WebAssembly ми не могли і не збиралися випускати напівфабрикат. Як браузер-розробники ми всі розуміли, яку ціну доведеться заплатити за погану специфікацію.

Звідки взялися стрес та токсичність?

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

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

У нас не було менеджера. Ми знали, що він нам потрібен, і навіть намагалися його отримати. У кращому разі такий менеджер викликався попрацювати за сумісництвом і недовго, а потім переходив до іншого проєкту. Через це у нас виникали складні соціально-організаційні проблеми, і вирішувати їх доводилося самим інженерам, які не мають такого досвіду. А роботи в них і так було достатньо.

У результаті ми змогли вчасно уявити продукт із мінімальним функціоналом, якість специфікації була низькою, а автори просто розбігалися. Подібна ситуація в історії продуктів з відкритим кодом не є унікальною, але спостерігати її все одно було сумно.

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

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

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

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

Через війну специфікація WebAssembly будувалася на каламутній і зовсім невідповідній технології. Через це людям було складно зробити свій внесок, і багато учасників групи залишилися незадоволені. Зрештою, специфікацію, звичайно, зачесали до потрібного рівня і випустили, але коштувало це недешево.

Як WebAssembly пошкодила мій мозок

Трохи вище я писала, що WebAssembly пошкодила мій мозок — абсурдне твердження, але, на жаль, правда. Два роки роботи у Google супроводжувалися постійним стресом. Мені довелося неофіційно виступити менеджером проєкту, допомагати вести наради, документувати рішення і при цьому ще й розбиратися з ворожо налаштованими колегами.

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

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

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

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

Моєю першою оплачуваною роботою була робота гейм-дизайнера у студії з розробки ігор на початку 2007 року. Я швидко вжилася у роль, яка визначила всю мою кар’єру — роль tool-програміста. Я зосередилася на тому, як допомогти іншим виконувати свою роботу, як зрозуміти, що саме викликає у них стрес та заважає рухатися далі.

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

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

Будь-яке токсичне місце, де я працювала, зазвичай було результатом поганої роботи керівництва. Цей випадок не став винятком. Тут я теж пояснила одному з керівників Google, чому у проєкті WebAssembly виникли проблеми. Що йому не вистачає підтримки з боку організації, бо люди просто йдуть геть. Він погодився з моєю оцінкою, а потім повідомив, що нічого не змінюватиме. У результаті команда змінила все самостійно.

Фінал моєї історії з Google

Моя робота в Google завершилася тихо і без жодних драм. Я повернулася з відпустки і виявилося, що команду WebAssembly фактично розпустили — хтось звільнився, а хтось втік до інших відділів. Мій новий менеджер повідомив, що тепер я буду працювати над незнайомою мені частиною Chrome з іншими людьми.

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

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

Сподіваюся, ви ніколи не відчуєте на собі те, що пережила я, і зможете побудувати успішну кар’єру своєї мрії.

Автор: Кетлін Гадд