Разработчик Дмитрий Свиридкин рассказал о своих трёх годах работы в Amazon Web Services в Лондоне и причинах ухода из этой компании.
17 октября 2022 Свиридкин вышел на работу в офис Amazon Web Services в Лондоне. 17 октября 2025 был его последний день в AWS. Уволившись, он отказался от возможности получить ещё как минимум около ~£100k в Amazon RSU, если продержится ещё год. Это было полностью его решение
Согласно пояснению Свиридкина, Amazon очень большой. «И действительно, истории про бесчеловечные условия могут быть 100% правдой в одной его части и совершенным мифом в другой его части. Я могу лишь конкретно говорить про AWS, а максимально уверенно про CloudFront. Но и есть некоторые особенности, справедливые для всего Amazon», — пояснил разработчик.
Некоторые причины, почему Свиридкин решил покинуть AWS:
компенсация в сравнении с рынком;
Return-to-office на 5 дней;
бесконечные согласования;
отчаянные попытки сделать что-то хорошо;
онколлы;
разочарование в проектах;
стресс (последняя причина стала решающей).
«Я всегда считал себя достаточно стрессоустойчивым. И мне казалось, что вокруг в целом ничего прямо сильно напряжённого в моей работе не происходит. По крайней мере, постоянно.
Однако, будучи подверженной регулярным почти каждодневным подёргиваниям в разные стороны (как тут любят говорить: receive shouldertaps), человеческая нервная система может в какой‑то момент не выдержать:
За 3 года работы в AWS я заработал себе чудовищный стрессовый кашель, от которого меня иногда складывало пополам и рвало. Я долго не понимал причины этого кашля — ходил по врачам, потратил на них всю годовую квоту страховки. Врачи и исследования отсекли респираторную и гастрологическую причину, оставив меня с од��ой — стрессовой. Я повнимательнее последил как мой кашель коррелирует с тем, что я делаю в течение дня. И заметил, что:
Я почти не кашляю на выходных.
Я почти не кашляю в отпуске.
Максимально плохо становилось после митингов.
А также когда я выходил из дома, направляясь в офис»,
— сообщил Свиридкин.
Дополнительно Свиридкин расказал, что GenAI истерия в Amazon совершенно неадекватная, по его мнению, так как:
От почти всех проектов хотят видеть GenAI, в каком угодно виде.
Внутренний хакатон? Надо GenAI приплести. Без этого оценивать не будут.
А вот вам еще KPI на использования GenAI в работе.
Также в Amazon есть система анонимного ежедневного опроса по текущей ситуации в команде. «Эта замечательная система последние недели перед моим решением уволиться, каждый день спрашивала, насколько глубоко я осведомлён и использую GenAI в работе. Долбление этими опросами уже стало меметично невыносимым», — добавил Свиридкин.
В 2022 году Свиридкина наняли как L5 Software Engineer. После примерно года работы в компании почти всех L4 инженеров промоутят до L5. Тогда он думал, что, наверное, неплохо попробовать тоже получить повышение. В Лондоне оказалось ни одного L6 инженера. Тем более Свиридкин рассказал, что продвинул хороший проект и выбил одобрение на него. И даже завершил.
В итоге Свиридкину дали оценку exceeded role expectations. Даже с большой заинтересованностью менеджера в промо и он получал комментарий: bar is so high. Потом ему надо было ещё один документ написать, чтобы продемонстрировать operational excellence. А потом ещё один системный документ и точно ожидалось повышение.
«Вот у всех уже такое восприятие, что ну ты прям L6, но сейчас только senoir peers, покажем ещё один документик, чтоб они поняли как ты будешь чувствовать себя за пределами зоны комфорта», — добавил Свиридкин.
В общем, год назад Свиридкин, насмотревшись на бесконечные митинги и ещё большее дёргание L6 инженеров (а ещё больше митингов до полуночи), решил что не очень сильно ему и надо это повышение.
«К тому же L5 в Amazon считается терминальным уровнем — на нём люди по 10 лет сидят. Потому что bar is soooooooooo high. И да, чтоб получить повышение, инженер должен несколько лет подряд пахать на уровне того самого повышения. Но без компенсации с того уровня выше. Компенсация при этом, по свидетельствам многих, совершенно не соответствует уровню головной боли, которая ждёт разработчика», — уточнил Свиридкин.
Также Свиридкин рассказал, что не очень сильно любит веб-разработку и стандартное энтерпрайз CRUDовращение. Он начинал свою карьеру как C++ разработчик, перекладывая байты из регистров FPGA плат и оптимизируя классные числодробилки. В CloudFront Compute ему довелось поработать с отличными задачами (многие из которых он сам себе нашел) по оптимизации и низкоуровневому системному программированию.
«Многие задачи и фиксы делались за пару дней или недель. И показывали очень хорошие результаты в лабораторных испытаниях, проходя все известные и разумные тесты. Ну что, может быть попробуем их зарелизить и увидим результаты?:
А мы уверены?
А сколько киллсвичей нужно?
А это точно верная цель?
А вдруг это кого‑то сломает?
И такие обсуждения тянулись месяцами. И каждый раз нужно было убеждать, убеждать, убеждать. Нельзя просто так попробовать, убедиться или откатить...
В какой‑то момент я уже просто не мог писать никакой код, кроме уж чего‑то совсем небольшого. Любое хоть сколько‑нибудь серьёзное изменение больше 10 строчек потребует раунды:
Долгого пинания ревьюеров с 8ми часовой разницей во времени.
Сомнений от всех подряд, а точно ли XXXX?
Написания бесконечных документов для аппрува тестирования на живом трафике, ведь экспериментального недостаточно.
Еще бесконечных обсуждений дополнительных мониторов, алармов и килл‑свитчей.
И потом еще регулярного отслеживания, как оно там едет через пайплайны, которые могут стоять месяцами.
Я прошел через это испытание один раз в рамках относительно небольшого изолированного проекта (примерно 5 тысяч строк изменений в сумме, и очень много тестов сверху). И от осознания того, что любое другое сопоставимое изменение пойдет таким же путём, у меня полностью отпало всякое желание начинать что‑либо.
Релиз проекта, который я сделал за 2 недели, занял полтора года... Полтора года не иметь возможности никак увидеть результат своей работы!
Заставьте программистов писать код, не дайте им увидеть результат и при этом дёргайте их в разные стороны — вот самый лу��ший рецепт для выгорания.
Я, конечно, прекрасно понимаю, что такое положение дел может многих устраивать. И вообще это всё правильно: система большая, со специфичными требованиями, нужно все чётко спланировать, учесть, продумать, чтоб нулевой down time, а потом караван будет медленно идти следующие 5 лет... Но меня такое только разочаровывает. Я предпочту работать над менее масштабными проектами с понятным циклом доставки, а не над чудовищными распределёнными облаками, непрерывный деплой которых — постоянная пляска на граблях.
Я почти уверен что все связанное с процессами релизов и проработки фич применимо не только к Амазону. Так что от любых как‑либо связанный с SRE (Site Releability Engineer) позиций я буду держаться как можно дальше»,
— пояснил Свиридкин.
