среда, 24 мая 2023 г.

Моё прощальное письмо

При трудоустройстве я выбрал компанию Госуслуги. Вернее дочку Ростелекома, которая делает госуслуги - ртлабс. Вернее подрядчика ртлабс. По зарплате мне в ней предложили примерно на 30% меньше, чем в других местах. Но я захотел сделать что-то полезное. Вообще, как мне кажется, Госуслуги - это немногое хорошее, что произошло с нашей страной за последнее время.

И вот я разочаровался. Tldr; думаю, что в эту контору надо нанять не хорошего программиста, а хорошего психолога.


Не думаю, что у меня есть шанс что-либо исправить. Всему виной - принцип Питера. В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности. В госуслугах не принято брать людей со стороны - принято "растить" своих. В результате многие должности заняты поднявшимися до уровня свой некомпетентности людьми. Некомпетентными людьми, людьми не на своём месте. Я пытался, но ничего не смог сделать. В какой-то степени это напоминает Советский Союз. Там тоже людей с работы не выгоняли. Наверх людей двигали снизу. Продвижение считалось успехом и к нему все стремились. И... он развалился. Почему продвижение своих плохо? Ну просто потому что быть разработчиком и быть руководителем - это совершенно разные вещи для которых нужны совершенно разные качества. Следовательно хороший, успешный разработчик может вполне и не стать хорошим начальником, и наоборот - плохой разработчик может быть хорошим руководителем. Просто в жизни надо делать, что нравится, а не ползти наверх, и считать, что продвижение наверх есть успех к которому надо стремиться.

Лид

В первый день работы мой лид сделал мне некую "презентацию" проекта. Более ужасной, сумбурной и непонятной речи я в своей жизни никогда не слышал. Ладно думаю - человек был занят, немного подзабыл, что в пятницу выходит сотрудник, немного не подготовился. Завтра соберётся с силами и всё расскажет. Завтра не настало - завтра он был занят "фиксом мега важных багов". И послезавтра. И потом. И всегда. Налаживание процесса разработки, улучшение качества кода, документация, метрики, разработка нового функционала - не, не слышали такого, у нас же есть миллион "мега важных багов, которые мне скинул женя", которые надо было срочно пофиксить вчера - это моя обязанность, буду чинить по ночам, на выходных, с пролетарской ненавистью. Я пытался - я предлагал назначить дежурного на которого все будут скидывать все проблемы, который будет всё разбирать, проводить первичный анализ всех 3лп, срочные чинить, несрочные отдавать в спринт. Адская работа, но позволила бы разгрузить остальных членов команды и дать им работать в нормальном режиме. Позволила бы очень быстро влиться во все тонкости. Предлагал себя. Нет. Нам этого не надо. Мы не будем назначать одного дежурного. Мы будем накидываться на каждую проблему все вместе - всей командой. Мы не будем работать над тем, чтобы проблем стало меньше. Мы просто будем их чинить.

Вечно перезагружен процентов на 300. Дайте это мне. Давайте я это сделаю. Запишите это на меня. И не делает. И все знают, что не сделает. Всё что делает делает по принципу допинать, как-нибудь. Может из-за того, что торопится, может просто характер такой, может привык - пофиг.

Замечание для себя на будущее - гнать ссаными тряпками безграмотных людей. Если человек не умеет грамотно писать на своём родном языке - хорошего от него не жди.

ЗЫ: этого лида убрали. Я ему сначала пытался намекать о том, что он делает не так и как надо. Потом говорил, потом ругался и уже планировал пойти на него жаловаться, но он сам ушёл.

Код

