Короче, было пару вопросов — кто такой стафф, поэтому давайте пару пояснений.

Стандартный трек карьеры айтишника выглядит так:

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

Далее ты выходишь на уровень мидла. Тут уже всё индивидуально: некоторые находятся на этом этапе год-два, некоторые задерживаются дольше. В целом мидлы считаются рабочими лошадками — потому что ты ещё не успел выгореть от формочек и перекладывания JSON’ов, тебе всё дико интересно. На этом этапе все страдают страшным перфекционизмом, чётким следованием заветам Дяди Боба, SOLID и прочих аббревиатур. Мидл — уже самостоятельная единица, за ним нужен лишь небольшой контроль. И то — только для того, чтобы, если мидлу скучно, он не начал делать бесконечный рефакторинг или не затащил новую либу, которая вышла только вчера.

После идёт сеньор. Это уже больше про какие-то сложные фичи или архитектурные задачи на уровне всего проекта. Ты уже знаешь, где нужно быть дотошным перфекционистом, а где можно быстро наговнокодить, чтобы быстрее заехать в прод. На этом этапе у тебя уже есть история проёбов, и ты знаешь, какие задачи нужно делать, а на какие лучше забить. Сеньор уже больше думает про бизнес-ценность. Полностью автономная единица — закидываешь ему задачу и можно не париться: всё будет сделано норм.

Идти выше – уже опционально, потому что и на уровне сеньора вполне комфортно сидеть. После сеньора идут две основные ветки, которые можно качать:

👉 Первая, дефолтная — уходить в менеджмент. Сначала ты тимлид, потом, если повезёт и ты готов ебошить, становишься тимлидом тимлидов, а дальше движешься к CTO. Однако нужно понимать, что на высоких должностях ты забываешь про ламповое айти — и у тебя буквально начинается игра престолов.

👉 Вторая — это ветка архитектора или техлида (он же стафф). В этом случае ты не управляешь конкретной командой, но влияешь уже на несколько проектов. На этом этапе ты создаёшь какие-то best practices, подходы, которые используют все, или делаешь уникальные решения, приносящие дикий профит. Конкретно эта ветка есть далеко не во всех компаниях, да и не везде она реально нужна.

Про плюсы и минусы грейда выше сеньора я сделаю отдельный пост.

Гребаный Python, я вам сейчас опишу ощущение от языка одним предложением.

Это чувство когда ты уже 8 лет работаешь в IT, но уже два часа не можешь расставить кавычки в строке как нужно, чтобы сформировался корректный json.

Знатно я выпадаю, в этом году мои проёбы меня, конечно, подкосили.

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

Итак, две ветки: тимлиды и техлиды. Наверное, сделаю два отдельных поста про каждого, и начнём с первых.

В чём плюсы тимлида:

👉 Самое основное – это то, что у тебя появляется чёткий и проторённый путь, куда идти дальше. После ты становишься каким-нибудь лидом лидов и дальше по иерархии – до CTO. Уровень иерархии зависит от размера компании, а также нужно понимать, что придется прям пиздец как попотеть, чтобы залезть на этот уровень.
👉 Зависит от компании, но в среднем, если судить по медианным зарплатам, позиция лида чуть выгоднее, чем позиция обычного сеньора. Это в целом можно увидеть и по вакансиям: у лидов довольно часто вилки выше. Правда, это отличие не в разы, а в некоторых компаниях и вовсе нет разницы.
👉 Качаются коммуникативные скиллы. Это возможно мое наивное представление, но как мне кажется прям тяжело быть закрытым интровертом, когда работа требует от тебя постоянного общения с людьми. Следовательно больше общения -> больше связей -> больше возможностей в дальнейшем.

Теперь минусы тимлида:

👉 Твоё время больше тебе не принадлежит – оно теперь командное. Появляется куча встреч; почти у всех знакомых лидов весь день по сути состоит из каких-то созвонов.
👉 Все успехи – командные, а проёбы – твои. Наслаждайся)
👉 Результаты твоей работы – пиздец какие отложенные. Когда ты разраб, ты можешь быстро раскатать фичу и сразу увидеть результаты по метрикам, отзывам и т.д. Но когда ты лид, то придётся прям подождать, и вероятнее всего – долго...
👉 Ты начинаешь терять в скиллах. Это индивидуально: есть много лидов, которые продолжают писать код. Но в среднем по больнице у тебя, вероятнее всего, не будет хватать на это времени, и с этим придётся смириться.

Что там с техлидами, aka staff, aka архитектор?

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

Однако же с техлидом требования выглядят примерно так (по крайней мере в нашей компании): «Ну, сделай то, не знаю что, что-то прямо очень необычное и большое, вооот... И еще тебе это нужно самому придумать и обосновать». Потом те ребята, которым посчастливилось стать техлидами до тебя, будут оценивать, насколько твое творение совпадает с их пониманием, кто такой техлид.

Теперь про плюсы/минусы:

Плюсы:
👉 Ровно как и у тимлида, у тебя выше вилка по ЗП, а также выше коэффициент премии.
👉 У тебя есть возможность расти дальше, но опять-таки на позицию CTO будут претендовать и тимлиды, которые, вероятнее всего, тебя уделают, так как больше парятся про бизнес.
👉 Ты не теряешь в скиллах, скорее даже наоборот – позиция требует, чтобы ты их прокачивал глубже.
👉 Есть рычаги давления на проект как у тимлида, но при этом от тебя не требуется проводить 1-to-1 и вообще заниматься персоналом.

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

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

Справедливости ради 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 довольно сложный дебаг, так еще и на каждый чих вам придется ждать конфигурацию, что на больших проектах занимает минуты.

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