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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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