Посмотрел на код. Код, конечно, полное говно. Объектно-ориентированный подход, инкапсуляция, solid - нет, не слышали про такое. У нас есть сервисы и DTO. Какие-то хитрые правила, неочевидности, нетипизированные константы - одним словом мины в коде. Пока в метод не сходишь, ни за что не догадаешься что он делает. Асинхронно что-то обрабатывать - не, мы так не делаем, мы из лихих девяностых - мы всё в одном потоке. Вместо разделения по бизнес логике имеем невнятное разделение по назначению. Это примерно как если бы всех программистов в один отдел, а тестировщиков в другой. Связи ужасные. Начинаешь что-то тянуть и из него вываливается всё остальное. Тестировать невозможно. Существующие тесты даже не компилируются. Ладно думаю. Код, конечно, говно, но дело то хорошее. Сейчас напишем нормальные функциональные тесты. Это развяжет нам руки, даст возможность быстро релизы выводить. Порефакторим. Есть над чем работать - там вроде есть безлимитный гэпс, много нужной, хорошей работы. Сначала всей командой накинулись "нахер нам тесты". Ну вроде удалось убедить - типа это вообще требование сверху. Написал функциональные тесты, настроил cicd.... И всё. За пол года не появилось ни одного нормального функционального теста. Конечно, зачем нам тесты - мы же все фиксим баги, чиним 3лп. Что характерно - у меня есть стойкое подозрение, что никто не считает код гепса говённым. Ну да, есть ошибочки, но в общем - всё збс. То есть чтобы что-то сделать надо сначала научить людей нормально программировать, чтоб они прозрели, потом рассказать как надо, и только потом браться что-то переделывать.

Архитектор

Архитектор вечно занят разгребанием проблем, которые ему по дружбе скидывает женя. Ничего, что его месяцами ждёт команда из 4 человек. Женя - друг - ему нельзя отказать. Подождут. Из моего опыта архитектор в команде - это полная хрень. Например он рисует розовые облака. Ты начинаешь реализовывать и выясняется, что он что-то не дорисовал. Идёшь к нему, а ему твои земные стоны по барабану - он живёт в мире розовых пони. Обычно эти походы к архитектору заканчиваются тем, что тихо забывают о розовых облаках и делают как смогли, без похода к архитектору. Но у нас ещё проще. Один поход к архитектору занимает 4 месяца - да - именно столько времени нужно, чтоб он нашёл время в своём плотном графике и ответил на вопрос. Документации нет, архитектуры нет - за что этого человека называют архитектором?

Замечание для себя на будущее - никогда не работать в компаниях, где в команде есть архитектор.

CTO

Ну и вишенка на торте. Когда CTO 12-летней государственной компании после получения штрафа на 90 млн. приходит и начинает всех нагибать за метрики - это уже кранты. Мужчина, эти метрики должны были появиться 12 лет назад  - в момент, когда MVP получил гос финансирование и стал гос. проектом. Это ваша прямая обязанность - тесты, метрики, документация - обязанность CTO всё это иметь, всё это проверять, всего этого добиться. Сразу. Да, можно налажать с технологиями - нанять неправильных людей в RnD, они могут предложить что-то с чем все намучаются и откажутся. В моём опыте были очень неочевидные моменты при выборе технологий - например в какой-то момент вся команда топила за mesos, потому что на тот момент он уже был, успешно использовался и у всех был опыт работы с ним. Через пару лет стало очевидно, что использовать mesos вместо k8s было бы ошибкой. Но есть какие-то базовые вещи - метрики, тесты, документирование, обеспечение надёжности и качества, стресс тесты. Просто человеку сложно выйти за свои маленькие рамочки - ты всю жизнь работал на одном месте, ничего не видел другого.

Команда

Я до этого 5 лет работал на удалёнке в компании, где офис находился не в россии. Но такой отчуждённости нигде не было. Видео никто не включает - я ни разу не видел людей с которыми работаю. Ни шутки ни от кого не услышишь. Поговорить, обсудить - не, это не у нас. Чё-то это даже для меня перебор. Обмен опытом, обсуждения какие-то - не, это не к нам.

