Возвращаясь к айтишному.

Последние полгода были интенсивными и интересными. Так получилось, что тот продукт, который я делал решили вывести в отдельный продукт и вокруг этого всего было много разной работы.

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

Доки на архитектуру пока нет, потому что как обычно бывает, всегда есть куча мелких вещей и багов, которые надо починить перед релизом.

Так получилось, что у нас было два внутренних релиза, которые мы релизили в пятницу вечером и недавно у нас даже было разделение на два лагеря. Одни были за релизы в пятницу, другие были против.

Учитывая, что продукт всё равно не будут деплоить в пятницу то в нашем случае в пятницу релизить можно. Да и в целом, я любитель подеплоить в пятницу, потому что это показатель того, как хорошо у вас устроено качество, процессы разработки и в каком состоянии система.

За это время я даже смог прочитать несколько книг

-- Переиздание программиста прагматика спустя 20 лет
-- Staff Engineer. A leadership beyond management ladder.
-- Перечитал книги Жоко Виллинка (Discipline equals freedom & Extreme ownership)

Сейчас на очереди Non-violent communication.

Вообще о чем написать? Какие предложения? Как часто выкидывать посты и на какую тему?

Кто релизится в пятницу -- тот не лох 😂

Пятничные релизы часто почему-то не любят люди, потому что впереди выходные и если что-то сломается, то будут выходные на то, чтобы всё починить.

Однако, если команда может релизнуться в пятницу -- значит она не боится этого релиза и это значит, что всё хорошо с процессами разработки и тестирования.

Отвечая на комментарий под предыдущим постом мы релизнули Everest. Это система для того, чтобы сделать Private DBaaS поверх кубера. Доки доступны тут https://docs.percona.com/everest/

На следующей неделе будет контент в целом с описанием архитектуры, решений и прочих вещей, а пока можно потыкать и поиграть.

PS. Можно на локалхосте поковырять с посощью k3d и вот этой инструкцией. Немного мануальных шагов, но всё остальное будет автоматически установлено.

В следующих постах я распишу технические кишки чуть подробнее и думаю это займет пару больших постов как минимум. Может оказаться, что будет интересно

Так получилось, что в мае у нас был пивот и мы решили поменять все планы и начать разработку нового продукта.

С одной стороны, когда Эверест был частью PMM (Percona Monitoring and Management) это было логично, что DBaaS фичи -- это часть менеджмента. Но было непонятно как поженить User Experience этих двух продуктов, учитывая что PMM всё таки заточен больше на мониторинг.

У нас было несколько проблем с PMM

-- Из-за того, что это было web based решение, а установка всех компонентов в худшем случае могла занять до 5-10 минут, то у нас были некоторые баги с этим. Да, мы делали процесс максимально повторяемым, но контроля таки было мало и в итоге кубер кластер мог зависнуть в Provisioning стейте
-- Помимо этого, для установки всех компонентов (а нам надо ставить OLM, устанавливать каталог, ставить все остальные операторы, конфигурить мониторинг), то нам требовалась очень большая кластер роль для кубера ради одноразовой операции
-- Бекапы и ресторы было сделать сложно, учитывая что в PMM есть часть функционала вокруг этого, которая реализована для bare-metal со своей логикой и хранением метаданных, то добавить кубер было прям задачей со звездочкой.
-- UX в целом страдал, потому что это было спрятано как фича в tech preview, которую еще и найти надо.

Благо, что в начале года мы делали мелкие шаги по выносу в отдельный продукт. Думали над архитектурой и UX, обсуждали как сделать те или иные вещи удобнее и понятнее.

Спустя пару Proof of Concept мы таки пришли к выводу, что нам нужен свой бекенд и CLI.

Основная CLI -- провижионить кубер класстер и ставить все нужные операторы и компоненты, которые нам нужны для нормальной работы продукта. В течение этого процесса создается сервис аккаунт в нужном неймспейсе с лимитированным списком пермишнов, которые как раз нужны для нормальной работы продукта.

CLI помог решить несколько проблем. Во-первых мы стали следовать least privilege принципу. Во-вторых, процесс установки можно сделать синхронным с понятным фидбеком пользователю что сейчас происходит с кубер класстером и процессом провижионинга.

CLI умеет доставлять отдельные операторы, включать или выключать мониторинг и для установки мы сделали быстрое решение -- это install скрипт.

