1) Найм и требования действительно изменились. Если раньше было достаточно просто хорошо делать свою работу, то теперь надо быть эрудированным. Сегодняшний мидл - вчерашний сеньер. 2) Найм сломан... Никому больше не интересно хороший вы работник или нет. Корпорации не могут это проверит, а кандидаты все лгут, да ещё и выбор огромный. Вот они и изобрели серебряную пулю для себя. Чтобы в итоге? Компании упакована исполнителями.90% из них пофиг на свой продукт, только плати. Все они топы, каждый думает о себе. Все они не важны - любого можно заменить. Кодовая база на уровня студента первокурсника - нет времени разбираться с тех долгами, есть продукты и прибыль. Итог: IT больше не ламповая разработка. Это бизнес, детка. 3) что делать? Ничего. Нейронкитво вот сожрут весь этот планктон. Они уже жрут, просто зашоренный взор мешает разрабам это увидеть. Многие продолжают это отрицать. Через 5 лет половина из сегодняшних сеньоров будет во всю переучиваться на ml dev разработку, вторая половина выдохнется, придут новые, свежие люди. Мб тогда процесс сломается ещё раз?
Спасибо за статью! У меня есть шапошные знакомые которые пекут хлеб на целый город под 400 тысяч человек. Они насколько я знаю имеют тыс по 5$ на хозяина, коих вроде как три. Но их ждут местные точки: открывается Окей или тип того, внутри сразу же пекарня. Раньше они могли продать свой хлеб всем мелким и крупным ларькам, теперь гибнуть ларьки, уходит спрос. Но там на производстве работает под сотню человек. Она трят в день несколько тон муки. Как-то так)
это вы уже не задачу решаете, а проект. А я говорю о задаче - ставите задачу перед машинкой, она вам все прочситает по конкретной детали в 5 минут, вы проверяете, поправляете и переходите к следующему блоку. Времена когда вы можете скормить госты и ТЗ на проект и получит готовый результат... за это я судить не берусь. Возможно мы увидим это очень скоро, а мб не увидим до самой смерти - всякое может быть
Фейспалм - это обижаться на критику своей статьи)) Вы же не думали, что в РФ можно что-то писать и ждать мягкой реакции? У нас общество жесткое, любит с говном смешать вне зависимости от вашей позиции - привыкайте. Я кстати вашему коменту лайк поставил, а статье дизлайк, т.к. полностью с ней не согласен))
В найме сломано почти все) Иначе как объяснить дефицит квалифицированных кадров?) с каждым годом разработчиков с реальным 5 летним опытом все больше, а дефицита кадров меньше не становится. Компании ищут не просто лучших разработчиков, они ищут чемпионов и делают это максимально субъективно. Кстати, ваш эксперимент подтверждает проблемы на первом этапе, но он не опровергает наличие или отсутствие проблем на остальных этапах, коих мы знаем не мало. Так что там все максимально криво и косо) Умение проходить собесы + настойчивость + удача = залог успешного прохождения в один из биг техов. Не знания и умение работать - заметьте это! Я видел таких сеньеров, которые проводят собесы, а потом видел их код - это даже не мидлы, но в компании они ценятся за эрудицию
Весь ужас в том, что идёт жуткая инфляция знаний. То что раньше считалось нормой для мидла теперь спрашивают с Джуна, с мидла спрашивают как с сеньера, а на сеньера лид перекладывает свою работу - ему никогда, он руководит сразу M командами. Итог каждый рвет жопу хз зачем)
Интересная статья, спасибо. У меня вот такой вопрос: сейчас много кто стал страдать Backend Dru UI, так почему бы вместо этого, не подгружать все обновления в виде динамической фичи? Определить все приложение как одну фичу, подгружать новые версии через динамический модуль. Как считаете, это работало бы?
Использую и GPT и Copilot. Нет сомнений, что заменит)) Лично я уже заменил го разработчика и фронтера в своем стартапе. Т.е. двое мидлов остались без работы с текущей нейронной. 5 лет максимум и 90% из нас будет учиться работать по-новой
я бы предложил еще расширить понятие useCase - использовать это как утилитарный класс для любой нужды (помимо связки viewmodel + repository). Название может кого-то смутить, но "use case" еть "случай использования", т.е. по сути что угодно что выполняет 1 конкретную задачу
Активно использую useCase - выношу в них все что можно и ничего в этом страшного нет. Да 90% из них так и остаются одноразовыми и закрытыми фичами. Зато это чистое ООП, где на каждую задачу еть свой выделенный класс. Главная задача useCase-ов уменьшить кодовую базу и облегчить тестирование. Если у вас все в едином файле на 2к сипрк, работать с этим сложно, а покрывать такую логику unit тестами вообще больно, если не невозможно. Так что лучше useCase-ов пока ничего не видел. Позволю себе привести здесь пример своего опен-сорсного проекта где useCase-ов на каждый чих (https://github.com/georrge1994/polykek-schedule-app/tree/main). Проекты же, где от них отказались выгледят крайне"замусоренными" и неаккуратными
+200 сейчас только если вы за тенге работаете)
и в правду) но у вас всегда годные статьи. Кроме вас авансом тут никому не ставлю))
Лайк авансом - истории всегда топовые
1) Найм и требования действительно изменились. Если раньше было достаточно просто хорошо делать свою работу, то теперь надо быть эрудированным. Сегодняшний мидл - вчерашний сеньер. 2) Найм сломан... Никому больше не интересно хороший вы работник или нет. Корпорации не могут это проверит, а кандидаты все лгут, да ещё и выбор огромный. Вот они и изобрели серебряную пулю для себя. Чтобы в итоге? Компании упакована исполнителями.90% из них пофиг на свой продукт, только плати. Все они топы, каждый думает о себе. Все они не важны - любого можно заменить. Кодовая база на уровня студента первокурсника - нет времени разбираться с тех долгами, есть продукты и прибыль. Итог: IT больше не ламповая разработка. Это бизнес, детка. 3) что делать? Ничего. Нейронкитво вот сожрут весь этот планктон. Они уже жрут, просто зашоренный взор мешает разрабам это увидеть. Многие продолжают это отрицать. Через 5 лет половина из сегодняшних сеньоров будет во всю переучиваться на ml dev разработку, вторая половина выдохнется, придут новые, свежие люди. Мб тогда процесс сломается ещё раз?
Спасибо за статью! У меня есть шапошные знакомые которые пекут хлеб на целый город под 400 тысяч человек. Они насколько я знаю имеют тыс по 5$ на хозяина, коих вроде как три. Но их ждут местные точки: открывается Окей или тип того, внутри сразу же пекарня. Раньше они могли продать свой хлеб всем мелким и крупным ларькам, теперь гибнуть ларьки, уходит спрос. Но там на производстве работает под сотню человек. Она трят в день несколько тон муки. Как-то так)
Спасибо за развернутый ответ!
это вы уже не задачу решаете, а проект. А я говорю о задаче - ставите задачу перед машинкой, она вам все прочситает по конкретной детали в 5 минут, вы проверяете, поправляете и переходите к следующему блоку. Времена когда вы можете скормить госты и ТЗ на проект и получит готовый результат... за это я судить не берусь. Возможно мы увидим это очень скоро, а мб не увидим до самой смерти - всякое может быть
Фейспалм - это обижаться на критику своей статьи)) Вы же не думали, что в РФ можно что-то писать и ждать мягкой реакции? У нас общество жесткое, любит с говном смешать вне зависимости от вашей позиции - привыкайте. Я кстати вашему коменту лайк поставил, а статье дизлайк, т.к. полностью с ней не согласен))
В найме сломано почти все) Иначе как объяснить дефицит квалифицированных кадров?) с каждым годом разработчиков с реальным 5 летним опытом все больше, а дефицита кадров меньше не становится. Компании ищут не просто лучших разработчиков, они ищут чемпионов и делают это максимально субъективно. Кстати, ваш эксперимент подтверждает проблемы на первом этапе, но он не опровергает наличие или отсутствие проблем на остальных этапах, коих мы знаем не мало. Так что там все максимально криво и косо) Умение проходить собесы + настойчивость + удача = залог успешного прохождения в один из биг техов. Не знания и умение работать - заметьте это! Я видел таких сеньеров, которые проводят собесы, а потом видел их код - это даже не мидлы, но в компании они ценятся за эрудицию
Хаха, но у вас статья скорее "не все так плохо, и в целом очень даже справедливо" - за это камнями и бьют))
Весь ужас в том, что идёт жуткая инфляция знаний. То что раньше считалось нормой для мидла теперь спрашивают с Джуна, с мидла спрашивают как с сеньера, а на сеньера лид перекладывает свою работу - ему никогда, он руководит сразу M командами. Итог каждый рвет жопу хз зачем)
луддиты всегда будут)
О, коллега) Работаю в той же связке. По ощущениям +30% к скорости разработки
Плюс один)) Просто это инструменты которыми надо уметь пользоваться и учиться пользоваться
Ну, здесь мне кажется ответ очевиден - в скорости работы + с течением времени контроль станет просто не нужен или сведется к 5 минутной проверке
Интересная статья, спасибо. У меня вот такой вопрос: сейчас много кто стал страдать Backend Dru UI, так почему бы вместо этого, не подгружать все обновления в виде динамической фичи? Определить все приложение как одну фичу, подгружать новые версии через динамический модуль. Как считаете, это работало бы?
Использую и GPT и Copilot. Нет сомнений, что заменит)) Лично я уже заменил го разработчика и фронтера в своем стартапе. Т.е. двое мидлов остались без работы с текущей нейронной. 5 лет максимум и 90% из нас будет учиться работать по-новой
я бы предложил еще расширить понятие useCase - использовать это как утилитарный класс для любой нужды (помимо связки viewmodel + repository). Название может кого-то смутить, но "use case" еть "случай использования", т.е. по сути что угодно что выполняет 1 конкретную задачу
Активно использую useCase - выношу в них все что можно и ничего в этом страшного нет. Да 90% из них так и остаются одноразовыми и закрытыми фичами. Зато это чистое ООП, где на каждую задачу еть свой выделенный класс. Главная задача useCase-ов уменьшить кодовую базу и облегчить тестирование. Если у вас все в едином файле на 2к сипрк, работать с этим сложно, а покрывать такую логику unit тестами вообще больно, если не невозможно. Так что лучше useCase-ов пока ничего не видел. Позволю себе привести здесь пример своего опен-сорсного проекта где useCase-ов на каждый чих (https://github.com/georrge1994/polykek-schedule-app/tree/main). Проекты же, где от них отказались выгледят крайне"замусоренными" и неаккуратными