Думаю проблема в пирамидной иерархии, тем, что люди считают, что чем выше они поднялись - тем лучше, тем, что понижение в пирамиде люди будут считать наказанием. Ну и в доброте - все вроде видят - человек не справляется, но дают ему ещё один шанс, помогают расти. Всё как описал Питер Лоуренс. Надо выходить за рамки пирамидки-компании, надо делать это постоянно. В японии например тоже человек женится на компании. Но в процессе работы его, независимо от его показателей и видимой "успешности" ротируют по разным местам - смотрят, как он будет себя проявлять в разных ситуациях. Там, сям - в продажниках, в поддержке, в разработке, в управлении. Спрашивают его - что ему больше нравится. Что, на мой взгляд, могло бы помочь. Нужна более жёсткая ротация - как внешняя, так и внутренняя. Надо стараться набирать лучших из лучших людей со стороны. Надо перемещать людей из одних  команд в другие, чтоб они несли свой опыт или набирались его. Но это уже совсем не моя зона ответственности.

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

Команда 2

Как я уже упомянал, у нас есть большие проблемы с т.н. soft skills. Изначально я выделял коммуникацию. Но было несколько звоночков, которые навели на некоторые размышления. Например в однолассниках ещё во время найма мне сообщили "мы не делаем херни. Да, мы специально набираем ответственных людей и ждём от них самостоятельности. Тебе могут дать задачу сделать херню. Твоя задача понять, что это - херня, донести до нужных людей мысль, что это - херня и не делать её, а сделать нормально." А тут меня начали терзать сомнения. А у нас вообще люди понимают, что мы делаем, зачем, почему и как мы должны это делать. Поэтому я задал вопрос на ретро "кто-нибудь понимает вообще, какие у нас есть цели, как у команды. Не те говно-показатели, которые нам на квартальном планировании спустили, а некий вектор, которые не должен меняться от квартала к кварталу." Молчание было мне ответом. Я, в принципе, понимаю ребят из QA (нет, но в некотором приближении) - они думают, ну а чё мы - мы берём задачи из пула в порядке приоритета и тестируем их - вот и вся наша работа. Я, в принципе, понимаю РП - станартный эффективный менеджмент. Вот есть ресурс, вот есть задача. Надо выполнить задачу ресурсом за ресурс "время". Но devs... . Конечно возможно у меня профессиональная деформация - я почти всё время работал в иностранных компаниях и один раз во флюродросной нашей. Ну иностранцы - они помешаны на целях, на планах, вектор развития, вот это всё. Там постоянно этим накачивают, хочешь - не хочешь какое-нибудь понимание целей команды появится. В одноклассничках тоже с флюродросом было всё в порядке. Ну собственно это следствие медийности компании. Но никто ничего не смог сказать. Ну то ечть это что получается - люди ходят на работу, чтобы работать свою работу и получать за это свою зарплату плюс премии. Хорошо. Но тогда почему никто не подыщет себе более высокооплачиваемую работу. Вроде после ковида почти везде удалёнка - устраивайся хоть в московскую контору, хоть в новосибирскую. И почемку я не должен перейти в другую компанию, где мне придложат на 30% больше. Я чтож, один такой Иванушка - дурачёк, который работает потому что ему нравится идея госуслуг и нравится делать жизнь простых людей удобнее. В принципе это объясняет почему у нас метрик нет, а разбор 3лп мы начинаем с jfr.

Ну как бы это точно не та вещь с которой я могу жить. И точно не та вещь, которую я могу исправить. Быть нянечкой для группы инфантилов "ой, а мы не знаем, пусть господин министр установит нам правила, мы будем им следовать. Ой, а пусть нам в цели добавят статистику, тогда мы её сделаем, если сможем, только пусть нам Лёша анализ сделает и нарежет всё на мелкие, понятные задачки, которые в спринт влезают. Ой, а пусть нам господин министр разрешит техдолгом заниматься и поставит это в квартальные цели, а то мы сами то не можем. Ой, это задача архитектора, ой это задача тим лида."