Это не единственное принятое архитектурное решение и дальше расскажу про бекенд

Бекенд.

Основная боль разработки была в перекладывании жсонов с места на место. Мы получили с фронта один жсон, покрутили и повалидировали его, собрали из этого жсона другой жсон, который закинули в кубер кластер и проверили статусы ответа.

В целом ничего нормального, кроме того, что в целом весь бекенд состоит из этой логики.

Появилась гипотеза проксировать специфичные запросы в кубер с фронта или как-то заэкспоузить кубер класстер на фронт.

Однако, нельзя так просто взять и заэкспоузить апиху кубера на фронт, потому как будут проблемы с CORS, но запроксировать ее можно и для этого в Go есть httputil.SingleHostReverseProxy, с которыми вполне удобно работать.

Первый Proof of Concept был вокруг того, чтобы сделать эту проксю, попробовать подцепить фронтовое приложение и посмотреть как оно будет работать. В целом достаточно просто и в первой версии вся куберовская апиха была доступна для фронта.

Однако, когда мы начали дизайнить рестовые эндпоинты, дизайн собственных эндпоинтов отличался от куберовских и появилась идея для другого PoC. Суть в том, что по-сути нам нужно выдать на фронт апиху, которую регистрирует в кубере наш оператор.

Во время разработки оператора всегда генерируется openAPI спецификация для нужного CRD и появилась идея просто взять эту спецификацию и задизайнить свои эндпоинты используя сгенерированную спеку как пейлоад. А на хендлере можно и логику с проксированием запилить.

В итоге, получилась вполне понятная апиха с разным пейлоадом и доку можно потыкать тут.

Под капотом спека и пример DatabaseCluster, а реализация тут

Этот подход помог нам избавится от кучи ненужной работы и ненужного (пока что) уровня абстракции.

Плюс, мы можем спокойно повалидировать то, что пришло в пейлоаде и выдать осмысленную ошибку до отправки в кубер кластер.

Ну а в следующем посте соберу всю картину воедино.

Ну и как вообще Эверест выглядит изнутри?

Пока пишется документация на сайт с объяснением всех компонентов, запощу сюда архитектуру текстом. Может быть даже будет полезно кому-то.

1. everest-operator. Основная логика вокруг day 1/day 2 операций реализована в операторе. Он предоставляет свою CR, в которой есть всё нужное и оно унифицировано для трех технологий: Postgres, MySQL, Mongo. Плюс всякие удобности для UX и дополнительная автоматизация лежит там. Некоторые правила валидации реализованы на стороне оператора, но пока большую часть приходится делать на бекенде, потому что ждём когда 1.24 таки умрёт везде, потому что в 1.25 появились validation rules
2. everest-backend. Это апиха для фронта, которая очень простая и особо не содержит никакой логики для day 1/ day2 операций. Правда он создает какие-то нужные ресурсы в кубер класстере. Например объекты для хранения конфигурации монитооринга или бекапов. Большая часть эндпоинтов -- это простая прокся до кубера, иногда с небольшой кастомной логикой перед проксированием
3. CLI, который занимается установкой Эвереста и всеми SREшными делами. В планах вроде есть достигнуть паритета с WebUI, чтобы можно было управлять кластерами баз данных и подобными вещами. Он ставит OLM, Everest Catalog, все нужные операторы, конфигурирует и доставляет мониторинг кубер кластера.
4. OLM (Operator Lifecycle Manager). Оператор, который устанавливает другие операторы. Ставит дополниительно кучу дополнительных удобных вещей. Информацию об операторах забирает из Каталога
5. Everest-Catalog. Это просто хранилище метаданных о доступных операторов для установки.

Версионирование.

Хоть мы пока не поддерживаем автообновление, но мы можем без проблем сделать его в следующих релизах. Какие были приняты решения

1. Мы версионируем CLI, Backend, Frontend, Operator и Каталог релизным тегом и пушим всё на докерхаб
2. Во время апгрейда эвереста нужно поменять каталогсорс в кубере и обновить версию. Это позволяет нам шипить поддерживаемые операторы и быть уверенным, что в 0.3 люди не получат операторы с 0.4. Из всего версионирования именно эта задача была самой сложной, потому как со всеми остальными компонентами всё более менее понятно.

Процесс апгрейда

