Я сделал себе скилл для работы со сложными задачами через pr loop, сначала вместе с агентом бьем задачу на шаги, потом он выполняет строго по одному шагу и делает pr на шаг, я отсматриваю эти небольшие pr и общаюсь с агентом через комментарии в них, когда шаги заканчиваются тестирую и отсматриваю финальный pr уже сам и отправляю на ревью. Состояние этого процесса разработки хранится в файле прямо в репозитории. Впринципе получается достаточно быстро перемалывать таски такой штукой. https://github.com/betine/dev-partner-skill
любой код, в котором видно что человек стремиться создать что-то новое, для меня будет лучше шаблонов чистой архитектуры, но на самом деле пет проекты не показатель вообще ничего, я просто несколько раз натыкался на людей с идельными пет проектами, но с нулевой эффективностью в работе и перестал обращать на их наличие внимание
Я вот, быстро прочитав ваше резюмен не понял бы что вы менторить хотите. Я не уверен что менторы массово нужны.
"Я сознательно стараюсь минимально участвовать в разработке сам и принимаю pull request’ы только тогда, когда они соответствуют моим требованиям по качеству и архитектуре." - вот это 100% ред флаг, если вы конечно не о своем проекте говорите, тк в компаниях они должны не вашим требованиям соответствовать а задачам и возможностям кода, который в продакшене. Я это читаю однозначно как - человек не будет ничего делать сам, будет тормозить работу всей команды. Извините но это так.
Небольшой фидбэк, я если что не hr но людей искал и то что написано только мое виденье.
ваше резюме слишком сухое, из него вообще непонятно что вы делали и что можете делать. Поэтому, если резюме много я бы просто скипнул его, тк в нем ничего непонятно а времени разбираться у меня нет.
пет проект в таком виде скорей бы шел в минус, потому-что он не имеет никакого отношения к реальным задачам, а вот какой-нибудь живой пусть костыльный но грязный код, но главное чтобы в нем была жизнь и свои идеи шел бы только в плюс.
(очень субъективно) у вас в пет проекте нет ничего что нельзя было бы сгенерировать нейронкой под свои задачи за полчаса и в самом шаблоне AGENTS.md тоже нет, а это уже важно
Возможно с работой в РФ действительно не очень хорошо, на вашем месте я бы поискал релоцировавшиеся из РФ компании и команды, расписал бы свое резюме, и отослал туда.
Каждый думает, что отвечает за свой код, на практике они часто ошибаются. И кто-то (их может быть несколько) должен отвечать за весь проект. Если у вас отсмотр PR - формальность, искренне сочувствую. Вообще интересно было бы посмотреть на жизнь чего-то полезного, написанного вайб кодером.
Мне очень интересно было бы почитать про опыт вайб кодинга в живых проектах, а не прототипах и пет проектах. Вот написали вы кучу кода и тесты с помощью ИИ. Дальше - этот PR кто-то смотрит? Кто его смотрит, как выглядит процесс приемки кода, итд. Потому-что написать код, это меньшая часть задачи, а вот запустить этот код в продакшен - большая.
Предлагаю не обожествлять ТК, который написан ни в интересах работника, ни в интересах работодателя, а исключительно в интересах государства. Зарплата в конверте (то есть кэшем) это кажется такой пережиток прошлого, пока обнал не прикрыли, и это действительно вариант хуже ТК. Для квалифицированного специалиста лучшим и самым здоровым вариантом трудовых отношений является ИП на УСН с кастомным контрактом, просто надо помнить, что вы как работник тоже можете выставлять свои условия. То-есть если вам в контракт хотят впихнуть штрафы, то можно требовать и плюшки. И кстати с ИП платятся соцвзносы, то есть вам начисляются пенсионные баллы.
Ваш работодатель нарушал ТК, потому-что ТК предусматривает неиспользование работником отпуска в течении года только в крайних случаях. Если бы вы брали больничный, то получив за него компенсацию, вы бы очень удивились ее размеру, она очень сильно ограничена сверху и компенсировать разницу между зарплатой и компенсацией вам по ТК никто не обязан. Если бы получали отпускные, то тоже удивились бы что вам пришло в месяц денег меньше зарплаты, а в некоторые особые месяцы существенно меньше.
Ради интереса, вы когда-нибудь получали выплаты за отпуск или больничный по ТК РФ? Вот где настоящее кидалово. Или у вас настолько маленькая зарплата, что выплаты по больничному, кажутся хоть чем-то кроме издевательства? Замечу, что копить неотгуленный отпуск это тоже не по ТК, по ТК отпуск не ваше право, а фактически ваша обязанность.
Ваш код на порядок или два лучше чем то, то в статье. По крайней мере он читается на лету, в отличии от. Код, который приведен как пример грамотного решения в статье, не должен пройти ревью. Да, я считаю, что разработчик, начиная с уровня мидла должен в этом случае попросить контекст, в котором вызывается метод, или явно указать, что он бы в первую очередь попытался бы отрефакторить код снаружи. Насчет входных параметров, если эта функция вызывается из любого места кода, то это просто вопрос времени, когда ее кто-то вызовет с неотсортированными массивами, и тогда первый неоптимальный вариант не является неоптимальным, он будет единственным правильным ответом. Если бы собеседуемый указал на это, это было бы ему в плюс. Насчет прошли бы или нет, это зависело бы от других факторов а не только от того как вы написали эту функцию. Возможно в голове у меня отложилось бы, что вы скорее склонны писать понятный и читаемый код, а автор статьи код пишет тяжелый и неприятный.
По сути нужен не HR, нужен помощник/секретарь, который чуть сократит время работы тимлида, а не зарежет, поржав с девочками, всех релевантных кандидатов. Но, если секретаря нет, то тоже не страшно. Если компания большая, и ее HR саботирует процесс найма, как в этом посте, то я бы попробовал хотя бы некоторым командам дать возможность самим искать себе кадры.
Вот реальный кейс поиска фронтенд (react, mobx, ts) - мидла в noname микро компанию месяц назад.
публикация на hh
200 откликов за первый день, вакансию скрываем - горшочек не вари
Один человек за несколько часов просматривает 100 резюме из присланных, и отправляет либо предложение договориться о собеседовании в телеграмме либо отказ.
Из 100 резюме в воронке, назначено и проведено 17 собеседований.
Собеседование проводится двумя главными разработчиками (тимлидами). Время на собеседование - час. Форма - разговор, с техническими вопросами. После собеседования 15 минут перекур и обсуждение кандидата. 17 собеседований занимают примерно 5 рабочих дней.
Отобрано 2 финалиста. Сделан оффер первому и он принял предложение.
Итого от размещения вакансии до выхода человека на работу прошло 3 недели. Сотрудник с работой справляется, представлению тимлидов о фронтенд мидле соответствует.
В моей картине мира именно по этой вакансии была очередь за забором.
Мой личный опыт (разработчик и внезапный генеральный директор продуктовой микро компании) показывает, что фич, которые приносят деньги и не оттестированы не бывает в природе. В основном они приносят внезапный головняк, что для микро компании чревато срывом сроков по другим продуктам. Поэтому обычно переговоры с разработчиками ведутся по вопросу, как написать фичу без оверинжиниринга, а не о том надо ли ее писать без тестов и под рефакторинг или не надо.
Если продакт менеджер говорит а почему 20, давай 10 и его нужно убеждать в том, что писать новую фичу без тестов и сразу под рефакторинг это плохо, то это говорит о его потенциальной профнепригодности. Адекватный диалог - должен звучать так:
20 часов?
Качественно и с тестами?
Да
Ок, вперед. (Или если во время не укладываемся) Ладно выпустим в следующем релизе.
Бюрократии, возможно, больше, чем в РФ (но я не был в РФ в качестве иностранца, так что не знаю), но она на 99% сидя в кресле дома попивая кофеёк лениво разбираться с онлайн-формами (иногда помощью Google Translate, но опять же я сам виноват в этом), а не часами от руки заполнять бесконечные бланки на подоконнике какого-нибудь госучреждения с очередью недовольных за спиной. ЭТО ДРУГОЕ.
Я ту недавно, в Москве, менял генерального директора в ООО, после внезапной гибели предыдущего гендиректора, который в то-же время являлся владельцем 50% доли этого ООО. Это достаточно неприятный казус в таком сочетании. И ни разу не сидел на подоконниках и не заполнял бланки. В основном процесс построен так, что тебе присылают инструкции, которые ты выполняешь. И даже в этом тяжелом случае, обычный программист, которым я по сути являюсь, справился с возвратом управления компании. Так что как минимум в Москве с бюрократией все замечательно.
Это миф о мифах, за 15 лет работы в постсоветском IT такие подходы к работе я не встречал ни разу. Зато постсоветское IT характеризуется подходом - сначала попытаться разобраться, почитать документацию, погуглить, а потом уже писать вопросы в поддержку. И это отличный, экономящий огромное количество времени подход к работе.
Я сделал себе скилл для работы со сложными задачами через pr loop, сначала вместе с агентом бьем задачу на шаги, потом он выполняет строго по одному шагу и делает pr на шаг, я отсматриваю эти небольшие pr и общаюсь с агентом через комментарии в них, когда шаги заканчиваются тестирую и отсматриваю финальный pr уже сам и отправляю на ревью. Состояние этого процесса разработки хранится в файле прямо в репозитории. Впринципе получается достаточно быстро перемалывать таски такой штукой. https://github.com/betine/dev-partner-skill
любой код, в котором видно что человек стремиться создать что-то новое, для меня будет лучше шаблонов чистой архитектуры, но на самом деле пет проекты не показатель вообще ничего, я просто несколько раз натыкался на людей с идельными пет проектами, но с нулевой эффективностью в работе и перестал обращать на их наличие внимание
а, тогда все ок
Я вот, быстро прочитав ваше резюмен не понял бы что вы менторить хотите. Я не уверен что менторы массово нужны.
"Я сознательно стараюсь минимально участвовать в разработке сам и принимаю pull request’ы только тогда, когда они соответствуют моим требованиям по качеству и архитектуре." - вот это 100% ред флаг, если вы конечно не о своем проекте говорите, тк в компаниях они должны не вашим требованиям соответствовать а задачам и возможностям кода, который в продакшене. Я это читаю однозначно как - человек не будет ничего делать сам, будет тормозить работу всей команды. Извините но это так.
Небольшой фидбэк, я если что не hr но людей искал и то что написано только мое виденье.
ваше резюме слишком сухое, из него вообще непонятно что вы делали и что можете делать. Поэтому, если резюме много я бы просто скипнул его, тк в нем ничего непонятно а времени разбираться у меня нет.
пет проект в таком виде скорей бы шел в минус, потому-что он не имеет никакого отношения к реальным задачам, а вот какой-нибудь живой пусть костыльный но грязный код, но главное чтобы в нем была жизнь и свои идеи шел бы только в плюс.
(очень субъективно) у вас в пет проекте нет ничего что нельзя было бы сгенерировать нейронкой под свои задачи за полчаса и в самом шаблоне AGENTS.md тоже нет, а это уже важно
Возможно с работой в РФ действительно не очень хорошо, на вашем месте я бы поискал релоцировавшиеся из РФ компании и команды, расписал бы свое резюме, и отослал туда.
Каждый думает, что отвечает за свой код, на практике они часто ошибаются. И кто-то (их может быть несколько) должен отвечать за весь проект. Если у вас отсмотр PR - формальность, искренне сочувствую. Вообще интересно было бы посмотреть на жизнь чего-то полезного, написанного вайб кодером.
Мне очень интересно было бы почитать про опыт вайб кодинга в живых проектах, а не прототипах и пет проектах. Вот написали вы кучу кода и тесты с помощью ИИ. Дальше - этот PR кто-то смотрит? Кто его смотрит, как выглядит процесс приемки кода, итд. Потому-что написать код, это меньшая часть задачи, а вот запустить этот код в продакшен - большая.
Предлагаю не обожествлять ТК, который написан ни в интересах работника, ни в интересах работодателя, а исключительно в интересах государства. Зарплата в конверте (то есть кэшем) это кажется такой пережиток прошлого, пока обнал не прикрыли, и это действительно вариант хуже ТК. Для квалифицированного специалиста лучшим и самым здоровым вариантом трудовых отношений является ИП на УСН с кастомным контрактом, просто надо помнить, что вы как работник тоже можете выставлять свои условия. То-есть если вам в контракт хотят впихнуть штрафы, то можно требовать и плюшки. И кстати с ИП платятся соцвзносы, то есть вам начисляются пенсионные баллы.
Ваш работодатель нарушал ТК, потому-что ТК предусматривает неиспользование работником отпуска в течении года только в крайних случаях. Если бы вы брали больничный, то получив за него компенсацию, вы бы очень удивились ее размеру, она очень сильно ограничена сверху и компенсировать разницу между зарплатой и компенсацией вам по ТК никто не обязан. Если бы получали отпускные, то тоже удивились бы что вам пришло в месяц денег меньше зарплаты, а в некоторые особые месяцы существенно меньше.
Ради интереса, вы когда-нибудь получали выплаты за отпуск или больничный по ТК РФ? Вот где настоящее кидалово. Или у вас настолько маленькая зарплата, что выплаты по больничному, кажутся хоть чем-то кроме издевательства? Замечу, что копить неотгуленный отпуск это тоже не по ТК, по ТК отпуск не ваше право, а фактически ваша обязанность.
del
Ваш код на порядок или два лучше чем то, то в статье. По крайней мере он читается на лету, в отличии от. Код, который приведен как пример грамотного решения в статье, не должен пройти ревью. Да, я считаю, что разработчик, начиная с уровня мидла должен в этом случае попросить контекст, в котором вызывается метод, или явно указать, что он бы в первую очередь попытался бы отрефакторить код снаружи. Насчет входных параметров, если эта функция вызывается из любого места кода, то это просто вопрос времени, когда ее кто-то вызовет с неотсортированными массивами, и тогда первый неоптимальный вариант не является неоптимальным, он будет единственным правильным ответом. Если бы собеседуемый указал на это, это было бы ему в плюс. Насчет прошли бы или нет, это зависело бы от других факторов а не только от того как вы написали эту функцию. Возможно в голове у меня отложилось бы, что вы скорее склонны писать понятный и читаемый код, а автор статьи код пишет тяжелый и неприятный.
У меня безоговорочный приоритет получил бы кандидат, который, перед тем как писать код задал бы несколько вопросов.
какого размера массивы в параметрах, есть ли смысл тут писать оптимальное решение в ущерб читаемости кода
нет ли возможности отрефакторить, вызывающий код так, чтобы избежать написания алгоритма и обойтись сортировкой из стандартной библиотеки
приватный это метод или публичный, нужна ли проверка на то, что массивы отсортированы
Ну и так далее. Это если конечно мы проверяем "насколько хорошо варит голова кандидата в бою".
По сути нужен не HR, нужен помощник/секретарь, который чуть сократит время работы тимлида, а не зарежет, поржав с девочками, всех релевантных кандидатов. Но, если секретаря нет, то тоже не страшно. Если компания большая, и ее HR саботирует процесс найма, как в этом посте, то я бы попробовал хотя бы некоторым командам дать возможность самим искать себе кадры.
Вот реальный кейс поиска фронтенд (react, mobx, ts) - мидла в noname микро компанию месяц назад.
публикация на hh
200 откликов за первый день, вакансию скрываем - горшочек не вари
Один человек за несколько часов просматривает 100 резюме из присланных, и отправляет либо предложение договориться о собеседовании в телеграмме либо отказ.
Из 100 резюме в воронке, назначено и проведено 17 собеседований.
Собеседование проводится двумя главными разработчиками (тимлидами). Время на собеседование - час. Форма - разговор, с техническими вопросами. После собеседования 15 минут перекур и обсуждение кандидата. 17 собеседований занимают примерно 5 рабочих дней.
Отобрано 2 финалиста. Сделан оффер первому и он принял предложение.
Итого от размещения вакансии до выхода человека на работу прошло 3 недели. Сотрудник с работой справляется, представлению тимлидов о фронтенд мидле соответствует.
В моей картине мира именно по этой вакансии была очередь за забором.
Мой личный опыт (разработчик и внезапный генеральный директор продуктовой микро компании) показывает, что фич, которые приносят деньги и не оттестированы не бывает в природе. В основном они приносят внезапный головняк, что для микро компании чревато срывом сроков по другим продуктам. Поэтому обычно переговоры с разработчиками ведутся по вопросу, как написать фичу без оверинжиниринга, а не о том надо ли ее писать без тестов и под рефакторинг или не надо.
Если продакт менеджер говорит а почему 20, давай 10 и его нужно убеждать в том, что писать новую фичу без тестов и сразу под рефакторинг это плохо, то это говорит о его потенциальной профнепригодности. Адекватный диалог - должен звучать так:
20 часов?
Качественно и с тестами?
Да
Ок, вперед. (Или если во время не укладываемся) Ладно выпустим в следующем релизе.
...кровати двигает
Я ту недавно, в Москве, менял генерального директора в ООО, после внезапной гибели предыдущего гендиректора, который в то-же время являлся владельцем 50% доли этого ООО. Это достаточно неприятный казус в таком сочетании. И ни разу не сидел на подоконниках и не заполнял бланки. В основном процесс построен так, что тебе присылают инструкции, которые ты выполняешь. И даже в этом тяжелом случае, обычный программист, которым я по сути являюсь, справился с возвратом управления компании. Так что как минимум в Москве с бюрократией все замечательно.
Это миф о мифах, за 15 лет работы в постсоветском IT такие подходы к работе я не встречал ни разу. Зато постсоветское IT характеризуется подходом - сначала попытаться разобраться, почитать документацию, погуглить, а потом уже писать вопросы в поддержку. И это отличный, экономящий огромное количество времени подход к работе.