То есть если надо что-то сделать, то надо это сделать в одиночку, в свободное от запланированных на квартал задач время, принять кучу херов на свою голову из разряда "пачаму ты не обсудил это с командой", и потом одному это тащить, потому что да, все понимают важность и необходимость, но делать не будут потому что "это не прописано в планах, а пусть кто-нибудь придёт и сделает это нам, мы думаем это должен быть ХХХ". Ну ладно один раз. Но так было с тестами, с документацией, с метриками, с opentracing, с качеством кода. Ну и я как бы не знаю что можно сделать с этим командным инфантилизмом. И надо ли вообще что-то с этим делать - госулуги работают, развиваются, появляются новые сервисы. Может дело во мне - просто это я не совместим, а у всех всё хорошо.

Резюме

1. Мотивация - основной целью в гэпс является полчение премии, то есть бабло. Если мотивация - бабло, то почему вообще надо работать в госуслугах - в предыдущей конторе я получал в три раза больше, почему бы туда не вернуться

2. Организация работы. Есть воспитатель Лёша, который делает анализ, тех проектирование, декомпозицию. В общем 90% работы делает Лёша. Все остальные опускаются до уровня кодировщиков. А за оставшимися 10% опять приходят к Лёше, когда в процессе кодирования что-то не срастается и Лёша вытирает всем сопельки. Детский сад. Несколько раз говорил, что такой подход - херня.

3. БГ. Ну БГ был коммуникационным кошмаром с самого начала. С тем подходом, который придумал Лёша и одобрил Женя всё затянется ещё сильнее. Нам дали 2 месяца, они уже прошли, а мы ещё даже ничего не начинали. РТЛабс, конечно, от этого не развалится, рано или поздно все переедут на кассандру - через годик что-то сделают, через полтора запустят, года через два окончательно переедут. Несколько раз говорил - это херня.

4. Подход к разработке - Женя даёт задачи, иногда важные и полезные и хочет абсолютно невозможного - чтобы их допинали до продакшена за два дня. В результате выходит полное говно. Вредное, неработающее говно. Так было с open tracing, так было с PMD, так было с epgu-kafka-spring-boot-starter. То же самое будет с тестами - напишут очередное бесполезное говно. Покроют одно говно другим на 60%, чтоб получить премию. Жалкое зрелище, не хотелось бы на это смотреть. Тут даже сказать нечего и некому.

5. Ну как бы можно было работать. Делать то, что считаешь нужным с максимальной отдачей. Но как-то я слишком молод для всего этого. Вот лет через 10, когда мне стукнет 60 и когда я начну забывать в какой стороне находится тулает, то можно будет вернуться в госуслуги мирно доживать до пенсии и пытаться не растерять остатки мозга. Но думаю годика через два всё это станет не важным - появится какая-нибудь очередная LLM GPT-6, загрузим в неё наш код, она нам его исправит, напишет тесты. И будем ей писать ТЗ, а она нам будет писать всё остальное.


вторник, 16 мая 2023 г.

Неформатированный список материалов для Яндекс собеседования

Общее описание всех этапов

Более подробный Notion в Яндекс.Облако с этапами, примерами задач, материалами для подготовки


Про архитектурную секцию

Предстоит определить и сформулировать функциональные и технические требования, спроектировать высокоуровневую архитектуру, детально описать один из компонентов, оценить вычислительные ресурсы, необходимые для полномасштабного внедрения. Пример такой задачи: спроектировать сервис Яндекс.Такси. Как правило, задача формулируется в очень общих чертах, поэтому здесь важна активная коммуникация: задавайте уточняющие вопросы, выдвигайте обоснованные предположения и идеи, аргументируйте свою точку зрения. В процессе беседы вам может понадобиться описать потоки данных в системе, API, определить ключевые алгоритмы и структуры данных или описать структуру таблиц в СУБД, набросать черновик реализации одной из частей. Кроме проектирования ядра системы, важно определить ее структуру и топологию в целом: балансировку нагрузки, сценарии отказов и соответствующих защитных механизмов, нюансы эксплуатации, способы и методы контроля штатного функционирования системы.