Если мы релизнули новую версию Эвереста, то пользователю нужно выкачать последнюю версию everestctl и в идеале запустить что-то типа everestctl upgrade. Эта команда должна через интерактивный процесс сделать следующее

1. Спросить и обновить OLM в кубер класстере
2. Обновить каталог сорс и подождать когда будет доступна новая версия каталога в кластере
3. Предложить обновить все операторы и если пользователь согласен, то обновить их. Сам процесс обновления операторов простой и его можно сделать без каких-либо проблем, потому как нет никаких сайд эффектов
4. Обновить версии в композе или в кубер манифесте и выкачать новые образы
5. Обновить конфигурацию мониторинга

В целом, хоть продукт пока еще в альфе, но это вполне себе хороший старт. Правда пока не понятно как запилить IAM, RBAC фичи, но мы точно в следующем квартале что-то придумаем.

Staff Engineer: Leadership beyond the management track

Небольшие заметки про книгу.

Обычно, когда опыта у разработчика 5, 7 или больше 10 лет и при этом он сеньер как по выслуге лет, так и по подходам, майндсету и подобным вещам. Становится непонятно куда вообще расти дальше и где больше денег можно взять за свои скиллы.

Есть два стула три карьерных трека:

1. Уход в пипл менеджеры
2. Уход в архитекторы
3. Уход в принципалы

Менеджерский трек не всем зайдёт по разным причинам. Мне не зашло, потому что я люблю что-то программировать, решать задачи и подобное. А люди... Люди они сложные, непонятные и вообще непредсказуемые в отличие от кода/железок/систем.

Архитектурный трек это чаще всего про то, чтобы думать долго, описать всё это на бумаге и диаграмах (очень утрировано) и мыслить как всё это барахло, которое пишется погромистами будет работать в масштабах организации

Принципалы. Это вообще хрен пойми что за люди.

Книжка оказалась полезной и наверное будет настольной в ближайшее время. Staff+ инженер включает в себя следующие роли: Staff, Architect, Principal. Разница только в области, которую нужно грести.

В книге рассказывается что эти роли разные в разных компаниях (да неужели) и что от места к месту тайтл может быть разным.

В отличие от сеньера, staff это где-то плюс 20% к зп но если кратко посмотреть и попробовать описать -- это что-то вроде техлида (а у техлида есть ток техническое лидерство и нет пипл менежмента). Только техлидить нужно несколько проектов/комманд

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

А я пока хз стоит ли идти в эту ветку или нет. В целом техлидить/сеньорить нормально

Non-violent communication.

Наконец дошли руки начать читать Non-violent communication. Книга хороша и понравилась вот эта мысль в самом начале книги

As NVC replaces our old patterns of defending, withdrawing, or attacking in the face of jugment and criticism, we come to perceive ourselves and others, as well as our intentions and relationships, in a new light.

Вообще с темой миролюбивой (ненасильственной) коммуникации впервые я столкнулся, когда учился менеджменту в Стратоплане. Правда, там было больше про безоценочное общение, чем про сами практики NVC, но всё же, этот курс прокачал коммуникацию достаточно хорошо.

Если кратко про безоценочность, то там есть несколько вариантов

Идти в сторону фактов и уходить от оценок и обобщений.

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

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

Фокус на проблеме, а не на человеке

Хорошая вещь, которая помогает как раз таки выключить механизмы защиты и сфокусироваться на обсуждении проблемы с которой столкнулся человек, а не на обсуждении самого человека, что как раз таки включит эти все механизмы.

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

Страданий псто.

Решил я тут попробовать сбилдить на своем маке с arm процом парочку C++ проектов, почитать их код и вообще посмотреть на внутряковые реализации парочки баз данных: Postgres и Mongo.

Последний раз я компиляцией и подобными вещами занимался в году 2009м, когда ковырял TrinityCore или сидел на Gentoo.

Кажется, что мало что поменялось за это время по экосистеме C++. Ниже просто вопросы от человека, который хочет вкатиться в C++ в 2023.

1. Почему нет никакого менеджера зависимостей, чтобы можно было добавить их как-то автоматом и не складировать это в third_party. В Go от этого избавились с помощью модулей. В Python был pip с кучей оберток вокруг него. В php есть композер.

2. Выбрать редактор текста, который может поддерживать основные три инструмента вокруг автоматизации -- боль. Clion не поддерживает Scons, VSCode не может найти инклуды в includePath, пока качаю XCode

