Я ему сейчас вьебу, честное слово...

Справедливости ради Claude Code прям хорош. Пожалуй один из лучших агентов, которыми я пользовался. Мне кажется он работает на уровне Junior+ или Middle–. Правда такой Middle который переодически в запой уходит и ему становится вообще похеру на твои замечания. Прям как с реальным разрабом получается

Как я так и не получил стаффа в этом году

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

👉 Развернул n8n на всю компанию. Я взял уже готовое решение, развернул его на нашей инфре и сделал мелкие доработки, чтобы оно вообще завелось у нас. Далее договорился с безами, чтобы все могли этим пользоваться.
👉 Импакт-анализ. Кому интересно – подробнее есть статья, кому не интересно – штука, которая запускает только нужные тесты в MR-ах, а не все. И нет, это не как у Авито, у них гораздо примитивнее всё.
👉 Сервис для мобильных релизов. Сервис – это веб-приложение на Next.js, которое позволяет создавать релизы и интегрировано с n8n, чтобы запускать релизные процессы.

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

Основная критика строилась вокруг двух вещей:

👉 Нехватка technical complexity
👉 Нет законченности задач

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

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

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

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

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

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

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

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

Это то место, где агенты дико сосут. Ты даёшь им задачу, и вот они, как выбрали какой-то путь, так, вероятнее всего, с него и не свернут: перепишут целый модуль, но сделают всё по первому сценарию. Это ровно как джун с очень горящими глазами, который ничего не боится. Джун, который, не сомневаясь, перелопатит кучу файлов там, где нужно было дописать три строки.

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

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

Тем временем на курсе для HRов: "если сопровождающее письмо оформлено под вакансию, то это красный флаг" 🗿🗿🗿

Вот бы HR вчитывались в опыт, а не анализировали блять стиль текста

Как понять, что не ошибся со станцией, когда едешь на мероприятие по мобильной разработке

В Advent of Code в этом году стало в два раза меньше задач. Сука, даже здесь сокращения...

Есть три основных способа решать задачи в CI/CD:

👉 Script
👉 CLI
👉 Плагин для билд-системы

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

Скрипты – самый простой и частый вариант. Обычно крутятся на CI или используются для настройки проекта, git-хуков и т.д. Всё, что связано с отправкой артефактов, уведомлений или обновлением внешних систем, отлично ложится на скрипты. Примеры:

👉 отправить сборку QA;
👉 создать отчёт после тестов и отправить в чат;
👉 подвинуть задачи в Jira после merge.

Python – тут разумеется король: простой синтаксис, лёгкий дебаг, небольшой Docker-образ. Иногда используют Ruby, JS или (не дай бог) Bash. Скрипты хранятся рядом с кодом и легко мгновенно – огромный плюс.

Минус – нужен дополнительный runtime в базовом образе. Главная ошибка тут, это когда скрипт разрастается и не выносится в отдельный CLI когда уже нужно. В этом случае даже нейронка запутается с тем, нафига он вообще создавался.

CLI – следующий уровень. Это уже не просто один скрипт, а маленькая утилита или набор инструментов. Четкой границы когда нужно делать CLI, а не скрипт я вам не дам, но есть пара признаков:

👉 запускается и на CI, и у разработчиков;
👉 переиспользуется в разных проектах;
👉 не зависит от структуры конкретного проекта.

Пример: линтеры вроде detekt (его можно запускать как CLI). У нас на проекте есть CLI для запуска тестов с разными параметрами, работает куда предсказуемее обычного запуска через студию.

Лучший язык тут – Go: один бинарь, никаких runtime. Java/C# тоже можно, но придётся тащить runtime. Python также можно упаковать в бинарь, но это прям геморно. Rust – если прям нужен низкий уровень, но я бы не стал.

Минус – правки уже не такие быстрые, чаще всего CLI живёт в отдельной репе. Плюс – если берем Gо, то ничего лишнего в базовом образе.

Плагин – я выделил эту сущность отдельно, потому как по сути это что-то среднее между CLI и скриптами. Тут автоматизация уже работает в рамках конкретной билд системы. Этот подход стоит применять только в том случае, если задача сильно привязана к коду или структуре проекта:

👉 генерация кода
👉 обход графа зависимостей
👉 кастомные трансформации при компиляции

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

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

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