Для подготовки к архитектуре:

Тут написано в общих чертах, что будет на секции (смотри пункт 3)

Как проходят архитектурные секции (habr)

Опыт разработчиков (habr)

Гайд про архитектуру - System Design Primer (полезные шаблоны, много полезной информации, обзорно)

Числа, которые точно нужно знать

Видео с полезной информацией про архитектурную секцию


На секции не обязательны инструменты для рисования, но если вам понадобятся, то вот примеры

Доска (Майкрософт)

Miro

Web whiteboard (powered by miro)


Какие материалы можно использовать для подготовки (ссылки невозбранно вырезаны из статьи с хабра):

Книги

— Эндрю Таненбаум — Распределенные системы. Принципы и парадигмы

— Брендан Бёрнс — Распределенные системы. Паттерны проектирования

— Martin Kleppmann — Designing Data-Intensive Applications

— Бетси Бейер, Крис Джоунс, Дженнифер Петофф, Нейл Ричард Мёрфи — Site Reliability Engineering. Надежность и безотказность как в Google

— Computer Architecture, Fifth Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design) by: John L. Hennessy, David A. Patterson Amazon

— Designing Data Intensive Applications

— Databases by Korth

— Clean Architecture

— DDD (красная, зелёная, синяя - Эрик Эванс Domain Driven Design)

— Cracking Code Interview (там есть глава про System Design)

Доклады

Видео с докладами с любых конференций по высоконагруженным системам, например HighLoad++.


Некоторые команды

Yandex Platform Engineering

Audit Services в Yandex.Cloud

Identity & Access Management в Yandex.Cloud

Биллинг и Директория 360

Телемост

Диск

ML-сервисы Yandex Cloud

Managed Kubernetes в Yandex Cloud, notion


И ещё

Как получить офер в Яндекс за 1–2 дня

Яндекс диагностика


понедельник, 15 мая 2023 г.

Обо мне

Личное

У меня есть три темы для разговора - смысл жизни, воспитание детей и на худой конец айтишечка (если не удалось найти общего по первым двум)
Раньше я занимался капоэйрой и танцами, но бросил. Планирую опять начать (уже три года как).
В детстве мечтал потолстеть, теперь мечтаю похудеть
Характер у меня не очень, но это не проблема - я считаю, что быть говном не зазорно, зазорно говном оставаться, к тому же я - жадный шопоголик
Не люблю верить в "шанс" - мне больше нравится считать, что случится то, что должно случиться
Ценю необычность взглядов

Профессиональное

Не люблю spring и микросервисы. Первые за то, что уменьшеают объём boilerplate code, но не порог вхождения. Последние в основном за то, что народ пытается возвести их в ранг серебряной пули и пихает не в дело. Но это пройдёт.
Люблю порядочек и контроль. Хлебом не корми - дай что-нибудь причесать
Ценю умение идти в проблеме до конца
Не люблю делать одно и то же несколько раз (детей двое)
Пытаюсь научиться в ML (примерно 8 лет, пока безуспешно, но я надеюсь)
Считаю, что в команде полезен туповатый старичок, который будет постоянно говорить "А это непонятно, а давайте сделаем попроще". Ну вы понели
Почему-то меня привлекает всякая перепрошивка устройств и настройка сети типа iptables - может потому что мне это кажется очень сложным
Выбрал YPE потому что хочу как можно лучше познакомиться со всем Яндексом
Надеюсь, что окажусь Я-у полезным и надеюсь, что Я даст мне возможность сделать что-то полезное для людей
Перешёл на тёмную сторону