3. Линкеров туева хуча. Gold, lld, bfd, clang, clang++ и попробуй найти тот, который заработает на маке для его Mach-O. Gold, lld только для ELF. После перебора вроде как стало понятно, что можно использовать clang и оно даже будет работать. Bfd жрет кучу памяти и тормозит.

4. Но не особо долго, потому что оказывается нужен еще llvm, добавив который появились ошибки компиляции, которые решаются даунгрейдом SDK с 14 на 13. А как это сделать в Scons я пока не нашел, но решил скачать XCode

5. Для Cmake это было сделать просто через set(CMAKE_OSX_SYSROOT "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk")


Кажется зря я забросил C++ лет цать назад. Сейчас вообще фиг разберешься в экосистеме.

Вайлдберрис — контора пидорасов.

Нет, не хочу тут оскорбить геев и ЛГБТ сообщество. Пидорасы они по майндсету и по подходам к жизни.

Приложение у них написано людьми, которые ненавидят людей и до поддержки хрен достучишься.

Решил заказать себе робот пылесос, регнулся в приложении и долго чесал репу что значит itn и еще какое-то слово, которое означает отчество.

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

В итоге, списали два раза деньги, хрен отменишь заказы, в доставках нет ничего и хрен найдешь поддержку.

А на пункте выдачи особо ничего не подскажут, потому что они выдают товар.

Штош, буду ждать возврата денег, если вернут их конечно.

Вайлдберрис — контора пидорасов. Неделю спустя.

Оставайтесь на линии, ваш звонок очень важен для нас. Примерное время ожидания два года.

Поддержка у ребят работает прям очень быстро, в целом можно сделать вывод что во всей конторе работают некомпетентные люди.

-- В Бишкеке говорят чтобы писал в приложение и задавал вопрос
-- Спустя пару суток после ожидания сказали писать в чат, а в чате вон по скрину выше можно понять как быстро отвечают люди.
-- Отписал в чат и учитывая что писал в пятницу и были выходные, но результата так и нет.

Самое забавное, что ВБ говорит что транзакций нет и доставок не видят, хотя пять покупок у меня в кабинете висят себе как доставленные.

На сайте написано что по всем вопросам можно писать на sales@wildberries.kg или sales@wildberries.ru, но там тоже не отвечают.

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

В целом, 16к в итоге жалко, они могут их и не вернуть учитывая вообще что происходит у них, но они будут в черном списке у меня вечно, как маркетплейс, как возможный работодатель и как вообще хоть какая-то компания

Непоправимых улучшений пост.

Don't marry your code. Наверное это лучшее что я слышал за последние полтора года и я полностью согласен с этим утверждением. И расскажу о последних изменениях, которые таки получилось вмержить в main, но они убивают больше половины кода, написанного в проекте.

Так вот, когда мы начинали делать Эверест, мы думали о том, чтобы Эверест работал как вне кубер кластера, так и внутри кубер кластера. Учитывая, что команда была еще достаточно новая и не у всех было понимание как работает кубер, то в итоге была взята связка в виде композа для запуска небольшого бекенда, который хранил данные в постресе.

С течением времени мы запилили чуть больше фичей в нашем операторе и получилось так, что почти бОльшую часть вещей, что мы храним в постресе мы храним и внутри кубер кластера. В итоге становится использование постреса для хранения куберовских объектов сомнительным, потому что:

1. Это достаточно большая и сложная зависимость для проекта и нужен код для работы с ним
2. Нужно думать, как сделать использование постреса для HA, а это значит нужно либо использовать оператор, либо пилить самим что-то чтобы запустить три реплики постреса, чтобы они работали между собой
3. Его нужно бекапить и думать об этом.
4. В кубере есть либо кеши контроллера, либо кеши клиента, которые лучше подходят для кеширования объектов, чем пострес.

Однако, была поддержка нескольких кубер кластеров и это был прям биг дил.

Но! Обсудив с продактом весь этот движ мы приняли два важных решения

1. Задепрекейтить композ и деплоить Эверест внутрь кубера и сделать его Kubernetes Native приложением
2. Убрать поддержку мультикуберов, потому что пока не понятно что на самом деле нам будет нужно и если убрать всё прямо сейчас, то продукт станет проще.

А дальше, потратив пару дней чтобы выпилить весь код, а потом написать его без использования постреса попивая чай между созвонами и закинув это на ревью, а после подождав около двух недель на всякие обсуждения, типа а давайте оставим пострес, я таки убил пострес.

