Comments 39
Многие боятся, что как только джуниор вырастет, он уйдет. Но, на мой взгляд, это немного странно, поскольку фронтендеры постоянно меняют место работы. Это уже стало нормой.
А почему странно? Совсем не хочется джуниора — год вкладываешь в его развитие и машешь ручкой. И здесь можно понять джуна, ведь на рынке его стоимость чуть ли не удвоилась, а поднимать з/п вдвое на старом месте, после года вложений, никто не будет.
Так и почему не пойти сразу на рынок за мидлом?
А джуниор не вкладывается, что ли? Работы не делает?
Тут по разному. На его обучение может быть потрачено больше времени сеньоров и лидов, чем они бы потратили сами на делегированные ему задачи. Это без учёта потерянной прибыли от задержек реализации фич, просто по взвешенной трудоемкости задач.
Ошибочно считать вложениями в специалиста только его зарплату и «печеньки». Прежде всего это вложения времени других специалистов.
Ошибочно считать вложениями в специалиста только его зарплату и «печеньки». Прежде всего это вложения времени других специалистов.
Тут по разному. На его обучение может быть потрачено больше времени сеньоров и лидов, чем они бы потратили сами на делегированные ему задачи.Я вас умоляю. Сеньоры и лиды не тратят время на джуниора. Да у них на обсуждения со «старыми» коллегами больше времени уходит.
Это без учёта потерянной прибыли от задержек реализации фич, просто по взвешенной трудоемкости задач.Срочные фичи джуниорам опять же не дают.
> Я вас умоляю. Сеньоры и лиды не тратят время на джуниора. Да у них на обсуждения со «старыми» коллегами больше времени уходит
Всё зависит от процессов. Уж ревью кодда джунов по нынешним временам практически везде. И на практике ревью джунов отнимает гораздо больше времени, чем «старых», с которыми обсуждаются рабочие вопросы как часть нормального рабочего процесса.
Всё зависит от процессов. Уж ревью кодда джунов по нынешним временам практически везде. И на практике ревью джунов отнимает гораздо больше времени, чем «старых», с которыми обсуждаются рабочие вопросы как часть нормального рабочего процесса.
Неоплаченные затраты у большинства специалистов будут побольше, чем вложения фирм в них. Как финансовые, так и временные. Затраты на учебу по специальности, затраты на самообучение, на постоянное изучение технологий, которые через какое-то время оказываются невостребованными, затраты времени на дорогу на работу и обратно, затраты на поиск работы и подготовку к собеседованиям.
Так и почему не пойти сразу на рынок за мидлом?Уйти любой спец может. В проектах нужны разработчики разного уровня. Под задачи нужно нанимать, а не под необоснованные хотелки. Если есть кучи задач, с которыми вполне справиться джуниор, не нанеся серьезного ущерба в виде не читаемого другими кода, задержками исполнения срочных задач или еще как-нибудь, зачем нанимать крутого спеца и платить в несколько раз больше? Он и время и нервы более опытного может сэкономить, освобождая того от рутинных и однотипных задач. Если задачи сложные, то зачем рисковать и экономить, нанимая джуниора?
> Неоплаченные затраты у большинства специалистов будут побольше, чем вложения фирм в них. Как финансовые, так и временные. Затраты на учебу по специальности, затраты на самообучение, на постоянное изучение технологий, которые через какое-то время оказываются невостребованными, затраты времени на дорогу на работу и обратно, затраты на поиск работы и подготовку к собеседованиям.
На рынке труда эти затраты скрыты, как и затраты компаний на обучение хоть джунов, хоть сеньоров и архитекторов. Всё это отражается в «мгновенных» значениях хотелок соискателей и компаний.
> Уйти любой спец может. В проектах нужны разработчики разного уровня. Под задачи нужно нанимать, а не под необоснованные хотелки.
Может, да. Нужны, да. Но работодатели жалуются на опускание планки соискателей. Джуны с теми же (с учетом новаций) знаниями и опытом, что 5 лет назад позиционируют себя уже как миддлы, а на джунов идут те, кто раньше не претендовал больше чем на стажера/трейни
На рынке труда эти затраты скрыты, как и затраты компаний на обучение хоть джунов, хоть сеньоров и архитекторов. Всё это отражается в «мгновенных» значениях хотелок соискателей и компаний.
> Уйти любой спец может. В проектах нужны разработчики разного уровня. Под задачи нужно нанимать, а не под необоснованные хотелки.
Может, да. Нужны, да. Но работодатели жалуются на опускание планки соискателей. Джуны с теми же (с учетом новаций) знаниями и опытом, что 5 лет назад позиционируют себя уже как миддлы, а на джунов идут те, кто раньше не претендовал больше чем на стажера/трейни
Может, да. Нужны, да. Но работодатели жалуются на опускание планки соискателей. Джуны с теми же (с учетом новаций) знаниями и опытом, что 5 лет назад позиционируют себя уже как миддлы, а на джунов идут те, кто раньше не претендовал больше чем на стажера/трейниБольше верится, что возраст работодателей дает о себе знать. Давно ведь уже известно:
Не знаю, насчет опускания планки соискателей. Зато замечаю повышение планки в вакансиях. Это касательно старых технологий. В новых областях первое время требования не завышенные.
Очень интересно.
То есть стоимость чуть ли не удвоилось а поднимать зп почему никто не будет?
Это же супер логично, что он уйдет туда, где у него будет намного большая зарплата.
Не в адекватной оплате труда ли секрет?
То есть стоимость чуть ли не удвоилось а поднимать зп почему никто не будет?
Это же супер логично, что он уйдет туда, где у него будет намного большая зарплата.
Не в адекватной оплате труда ли секрет?
Удвоилась в текущем моменте, но перед этим были ещё месяцы, когда он работал в минус.
Рынок труда работает исключительно в текущем моменте (обещание участия в прибыли уже не совсем рынок труда). Работа в минус — это не инвестиции в будущую работу в плюс, а инвестиции в отсутствие работы в минус кучи других людей когда джун уйдёт туда, где его оценят по рынку. Незаменимых не должно быть, но любая замена — это затраты.
Про текущий момент всё понятно, но это ответ на тот исходный вопрос, почему многие не хотят связываться.
Работа в минус — подразумевается, что первое время от отнимает много времени и внимания других людей. То есть затраты на его обучение намного выше его номинальной з/п.
Работа в минус — подразумевается, что первое время от отнимает много времени и внимания других людей. То есть затраты на его обучение намного выше его номинальной з/п.
Да джуниор делает меньше задач и дольше чем мидл, но ведь зп ему платят в столько же раз меньше, но вот когда он начал делать задачи в два раза быстрее, то логично было бы поднять в столько же раз и зп, но дело в том что некоторым компаниям пихологически сложно поднять зп в два три раза, сам по тем же причинам уходил
Проблема том, что джун на зарплату в столько раз меньшую не идет. Поэтому миддлу платят не в N раз больше. И это проблема как со стороны джунов, которые много хотят, и со стороны работодателей, которые не готовы адекватно бустить ЗП. Собственно поэтому джуны и хотят много, и уходят часто.
но ведь зп ему платят в столько же раз меньшеНе в столько же.
Я понимаю, что ситуации могут быть разные, но по моему мнению, в пересчете на 1 условный рубль мидл делает намного больше. Потому что джун будет:
а) изначально тратить больше времени;
б) писать больше говнокода, который потом аукнется гораздо большим количеством багов и затратами на поддержку;
в) требовать внимания со стороны старших сотрудников, отнимая их время, которое к тому же дороже.
В итоге, имея (условно) номинальную зарплату вдвое меньше, количество пользы меньше вчетверо.
Сужу только по своему опыту, устроился в компанию джуниором, хотя уровенем уже был далеко не джун(с зп в 350 у.е., понравилась компания, и обещали быстрый рост) и в качестве работы не сильно уступал мидлам, у них зп там была около 1500 у.е.
В итоге проработав год, в зп поднялся до 700 у.е. а вот по скорости и качеству работы обогнал мидлов которые там работали, вот только поднять зп до их уровня мне отказали, т.к. я там проработал только год, а они уже более 3-х лет
Может у Вас и по другому было, но я столкнулся с этим на личном опыте
В итоге проработав год, в зп поднялся до 700 у.е. а вот по скорости и качеству работы обогнал мидлов которые там работали, вот только поднять зп до их уровня мне отказали, т.к. я там проработал только год, а они уже более 3-х лет
Может у Вас и по другому было, но я столкнулся с этим на личном опыте
Тут возможны варианты:
1. Политический — руководство не захотело провоцировать волну требований о повышении от ряда других сотрудников.
2. Когнитивный — вам только кажется, что вы их во всём обогнали, а на самом деле есть ещё некие факторы, которые вам не видны, но видны руководству.
3. Сочетание обоих вышеперечисленных пунктов.
1. Политический — руководство не захотело провоцировать волну требований о повышении от ряда других сотрудников.
2. Когнитивный — вам только кажется, что вы их во всём обогнали, а на самом деле есть ещё некие факторы, которые вам не видны, но видны руководству.
3. Сочетание обоих вышеперечисленных пунктов.
Всё правильно! Так и зачем нужны такие напряги, когда можно сразу взять мидла и работать с ним долго и счастливо?
Постоянная текучка джунов также сказывается и на моральном состоянии постоянных сотрудников: с первым повозятся, со вторым повозятся, третьему уже никто не будет уделять много внимания – всё равно уйдет.
Заключать с джуном контракт на минимальный срок — тоже рискованная мера. Хорошо, если человек добросовестный попадется. А если нет?
Постоянная текучка джунов также сказывается и на моральном состоянии постоянных сотрудников: с первым повозятся, со вторым повозятся, третьему уже никто не будет уделять много внимания – всё равно уйдет.
Заключать с джуном контракт на минимальный срок — тоже рискованная мера. Хорошо, если человек добросовестный попадется. А если нет?
Заключайте контракт не по негласному соглашению, а с трудовой. Конечно в этом случае вашей стороне (фирме) придется соблюдать ТК, но ведь и вы сможете на него подать в суд в случае чего.
А то получается — «мы его взяли на 5к белой зарплаты, остальное в конвертике, налоги не платим, требуем с него переработок, за которые не платим, а потом обижаемся, что он нас кинул»
А то получается — «мы его взяли на 5к белой зарплаты, остальное в конвертике, налоги не платим, требуем с него переработок, за которые не платим, а потом обижаемся, что он нас кинул»
Про фулстек верно подмечено, только фулстеки обижаются на это.
А откуда браться людям способным спланировать архитектуру в целом, если «каждый спец только в свой области»?
что то полный раздрай, один человек если это проект не личный бложик такие вещи не планирует. Ну невозможно разбираться одному человеку качественно в современном fe и так же качественно в современном be, это все мифы. По верхам можно знать, или очень редкие единороги что автор расписал у которых по 10 лет опыта.
Пользы от намеренного изучения рядовыми разработчиками fullstack'a нет.
- А: неоправданно тяжелее собеседоваться
- Б: им не платят больше
- В: чаще предлагают работу с просто катастрофической нагрузкой
Даже будучи фуллстеком, всегда выгодней искать вакансию Back/Front.
Только если лежит душа к позиции руководителя, fullstack как цель обретает смысл.
UFO just landed and posted this here
Про фулстеков — не согласен. Архитектор, key developer, или любой другой главный по технике — должен шарить и фронт, и бек. Руководить разработкой, зная только половину его стека — полный бред же. Так что если хочется расти выше мидла — надо как минимум поверхностно разбираться в обоих частях.
надо как минимум поверхностно разбираться в обоих частях
Фулстек как раз таки тот кто может выполнять задачи по всему стеку, а не поверхностно разбираться. Разбираться и разрабатывать две большие разницы, между ними пропасть.
«разбираться» не подразумевает «может выполнять задачи», «разрабатывать»? Пускай на подзадачи по фронту и бэку уйдёт больше времени и(или) они будут решены менее эффективным по вычресурсам способом, но разве разбирающийся человек не способен решать задачи?
Так-то и абсолютно любой человек может разрабатывать прямо с улицы, но ему потребуется больше времени и качество пострадает =)
А если серьезно, да сможет, но в процессе ему придется учиться осваивая инструменты и наступая на грабли нюансов и таким образом превращаясь из «разбирающегося» в разработчика. Кроме того разрабатывать, т.е. выполнять задачи уже подразумевает сроки и качество (критерии за которые платит заказчик). Безусловно четкой границы нет, но все же специалист это в большей степени тот, кто может решить задачу, а на не научится это делать.
А если серьезно, да сможет, но в процессе ему придется учиться осваивая инструменты и наступая на грабли нюансов и таким образом превращаясь из «разбирающегося» в разработчика. Кроме того разрабатывать, т.е. выполнять задачи уже подразумевает сроки и качество (критерии за которые платит заказчик). Безусловно четкой границы нет, но все же специалист это в большей степени тот, кто может решить задачу, а на не научится это делать.
В последние годы этот «зоопарк» уже достигает абсурда — люди начинают выбирать технологии просто потому, что у них больше звездочек на GitHub.
На бэкэнде такое творится уже давно.
В прошлом году имел печальный опыт работы с одним «Agnostic»-фреймворком для аутентификации (аутентификация «искаропки» для лары не устроила), который выбрали только потому, что…
… у него было много «лайков» на гитхабе.
То, что у него отвратительная документация, под капотом — дичайший говнокод, а работа с базой неоптмизирована совершенно (чего стоит поиск по varchar(255) без индекса?) — не являлось для техдира аргументом «против».
Ведь у него «много лайков на гитхабе!». Это главный аргумент «за».
P.S. простите, было больно.
В целом «количество звездочек» и «от него зависят ...» является косвенной метрикой длительности поддержки. Другой обычно просто нет.
«Качество проекта» — интегральная характеристика и формулу качества вывести вряд ли возможно.
При оценке следует учитывать количество форков, принятых/отвергнутых пулл-реквестов, количество открытых/закрытых ишью и количество коммитов вообще.
А вовсе не количество «лайков».
Ну и конечно, историю закрытия ишью. Если ишью висит с 2013 года и к нему 0 комментариев — вряд ли проект можно считать «поддерживаемым».
Банальный пример: мой проект лайкнул какой-то чувак. Я заинтересовался… выяснилось, что он лайкнул каждый мой репозиторий, более того, он лайкает все репозитории подряд. Можно ли после этого считать, что мой репозиторий стал «лучше»?
При оценке следует учитывать количество форков, принятых/отвергнутых пулл-реквестов, количество открытых/закрытых ишью и количество коммитов вообще.
А вовсе не количество «лайков».
Ну и конечно, историю закрытия ишью. Если ишью висит с 2013 года и к нему 0 комментариев — вряд ли проект можно считать «поддерживаемым».
Банальный пример: мой проект лайкнул какой-то чувак. Я заинтересовался… выяснилось, что он лайкнул каждый мой репозиторий, более того, он лайкает все репозитории подряд. Можно ли после этого считать, что мой репозиторий стал «лучше»?
Многие боятся, что как только джуниор вырастет, он уйдет.Видел то ли на каком-то форуме, то ли на баше:
— А вы не боитесь, что мы сейчас вложимся в джуниоров, они всему научатся, а потом уйдут?
— Это не страшно. Страшно, если они ничему не научатся и останутся.
JS-разработчикам надо понимать, что они должны уметь верстать.
JS-разработчикам гораздо важнее быть хорошими программистами. Со всем входящим в этот перечень.
Вот эту часть не понял:
Как такое возможно? Может быть есть конкретные примеры? Просто инетересно. Я всегда думал, что «голый» JS всегда будет производительнее и гибче, чем любой фреймворк.
… мы в какой-то момент просто уперлись в производительность. Изначально все было написано на нативном JavaScript, но с выходом очередной фичи мы поняли, что дальше развивать продукт на этом ядре мы не можем.
Как такое возможно? Может быть есть конкретные примеры? Просто инетересно. Я всегда думал, что «голый» JS всегда будет производительнее и гибче, чем любой фреймворк.
Любое большое жизнеспособное решение на "голом JS" это тоже фреймворк, просто свой. А гибче он и производительнее ли — зависит от обстоятельств.
В популярных фреймворках обычно много усилий прилагают для оптимизаций. Успех React некоторые считают заслугой единственной оптимизации — инкрементный ререндинг DOM для достижения целевого состояния.
Мне кажется, он имел в виду производительность работы, которая понятно, что на фреймверке будет выше нежели на голом js.
Sign up to leave a comment.
Frontend 2018: многообразие фреймворков и недостаток миддлов