Тёмные и светлые стороны работы в Яндекс
Эпиграф: Профессии “программист” не существует.
На написание этой статьи меня натолкнула статья “Тёмная сторона работы в Яндекс.Маркете”.
Дисклаймер: написанное ниже является моим личным мнением, официальное мнение компании по данному вопросу мне неизвестно.
Автор описывает много вещей, которые, да - существуют в реальности, но пишет в каком-то сильно уж отрицательном ключе, так, что картина уж больно мрачная складывается.
Попробую немножко пооппонировать.
Прежде чем начать статью - немного расскажу о себе. Я работаю в Яндексе. Возглавляю в нём отдел, разрабатывающий ПО для одного из оффлайн/онлайн бизнесов. Сам при этом тоже пишу код (то есть я - не менеджер). До Яндекса я работал в нескольких компаниях. В том числе больших, например в Mail.RU.
Попал я в Яндекс не очень традиционным способом: мы с друзьями сделали вполне успешный стартап, который нормально взлетел и работал. Был конкурентом одному из бизнесов Яндекса. Технологически мы в каких-то аспектах сильно превосходили Яндекс. А вот финансово, разумеется, соперничать с ним не могли: наш стартап поднимался на вложении исключительно нашего труда. Инвестиции мы не привлекали. И поэтому в один прекрасный день Яндекс приобрёл нашу компанию и мы стали сотрудниками Яндекса.
До Яндекса я работал в основном в небольших коллективах. Поднимали большие проекты небольшими силами. В Яндексе я впервые столкнулся с разработкой одного продукта силами 150-200 человек. И вот что скажу: автор статьи говорит правду, называя отдельные недостатки, так оно и есть. Однако, как обычно бывает, это и так и не так. Главная проблема в том что он указывает на “это сделано/работает/устроено вот так”, но совершенно не хочет анализировать: “почему так?”. А так же не пробовал что-то менять.
Я думаю, что проблемы, с которыми столкнулся автор в Яндексе, целиком связаны с самим автором.
Покомментирую тезисы статьи:
Релокация
У меня в отделе работает сотрудник из Иваново. Когда он трудоустраивался, то:
- Ему сняли гостиницу рядом с офисом на пол месяца.
- Назначили и оплатили услуги консультанта, помогающего подобрать съёмное жильё.
- Заплатили комиссию агента (все помнят что когда жильё снимаешь надо ещё эту комиссию платить?).
- Заплатили за пол месяца проживания в новой квартире, которую ему подобрали.
- И ещё сразу после трудоустройства выплатили подъемные.
Когда он отработает год - он ничего не должен Яндексу за весь этот переезд.
Когда-то я приехал в Москву с беременной женой и количеством денег в кармане, достаточным только для покупки обратных билетов. Причём на поезд, не на самолёт. Мы остановились у знакомых на несколько дней и в эти дни нужно было найти работу, снять жильё (при том что денег только на билеты). Я тогда снял в далёком Подмосковье комнату. На работе, на которую я устроился, постоянно проводились технические конференции с кофе-брейками. С тех конференций удавалось утащить пяток бутербродов чтобы поесть что-то вечером…
Днём я штурмовал микропроцессоры, электрические схемы и программы, а вечером… вечером с такими же как я приезжими ставил кондиционеры в квартирах и домофоны в подъездах. А ужинали с женой - вот теми бутербродами с конференции… Если эта конференция сегодня была.
Эх, во времечко было…
Претензия у автора в том, что при увольнении в течение года Яндекс потребует эти деньги назад…
Как бы это сказать. Серьёзная претензия! Эх, мне бы такие серьёзные проблемы когда я приехал в Москву!
Уровень дохода
Яндекс платит ниже рынка.
У меня по жизни как-то легко получалось “продать себя на собеседовании”. Везде где я работал (кроме НИИ, но это - отдельная песня, там работа была настолько интересная, что фиг с ней с зарплатой) я зарабатывал в соответствии с рынком.
Коммуникабельностью меня бог тоже не обделил и где бы я не работал, как-то так получалось, что всегда знал уровни зарплат коллег.
Например, работал я в Mail.RU в разработке БД Tarantool. Было тогда удивительно, что два человека, работающие на одинаковых должностях, занимающиеся примерно одинаковым делом, могут получать вдвое отличающиеся зарплаты.
Сейчас я тоже знаю зарплаты своих коллег. И тоже вижу отличия у одинаковых по уровню/задачам сотрудников. Отличия не такие как были в Mail.RU, но они есть. Эта разница, очевидно, обусловлена поведением кандидата при приёме на работу.
Мы периодически набираем в отдел новых людей. После того, как все собеседования прошли, получено добро: “этого человека можно взять на такую-то должность, такой-то уровень”, то с ним начинают вести переговоры о суммах зарплат. Этим занимаются эйчары. Ориентируются они на уровень-оценку, проставленный на собеседованиях. Совсем недавний случай: с одним сотрудником (тогда - кандидатом) эти переговоры были очень длительные, но он в итоге получил именно такое предложение, какое ему было интересно. Потому что торговался, спорил, отказывался.
Если Вам предлагают ниже рынка - торгуйтесь. Не соглашайтесь. Всё у Вас получится.
Автору надо было написать: Я смог себя продать в Яндекс только по цене ниже рынка, а он написал “Яндекс платит ниже рынка”. Обычное перекладывание ответственности с себя на окружающих.
Cтоит поработать над скиллом коммуникаций на собеседованиях, либо поработать над техническими скиллами (их мы коснёмся ниже). Но он считает что мир (Яндекс) несправедливо устроен. Остаётся надеяться что новое место будет устроено лучше.
Велосипедостроение
Я очень люблю велосипеды. Мы - программисты. Мы должны писать код. Если всё время брать готовые решения, то где программирование-то будет? Когда код велосипеда всего втрое-пятеро больше кода импорта какой-то библиотеки, её инициализации/импорта из неё нужного - я обычно стою за велосипеды.
Заглядывая в PR человека, который притянул целую библиотеку numpy
заради константы numpy.nan мне хочется закричать: “Что ты творишь? Ты
в своём уме?” (но я вежливо пишу ему коммент). Чем не устраивает
прекраснейший велосипед float("nan"), или ещё 100500 вариантов этого
велосипеда?
Или если уж Вы не любите велосипеды, то чтоб не вбить в гугл вопрос “как
определить nan в python”? (Python тут для примера).
Если говорить о “велосипедах” большего уровня чем константа из либы, то здесь играет свою роль множество обстоятельств.
- Обстоятельства исторические: Свой аналог Docker Яндекс делал, насколько я понимаю, ещё в те времена когда Docker’а не было или он в детсад ходил.
- Обстоятельства legacy. Стоимость перехода с решения на решение может быть очень высока.
- Редактируемость. При необходимости можно легко внести изменения в свой велосипед, а вот внесение их в чужой, даже OpenSource могут оказаться запредельно дорогими. и так далее
Mail.RU сделал уникальный проект NoSQL БД - Tarantool. В мире нет второй БД которая может его полностью заменить. Сейчас я в Яндексе местами мучаюсь с MongoDB, которая “не умеет” и десятой доли того что было в Tarantool. Эх.
- Если бы Mail.RU не “велосипедил” по-крупному, то у нас бы не было Tarantool!
- Если бы Яндекс не “велосипедил” по-крупному, то у нас бы не было ClickHouse!
Аналог Docker от Яндекса возможно ещё “выстрелит” и потеснит Docker. Кто знает?
Смотрю на другие внутренние “велосипеды” Яндекс. Вот множество проектов. И всё это множество сталкивается с одной и той же задачей. Например задачей интернационализации проекта. Яндекс запилил свою систему автоматизации труда переводчиков, хранения и работы с переводами. Переводчик, переводя тексты, и не знает нюансов проекта, в который он этот перевод готовит. Этот велосипед позволяет переводчику трудиться над множеством разных проектов. Ответственным видеть прогресс и проблемы… Неужели это лишний велик?
Очень крутой другой внутренний велосипед Яндекса - собственный map-reduce кластер. Можно было взять стандартное что-то? Можно. И на начальном этапе наверно и пробовали…
Часто эти “внутренние велосипеды” в Яндексе - это обобщение множества решений в один подход. В Mail.RU такого вообще не было. Каждый отдел пилил что-то то же самое, но по-своему. И в целом для компании это было хорошо или плохо? Думаю что плохо.
Однако, когда мне не нравится Яндексовый велосипед, я знаете что делаю? Я пилю свой! Я - программист!
Нигилизм и качество кода
Следующее, с чем придётся столкнуться, это отрицание и обнуление всего вашего предыдущего опыта.
О! Знали бы Вы сколько я дрался, да-да, именно дрался в Яндексе за свой предыдущий опыт!
Диалог бизнеса и разработки:
- Бизнес: Нам надо сделать такую автоматизацию. Чтобы делалась вот такая работа, строился вот такой отчёт.
- Я (на основе опыта): Тут работы на 2-3 месяца. Поскольку нагрузки не предвидится, то можно пойти по самому дешёвому пути: сделать вот такой вот монолит.
- Разработка (на основе своего опыта): Но мы будем делать по-другому. Работы тут на год-два.
- Бизнес: Нам срочно надо!
- Разработка: Срочно не получится. Будем делать вот такие вот микросервисы. Год, может быть два. Монолит делать не будем. Точка.
И вот казалось мне, что неправильно это всё. И выглядит неправильно. А вот посмотришь поближе: а почему оно так? Начинаешь разбираться:
Имеется руководитель отдела. Перед ним стоит бизнес-задача. Имеется 15 разработчиков. Многие такие же умные как автор статьи, которую мы обсуждаем, говорят/пишут такое:
Иногда код настолько паршивого качества, что вызывает лишь недоумение: как все эти классные люди написали такое?
И руководитель смотрит на любого из пятнадцати своих подчинённых. Этот любой - классный. Он знает: “как правильно”. И говорит правильно. Нельзя спорить ни с одним словом.
Но всего-то одна проблема у него. Он не знает как вся система целиком работает. И что характерно - не хочет знать.
Ставишь такому задачу: “взять данные отсюда, обработать вот так, положить вон туда”, - справляется отлично! Если целые полгода на него падали такие задачи, то он получит “D” (выше ожидаемого) на ревью!
Ставишь задачу: “самому решить откуда взять данные и куда положить”, – решить не может. Ибо и не знает толком что за проект-то мы пилим. И знать не хочет.
Вот это нежелание знать о системе целиком - есть центральная проблема большой компании (и не только Яндекса).
Я программист, зачем мне знать тонкости бухгалтерии/найма/такси/еды/байды?".
А ведь именно эти тонкости часто определяют архитектуру проекта.
– Почему вот тут сложный такой конвейер из хоровода тасков в очереди?
– Потому что транзакции не можем себе позволить!
– Почему транзакции не можем себе позволить?
– Потому что пользователей у нас 100500, нагрузка огромная - приходится “велосипедить” (шардировать) хранилище. А ещё бизнес требует вот такие действия оформлять именно таким и никаким другим способом!
…
– Архитектура неправильная!
– Архитектура кривая говоришь? Давай я на тебя её разработку скину? Получишь грейд-ап на следующем ревью! Нам вот прямо не хватает человека, который бы думал об архитектуре!
– Ой, это же надо не просто данные из сокета в сокет перекладывать, придётся понимать зачем они оттуда-сюда идут. То есть в бухгалтерию/еду/такси/шмакси вникать. Нет, я не хочу этим заниматься. Я программист, а не бухгалтер!
– Ну ок, тогда идём пока по пути, который видно что приведёт к результату.
Так вот, если вернуться к моим спорам про быстрый (в разработке) монолит vs долгие микросервисы.
- Чем хорош монолит?
- Можно быстро сделать. Быстро поменять в нём что-то.i Тестируется легко и просто.
- Чем плох?
- Разработчик более-менее должен знать к чему и зачем нужны все его части.
А разработчики дистанцируются (дистанцируются, Карл!) от такого знания.
- Чем хороши микросервисы?
- Тем что каждый решает мелкую задачку. Что делает микросервис можно понять просто глядя в его код. Можно разобраться в нём и исправить ошибку, даже не понимая зачем он глобально нужен!
И теперь смотрим на наших классных 15 разработчиков. Которые не хотят знать чего-то больше работы “сказали-сделал”. Какой дорогой их отправлять? Конечно микросервисной: каждому раздать по законченному маленькому заданию - и каждый его выпилит. Потом это всё соединится в куче и полетит. Да, разрабатывать дольше. Но зато требования к кадрам существенно ниже!
Кадры решают всё! (И.В. Сталин)
Возвращаясь к эпиграфу. Профессии “программист” не существует. Программист - всегда смежник. Если ты программируешь игры, ты должен разобраться в принципах построения игр, дизайна. Если программируешь бухгалтерию - стать немножко бухгалтером. Такси - таксистом итп
Ещё цитата, которую хочется прокомментировать:
А ещё очень много проектов, которые собираются и запускаются только на Linux. Если у тебя Mac, то есть хоть какая-то надежда, а вот с Windows её вообще нет.
Я понемногу пришёл к тому, что новых сотрудников я просто не буду брать, если они на собеседовании скажут что “мой рабочий стол на Windows”. Или на Mac.
Почему? Потому что я преодолевал это некоторое количество раз. Тратил на это много сил.
Пример из жизни:
- Имеется написанная система.
- Скрипт, докер, который позволяет всю написанную систему запустить локально: нужно всего-лишь установленный Docker локально и всё. Остальное скачается запустится и можно работать.
Представляете для большой системы сколько труда вложено только в то, чтобы вот взять и копию развернуть в докерах локально?
И вот приходит человек:
– У меня не запускается на Mac.
– Давай разбираться… Хм, оказывается отображение портов докер-хост на Mac работает по-другому чем на Linux. Mac - юникс, но что-то в нём да другое… Давай попробуем чуть переделать (чтобы у всех прочих разработчиков не сломалось, а у тебя заработало).
– Всё равно не работает.
– Ок, погуглим ещё. Ага, тут ещё одна тонкость докера на Mac.
– Вроде заработало, спасибо!
И вот что сильно угнетает: человек в процессе адаптации системы под него проявляет крайнюю незаинтересованность. Он-де программист на Python/JavaScript/C++, а разбираться в Dockerfile’ах/bash-скриптах - это не его.
Mac только у него (у остальных - Linux). И залезть поправить bash-скрипт он сам не хочет. “Сделайте мне чтобы работало”.
Однажды я в сердцах сказал:
– ну раз не получается, отправь заявку в helpdesk поменять Mac на Linux.
И только такое действие заставило человека покопаться самостоятельно в проблемах Docker на Mac.
А затем следом пришёл второй:
- А у меня Windows, мне что делать?
В Яндексе разрабатывают ПО на Ubuntu. Внутренние пакеты собирают для Ubuntu. А я, исторически, живу в другом дистрибутиве. Свои проблемы от “другости” этого дистрибутива я решаю сам. Проблем этих бывает много.
Но почему-то многие считают, что это должно быть по-другому. Что руководство/коллеги должны решать их проблемы. Этого я не понимаю.
Ревью и премии
И здесь ты попадаешь в замкнутый круг: задачи тебе приходят сверху, и ты их не выбираешь. Даже, если задача дерьмо, ты будешь её делать. Отказ клеймит тебя человеком, нелояльным Компании. Попытка что-то доказать делает тебя токсичным, что тоже клеймо. Ну вы понял…
Я не боюсь быть токсичным. Я воюю, спорю, иногда на “материнском языке” разговариваю. Эскалирую, договариваюсь, итп
С “дерьмо”-задачами я не сталкивался.
Бывает, что обстоятельства заставляют идти к цели более длинным путём, чем можно. Когда растолкуешь что есть более короткая дорога - обычно можно следовать ей.
Иногда, в процессе растолковывания, сам поймёшь все обстоятельства дела и поймёшь почему решили идти этим, а не иным путём.
Когда “разбиваем нос”, не ленюсь сказать “видите? а я ведь предупреждал!”.
Вот эта цитата (и вообще весь текст статьи) говорит о том, что автору неинтересно пытаться что-то менять. Что на работу он ходит чтобы эту работу поработать, зарплату получить и адью.
Да, многие имеют такое отношение к работе. Это не уникальное явление. Многие (и автор - не исключение) именно потому и страдают.
С подходом “я делаю (только) то, что мне сказали и не обсуждаю” и будешь делать что сказали. Будешь заниматься “дерьмо” задачами.
Какая лошадь как везёт, такую лошадь так и грузят!
Заключение
На работе мы проводим половину жизни. Дома - другую половину.
Когда дома нас не устраивают обои, кровать, сантехника, мы делаем ремонт. Улучшаем нашу жизнь дома. Когда на работе нас что-то не устраивает - почему не вести себя так же?
- Плохой код? - предлагай как улучшить. Сядь полчаса выдели на прототип. Мало полчаса? Полчаса в день выдели на протяжении недели.
- Тебе в Windows/Mac плохо? - Переходи на Linux или допиливай инфру для Windows/Mac. Сам.
- Велосипедно? - Разберись: почему оно так? Может этому есть основания?
- Токсично выглядеть боишься? - перестань! Умеющего за дело послать на три буквы начальство часто больше ценит!
Активная жизненная позиция на работе:
- и сделает работу интереснее
- и позволит зарабатывать больше (как-то само образуется, поверьте)
Я уверен, что на новой работе у автора (будут) примерно те же проблемы что были в Яндексе. Просто развёрнуты другим ракурсом.
Как говорится: та же ж… только вид с другой стороны.