Что дало? Кодобаза похудела на 5к строк, продукт стал проще, пространства для сетевых и человеческих ошибок стало меньше по ряду причин. Самый важный для меня пункт -- это теперь у бекенда нет никакого стейта и его можно как угодно масштабировать.

Такие дела

Не трогай, оно и так работает.

Жаль, что сечас можно эту фразу услышать не только от админов, но и от разработчиков.

Продолжая тему Don't marry your code с течением жизни проекта и изменений требований проекта, части системы придется выкидывать. Как по мне лучше всего это делать без сожалений и не думая о том, что завтра эта вещь может понадобиться. Это равносильно комментированию кода при коммитах.

Видеть закоментированный код в коммитах печально, потому что единственный вывод который можно сделать -- люди не умеют пользоваться гитом. Его можно спокойно удалить, а потом если что достать из истории либо пользуясь консолью, либо в современных IDE есть куча инструментов для этого.

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

И Мартин и Фаулер согласны с тем, что система хороша тогда, когда ее можно менять, если систему можно менять радикально за короткое время -- это либо хорошо написанная система, либо проект в начальной стадии. Но если упустить этот момент, то система обрастет техдолгом и дополнительной сложностью.

Поэтому, я люблю непоправимо улучшать систему, когда одно продуктовое решение может упрастить поддержку кода и работу с ним в разы.

Убитая ненужная зависимость снижает
1. Когнитивную нагрузку
2. Косты на хостинг для пользователей
3. Поддержку решения разработчиками
4. Количество корнеркейсов и обращений от пользователей, что не работает тот или иной функционал
5. Тестирование

NFS: Unbound, Resident Evil 4 и God Of War: Ragnarok Valhalla

Последние пару недель я устроил себе что-то типа отпуска и восстанавливаю потихоньку менталку. Вытерая пыль с консоли и контроллера, я вспомнил что были планы на прохождение резидента и вальхаллы.

Resident Evil 4 — это любимая игра из прошлого, но проходил я ее впервые на компе. Я тильтанул после первой попытки и когда пришел в деревню дох очень часто, плюс на компе я проходил ее с читами, нарисовав себе кучу денег с помощью артмани. В целом — это тот же самый резидент, с тем же сюжетом, теми же косяками, только с новым и классным графонием. На контроллере в нее играть сначала непривычно, но потом как-то втягиваешься. Было прикольно пройти ее сначала, а потом еще раз и в итоге забив, что я таки не куплю бесконечную базуку я забил на нее спустя 2 с половиной прохождения. Плюс до платины ее если добивать, то пройти надо будет не один раз, а на это тратить 5-10 часов не очень хочется

DLC для God Of War получился достаточно интересным и хорошим. Кто играл в Варкрафт и знает что такое Торгаст или Башня Мага, то это примерно тоже самое, только с дополнительной историей и всем подобным. Кратко — нужно просто проходить через несколько миров и дверей поднимаясь наверх, драться с Тиром и получать какой-то кусок истории. В целом пройдя DLC на 100% остались вполне себе хорошие впечатления.

Unbound. Вообще я не собирался покупать игру и как-то гамать в нее. Я вообще думал поставить NFS: Most Wanted 2005 года и пройти ее еще раз, но посмотрев пару обзоров я решил дать шанс, к тому же она шла со скидкой и обошлась мне в 11 баксов. Я не любитель серии после того, что выходило после 2005 года, пробовал Heat, пробовал переиздание Most Wanted и оно не заходило. Тут же есть прикольные эффекты в стиле комиксов. По геймплею есть вайб тех самых андерграундов и мост вонтед, саундтрек в игре отстой, AI хорош и на пару кругов не накатать их уже, плюс количество рестартов ограничено. Также можно не париться и не всегда приезжать первым, кроме некоторых ивентов. В общем, можно попробовать поиграть в нее. Правда онлайн доступен только при подписке на Playstation+.

А пока сейчас межсезонье в World Of Warcraft, то приходится играть либо в какие-то игры на плойке, либо смотреть видосики с конф.

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

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

Обычно из каждого утюга говорят про ворк-лайф баланс. Однако если в вашей лайф только ворк и лайф, то у меня плохие новости. Жизнь не делиться на лайф и ворк и обычно для поиска баланса есть колесо баланса и другие инструменты. Также говорят, что переработки ведут к выгоранию, однако это в большинстве случаев не так. Я сколько перерабатывал и не выгорал (Да-да типичное у нас психологов не было и ниче, нормальные. С вас пять тыщ :D). По опыту и наблюдениям переработки ведут к усталости, истощению и даже если разорвать бесконечный цикл, то восстановление займет достаточно быстрое время до пары недель. Однако, если переработки бесмыссленные, то вот в этом случае оно может привести к выгоранию.

В чем же тут дело? Почему в одном случае у нас есть выгорание, а в другом нет? Дело в том, что выгорание – это всегда про бесмыссленность. Если это расширить, то выгорания не приходят к нам из-за переработок. Они приходят к нам из-за того, что мы долго не можем добиться результата, либо мы не согласны с видением, либо у нас нет этого видения. Вот эту цитату я прочитал как-то в одной рассылке и мне стало понятнее почему я выгорал и что с этим делать.

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

Более менее список причин, которые могут привести к выгоранию

1. Некомпетентный менеджмент. К сожалению его найти в отрасли достаточно легко. Сюда входят классические примеры, что мы используем agile poker для получения эстимейтов, менеджер принимает решение когда должна быть готова та или иная фича в 100% случаев и так далее
2. Насилие на рабочем месте. Сюда входит обесценивание труда, выданное под соусом “Я выдаю фидбек”, не умение в конструктивную обратную связь, обвинения всякие, газлайтинг, абьюз и подобное
3. Непонятна картина куда вообще идет проект ни по технической, ни по продуктовой стороне. Если нет ответа “А зачем мы делаем этот проект”, то в конечном счете человек не будет видеть смысла в своей работе
4. Бесмыссленные переработки. Есть переработки, которые вполне легко переносятся. Например, когда катите какую-то фичу и хотите успеть. Тут всё понятно зачем и почему перерабатываете. Но если переработки не по вашему желанию а из-за некомпетентности менеджмента или неумения говорить нет, то тут они и ведут к тому, что можно выгореть.

Завтра напишу как распознать и что с этим делать также со своего опыта

Если выгорание на ранних стадиях, то выйти из него можно достаточно быстро, а если на поздних стадиях и почти угли, то реабилитация может занять достаточно долгое время. Как выходить из выгорания? (Вопрос, а зачем вы туда вообще зашли?) Я хз если честно, однако по своему опыту могу рассказать как я выходил из выгорания.

1. Отъебитесь от себя и позвольте себе ничего не делать. С работы можно либо взять отпуск, либо уволиться, либо делать что-то другое.
2. Прислушайтесь к себе что хочется делать. Это может быть желание отоспаться, посмотреть сериалы, погамать в игрушки, набухаться, накуриться, натрахаться или что-то еще
3. Дайте себе время на отдых и реабилитацию
4. Смените область деятельности
5. Плюс была терапия, которая дала результаты

С выгорания 21 года я выходил около 2х месяцев но окончательно вышел спустя 8 месяцев, правда через год уже на начальной стадии я решил уволиться. Выходил из сложного выгорания следующим способом

1. Сначала спал и ничего не делал
2. Потом посмотрел все сериалы, которые хотел
3. Когда понял, что не могу сидеть без дела, решил попробовать поработать таксистом, чтобы закрыть весь цикл работы в такси
4. Когда понял, что бухать можно в ноль, поработал барменом пару смен и научился готовить пару коктейлей. В итоге у меня теперь есть немного барного оборудования и я могу делать коктейли. По крайней мере сделать виски саур – это изи
5. Занялся обучением, ресерчем интересных для меня тем

С последнего начального выгорания я выходил через гейминг и ресерч интересных для меня тем. Наверное более менее дельный совет, который могу тут дать – это найти или осознать ту активность, которая вас наполняет или заряжает. У меня это изучение чего-то нового, будь то что-то по сфере или изучение как выдерживать мясо сухим вызреванием.

На этом всё. Наверное стоит посмотреть еще Анну Обухову, чтобы разобраться в теме детальнее. А вообще стоит сходить к психологу, но поиск хорошего – это сложно

Ну и свои варианты можно докинуть в комменты

Capture the Flag(CTF) — это всегда интересно, прикольно, волнительно и в целом офигенно. Это такое соревнование, в котором можно залипнуть сильнее, чем в любой самопогружающей игре и на этой неделе меня случайно подбили на это действие.

Регнул команду, посоревновался вместе с другими ребятами со всего мира по разным тематикам: Web, Pwn, Crypto, Hardware, Reverse, Misc и несколько других. Решил 10 челленджей из 67 уровня до медиум.

Веб разработчикам участвовать в этих мероприятиях будет хорошо, чтобы научиться писать безопасный код и хотя бы знать про OWASP top 10. Админам и прочим — научиться конфигурировать сервисы достаточно хорошо.

Из интересных вещей, которые были не в Reverse:

1. Прикольно было ковырять RabbitMQ, чтобы найти флаг в очередях
2. Было интересно поэксплуатировать RCE питоновского pickle
3. Было забавно впервые самому загрузить пхпшный шелл и поломать пхп приложение по выводу времени
4. Получить классный опыт получения reverse shell

Был удивлен решить хоть что-то в Reverse, учитывая что для меня эта тема была новой (относительно). Я как-то давно интересовался этой темой и руки никак не доходили до этого, пока десяток лет назад не встретился с чуваком, который захотел перейти с реверс ресерчера в питониста. Тогда он скинул мне простую crackme, сказал поставить IDA, открыть его и сказал: “Вот тут код, найди тут баг”.

Это был забавный опыт, учитывая что я тогда вообще не понимал ничего про asm и опыта работы с разными тулами было меньше, чем сейчас.

Сейчас же, дошел до медиум и в процессе реверса чуть лучше стал понимать ассемблер (не, код на нем я конечно не напишу, но понять стало проще), поработал с разными тулами, типа strings, file, ltrace, strace, radare2, ida.

Некоторые бинари поддавались минут за 20-60, над некоторыми думал более 5-6 часов.

CTF уже закончился, но парочку бинарей я себе оставил конечно же. Тему реверса я поизучаю, учитывая что у меня в ближайших планах было поковырять ассемблер чутка.

А какие подобные активности нравятся вам и почему? Хакатоны? CTF? Что-то другое?

Следующая серия постов будет про найм. Там я и по ворчу и по критикую и в целом как-то порефлексирую опыт. Я долгое время нанимал сам, поэтому кое что об этом знаю.

Лучшее интервью, которое было у меня недавно длилось час и у меня почти не было вопросов. Оно прошло по следующему плану

— Рассказ о том, как работают ребята. Какие процессы, какой стек, какие люди в команде, как они коммуницируют и в целом как выглядит процесс поставки.
— Технические вопросы, которые больше направлены на проверку компетенций.

Ноль алгоритмических секций. Ноль булщита и в целом стало всё понятно о команде и как они набирают людей. Это было лучшее и запоминающееся, но радует, что я стал встречать таких интервью куда больше и стал чаще отказываться от секций с алгоритмами.

Секции с алгоритмами вызывают у меня стресс и вообще первую половину времени я соображаю что от меня вообще хотят, а потом начинают потихоньку брутфорсить решение, размышляя. Самый токсичный опыт был на этой секции, что я пошел не совсем так как нужно было, потратил 15 минут, мне сказали что я не умею программировать и завершили собеседование, но в итоге через 5 минут я задачу таки решил.

Опыт хороший, чтобы понять вообще та ли команда или нет, потому что с ними я работать и так не особо хотел, а после этого опыта и подавно. Так что для меня это тоже хороший фильтр.

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

Самый кринжовый опыт по алгосикам — это решать их в аналоге гуглодока, где есть просто типа блокнота, который пошарен между обоими без дополнительных тулов. Я хз зачем оно нужно в таком ключе, ведь есть куча платформ аналогов литкода, где не надо в своем мозгу эмулировать компилятор или интерпретатор.

План, который собираюсь раскрыть следующий:

1. Почему, оказывается, резюме писать нужно учиться и следовать каким-то практикам (внезапно)
2. Почему я не люблю секции с алгоритмическими задачами и что с ними не так. Чем можно их заменить
3. В целом про хорошие процесы найма и плохие процессы найма для меня
4. Че вообще делать со всем этим дальше и какой там план.

А что добавите вы?

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

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

Долгое время я пытался напилить резюме самостоятельно, следуя каким-то рекоммендациям из интернета, типа глаголы должны быть сильные и всё в том же духе. С одной стороны вроде бы и получалось, а с другой стороны опыт в резюме всё равно размазывался.

Недавно, я нанял консультанта, который помог написать резюме. Саша Жарков сначала дал просто одностраничный шаблон, который достаточно простой и я просто перетащил туда свое прошлое резюме, как оно было написано пару лет назад.

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

Пришлось правда убрать некоторые вещи, которые с одной стороны было жалко убирать, потому что это был всё таки ценный опыт, типа полугода работы DevRel (пришлось растянуть чуть чуть сроки работы на двух местах, чтобы гэп был меньше), плюс убрать опыт CTO, потому что это может вызывать вопросы.

В итоге, количество интересующихся компаних вырасло значительно и если сравнивать с опытом поиска работы в ноябре прошлого года и до декабря, то и интереса больше и в целом работу нашел быстрее. Буквально за полторы недели прошел до оффера.

Хоть и убранный опыт было жаль убирать, но это сразу убрало кучу ненужных вопросов про то, почему ушел, хочешь ли ты снова быть в пиплменежменте или нет, почему решил уйти в деврельство и подобное. Правда вопросы не ушли, потому что на линкедине всё осталось также и душные рекрутеры могут и до этого докапаться, но стало всё куда проще.

Если смотреть наглядно про было и стало то вот резюме до работы с Сашей и вот после.

Ну и как итог я рекомендую иногда нанимать людей, которые могут помочь вам разобраться с темой, которую вы не понимаете в разы лучше.

Гэпы по работе в резюме. Когда начал искать работу, то у меня был гэп в почти три месяца и у меня спрашивали почему оно так получилось.

С одной стороны простой вопрос, а с другой стороны вежливо и как оно есть не расскажешь. Да и к тому же рекрутерам эта вещь часто интересна, однако причины могут быть совершенно разные:

— Чувак просто решил побездельничать пару месяцев и это вполне себе лайтово
— Можно взять время на рефлексию и это тоже лайтовый вариант для ответа
— Ухаживал за больным родственником
— Человек сам болел или с ним что-то случилось.

Можно вопрос “А почему вы ушли и не устроились куда-то после увольнения” ставить примерно в одну и ту же категорию, что вопрос “Тебе 30+ лет и у тебя нет детей. Почему?”.

Как-то пару лет назад было подобное обсуждение у людей в иммиграции отвечать на вопрос “Откуда ты?”. Вроде такой же простой вопрос, который показывает просто интерес, однако может вскрыть кучу разных наболевших болячек.

А что еще может вскрыть кучу болячек — это алгоритмическая секция на интервью 😂

На тему алгоритмических задач можно накидывать бесконечно. С одной стороны — это равные условия (сомнительно конечно, но окэй) для всех кандидатов, которые приходят на интервью. С другой стороны она проверяет только то, как человек может решать эти задачи.

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

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

Алгоритмические задачи, особенно абстрактные, особенно которые есть на литкоде — это зло. Конечно, можно потратить пару месяцев на то, чтобы научиться решать все эти задачи, но к реальному программированию и работе оно не имеет никакого отношения.

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

БОльшая часть работы в реальности — это чтение кода, дизайн кода, написание его так, чтобы можно было покрыть тестами, покрыть тестами, добавить где надо комментариев, чтобы сделать понятнее следующему человеку какие-то неочевидные места, следование каким-то практикам типа KISS, YAGNI, SOLID, что-то еще забытое или модное.

Однако, посидеть и подумать над какой-то задачей, которая на первый взгляд алгоритмическая, но не академическая — это хорошо. Хорошо тем, что можно просто поговорить, понять вообще где оно может быть применимо, какой кейс может быть в реальности, и в целом закодить ее без проблем за оставшееся время.

Чаще всего — это просто задизайнить какую-нибудь структуру, типа LRU кеша, либо чего-то подобного но для получения уникальных результатов. Это хоть как-то можно соотнести с работой и чем придется заниматься в будущем.

Идеальные на мой взгляд интервью — это либо ревью кода, либо парное программирование, либо имплементация фичи, либо дебагинг в реальном времени. Это интересно обычно (чисто для меня, другим может быть стрессово)

Домашние задания тоже вполне себе окей, хоть тоже и сомнительно. Обычно я не против домашних заданий, если я чему-то научусь в процессе, либо задание интересное, либо оно короткое до 4х часов в идеале, максимум 8.