Блог компании Конференции Олега Бунина (Онтико)
JavaScript
Интерфейсы
Конференции
Комментарии 38
0
Многие боятся, что как только джуниор вырастет, он уйдет. Но, на мой взгляд, это немного странно, поскольку фронтендеры постоянно меняют место работы. Это уже стало нормой.

А почему странно? Совсем не хочется джуниора — год вкладываешь в его развитие и машешь ручкой. И здесь можно понять джуна, ведь на рынке его стоимость чуть ли не удвоилась, а поднимать з/п вдвое на старом месте, после года вложений, никто не будет.
Так и почему не пойти сразу на рынок за мидлом?
+6
Тут по разному. На его обучение может быть потрачено больше времени сеньоров и лидов, чем они бы потратили сами на делегированные ему задачи. Это без учёта потерянной прибыли от задержек реализации фич, просто по взвешенной трудоемкости задач.

Ошибочно считать вложениями в специалиста только его зарплату и «печеньки». Прежде всего это вложения времени других специалистов.
+1
Тут по разному. На его обучение может быть потрачено больше времени сеньоров и лидов, чем они бы потратили сами на делегированные ему задачи.
Я вас умоляю. Сеньоры и лиды не тратят время на джуниора. Да у них на обсуждения со «старыми» коллегами больше времени уходит.

Это без учёта потерянной прибыли от задержек реализации фич, просто по взвешенной трудоемкости задач.
Срочные фичи джуниорам опять же не дают.
+2
> Я вас умоляю. Сеньоры и лиды не тратят время на джуниора. Да у них на обсуждения со «старыми» коллегами больше времени уходит

Всё зависит от процессов. Уж ревью кодда джунов по нынешним временам практически везде. И на практике ревью джунов отнимает гораздо больше времени, чем «старых», с которыми обсуждаются рабочие вопросы как часть нормального рабочего процесса.
0
Неоплаченные затраты у большинства специалистов будут побольше, чем вложения фирм в них. Как финансовые, так и временные. Затраты на учебу по специальности, затраты на самообучение, на постоянное изучение технологий, которые через какое-то время оказываются невостребованными, затраты времени на дорогу на работу и обратно, затраты на поиск работы и подготовку к собеседованиям.

Так и почему не пойти сразу на рынок за мидлом?
Уйти любой спец может. В проектах нужны разработчики разного уровня. Под задачи нужно нанимать, а не под необоснованные хотелки. Если есть кучи задач, с которыми вполне справиться джуниор, не нанеся серьезного ущерба в виде не читаемого другими кода, задержками исполнения срочных задач или еще как-нибудь, зачем нанимать крутого спеца и платить в несколько раз больше? Он и время и нервы более опытного может сэкономить, освобождая того от рутинных и однотипных задач. Если задачи сложные, то зачем рисковать и экономить, нанимая джуниора?
0
> Неоплаченные затраты у большинства специалистов будут побольше, чем вложения фирм в них. Как финансовые, так и временные. Затраты на учебу по специальности, затраты на самообучение, на постоянное изучение технологий, которые через какое-то время оказываются невостребованными, затраты времени на дорогу на работу и обратно, затраты на поиск работы и подготовку к собеседованиям.

На рынке труда эти затраты скрыты, как и затраты компаний на обучение хоть джунов, хоть сеньоров и архитекторов. Всё это отражается в «мгновенных» значениях хотелок соискателей и компаний.

> Уйти любой спец может. В проектах нужны разработчики разного уровня. Под задачи нужно нанимать, а не под необоснованные хотелки.

Может, да. Нужны, да. Но работодатели жалуются на опускание планки соискателей. Джуны с теми же (с учетом новаций) знаниями и опытом, что 5 лет назад позиционируют себя уже как миддлы, а на джунов идут те, кто раньше не претендовал больше чем на стажера/трейни
+1
Может, да. Нужны, да. Но работодатели жалуются на опускание планки соискателей. Джуны с теми же (с учетом новаций) знаниями и опытом, что 5 лет назад позиционируют себя уже как миддлы, а на джунов идут те, кто раньше не претендовал больше чем на стажера/трейни
Больше верится, что возраст работодателей дает о себе знать. Давно ведь уже известно: image
Не знаю, насчет опускания планки соискателей. Зато замечаю повышение планки в вакансиях. Это касательно старых технологий. В новых областях первое время требования не завышенные.
+6
Очень интересно.
То есть стоимость чуть ли не удвоилось а поднимать зп почему никто не будет?
Это же супер логично, что он уйдет туда, где у него будет намного большая зарплата.
Не в адекватной оплате труда ли секрет?
0
Удвоилась в текущем моменте, но перед этим были ещё месяцы, когда он работал в минус.
0
Рынок труда работает исключительно в текущем моменте (обещание участия в прибыли уже не совсем рынок труда). Работа в минус — это не инвестиции в будущую работу в плюс, а инвестиции в отсутствие работы в минус кучи других людей когда джун уйдёт туда, где его оценят по рынку. Незаменимых не должно быть, но любая замена — это затраты.
0
Про текущий момент всё понятно, но это ответ на тот исходный вопрос, почему многие не хотят связываться.
Работа в минус — подразумевается, что первое время от отнимает много времени и внимания других людей. То есть затраты на его обучение намного выше его номинальной з/п.
0
Да джуниор делает меньше задач и дольше чем мидл, но ведь зп ему платят в столько же раз меньше, но вот когда он начал делать задачи в два раза быстрее, то логично было бы поднять в столько же раз и зп, но дело в том что некоторым компаниям пихологически сложно поднять зп в два три раза, сам по тем же причинам уходил
0
Проблема том, что джун на зарплату в столько раз меньшую не идет. Поэтому миддлу платят не в N раз больше. И это проблема как со стороны джунов, которые много хотят, и со стороны работодателей, которые не готовы адекватно бустить ЗП. Собственно поэтому джуны и хотят много, и уходят часто.
+2
Видимо, им не хватает на жизнь, вот они и уходят. Джун обычно ест столько же, сколько и миддл.
0
но ведь зп ему платят в столько же раз меньше
Не в столько же.
Я понимаю, что ситуации могут быть разные, но по моему мнению, в пересчете на 1 условный рубль мидл делает намного больше. Потому что джун будет:
а) изначально тратить больше времени;
б) писать больше говнокода, который потом аукнется гораздо большим количеством багов и затратами на поддержку;
в) требовать внимания со стороны старших сотрудников, отнимая их время, которое к тому же дороже.
В итоге, имея (условно) номинальную зарплату вдвое меньше, количество пользы меньше вчетверо.
0
Сужу только по своему опыту, устроился в компанию джуниором, хотя уровенем уже был далеко не джун(с зп в 350 у.е., понравилась компания, и обещали быстрый рост) и в качестве работы не сильно уступал мидлам, у них зп там была около 1500 у.е.
В итоге проработав год, в зп поднялся до 700 у.е. а вот по скорости и качеству работы обогнал мидлов которые там работали, вот только поднять зп до их уровня мне отказали, т.к. я там проработал только год, а они уже более 3-х лет
Может у Вас и по другому было, но я столкнулся с этим на личном опыте
0
Тут возможны варианты:
1. Политический — руководство не захотело провоцировать волну требований о повышении от ряда других сотрудников.
2. Когнитивный — вам только кажется, что вы их во всём обогнали, а на самом деле есть ещё некие факторы, которые вам не видны, но видны руководству.
3. Сочетание обоих вышеперечисленных пунктов.
0
Всё правильно! Так и зачем нужны такие напряги, когда можно сразу взять мидла и работать с ним долго и счастливо?
Постоянная текучка джунов также сказывается и на моральном состоянии постоянных сотрудников: с первым повозятся, со вторым повозятся, третьему уже никто не будет уделять много внимания – всё равно уйдет.
Заключать с джуном контракт на минимальный срок — тоже рискованная мера. Хорошо, если человек добросовестный попадется. А если нет?
+1
Заключайте контракт не по негласному соглашению, а с трудовой. Конечно в этом случае вашей стороне (фирме) придется соблюдать ТК, но ведь и вы сможете на него подать в суд в случае чего.

А то получается — «мы его взяли на 5к белой зарплаты, остальное в конвертике, налоги не платим, требуем с него переработок, за которые не платим, а потом обижаемся, что он нас кинул»
+1
Про фулстек верно подмечено, только фулстеки обижаются на это.
0
А откуда браться людям способным спланировать архитектуру в целом, если «каждый спец только в свой области»?
0
что то полный раздрай, один человек если это проект не личный бложик такие вещи не планирует. Ну невозможно разбираться одному человеку качественно в современном fe и так же качественно в современном be, это все мифы. По верхам можно знать, или очень редкие единороги что автор расписал у которых по 10 лет опыта.
+1

Пользы от намеренного изучения рядовыми разработчиками fullstack'a нет.


  • А: неоправданно тяжелее собеседоваться
  • Б: им не платят больше
  • В: чаще предлагают работу с просто катастрофической нагрузкой

Даже будучи фуллстеком, всегда выгодней искать вакансию Back/Front.
Только если лежит душа к позиции руководителя, fullstack как цель обретает смысл.

0
Верно, да не совсем. Есть класс проектов, где не нужны топовые технологии, не нужна адова оптимизация, топовая безопасность, расширяемая архитектура и т.д. Причем это не только лэндинги, но и вполне себе средние сайты и веб-приложения, которые может тянуть один человек. Тянуть в смысле поднять сервер, худо-бедно спроектировать базу, написать бэкенд, фронтенд, настроить резервное копирование и осуществлять поддержку.

Очевидно что он не будет знать в совершенстве ничего из вышеперечисленного, и на конференции блеснуть будет нечем. Но многим заказчикам проще работать так, чем собирать команду. Фулстэк часто означает что человек может поднять веб-сервис целиком, качество этого решения остается за кадром.
+1
Про фулстеков — не согласен. Архитектор, key developer, или любой другой главный по технике — должен шарить и фронт, и бек. Руководить разработкой, зная только половину его стека — полный бред же. Так что если хочется расти выше мидла — надо как минимум поверхностно разбираться в обоих частях.
+2
надо как минимум поверхностно разбираться в обоих частях

Фулстек как раз таки тот кто может выполнять задачи по всему стеку, а не поверхностно разбираться. Разбираться и разрабатывать две большие разницы, между ними пропасть.

0
«разбираться» не подразумевает «может выполнять задачи», «разрабатывать»? Пускай на подзадачи по фронту и бэку уйдёт больше времени и(или) они будут решены менее эффективным по вычресурсам способом, но разве разбирающийся человек не способен решать задачи?
+1
Так-то и абсолютно любой человек может разрабатывать прямо с улицы, но ему потребуется больше времени и качество пострадает =)
А если серьезно, да сможет, но в процессе ему придется учиться осваивая инструменты и наступая на грабли нюансов и таким образом превращаясь из «разбирающегося» в разработчика. Кроме того разрабатывать, т.е. выполнять задачи уже подразумевает сроки и качество (критерии за которые платит заказчик). Безусловно четкой границы нет, но все же специалист это в большей степени тот, кто может решить задачу, а на не научится это делать.
+2
В последние годы этот «зоопарк» уже достигает абсурда — люди начинают выбирать технологии просто потому, что у них больше звездочек на GitHub.

На бэкэнде такое творится уже давно.

В прошлом году имел печальный опыт работы с одним «Agnostic»-фреймворком для аутентификации (аутентификация «искаропки» для лары не устроила), который выбрали только потому, что…

… у него было много «лайков» на гитхабе.

То, что у него отвратительная документация, под капотом — дичайший говнокод, а работа с базой неоптмизирована совершенно (чего стоит поиск по varchar(255) без индекса?) — не являлось для техдира аргументом «против».

Ведь у него «много лайков на гитхабе!». Это главный аргумент «за».

P.S. простите, было больно.
0
В целом «количество звездочек» и «от него зависят ...» является косвенной метрикой длительности поддержки. Другой обычно просто нет.
0
«Качество проекта» — интегральная характеристика и формулу качества вывести вряд ли возможно.

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

А вовсе не количество «лайков».

Ну и конечно, историю закрытия ишью. Если ишью висит с 2013 года и к нему 0 комментариев — вряд ли проект можно считать «поддерживаемым».

Банальный пример: мой проект лайкнул какой-то чувак. Я заинтересовался… выяснилось, что он лайкнул каждый мой репозиторий, более того, он лайкает все репозитории подряд. Можно ли после этого считать, что мой репозиторий стал «лучше»?
+2
Многие боятся, что как только джуниор вырастет, он уйдет.
Видел то ли на каком-то форуме, то ли на баше:
— А вы не боитесь, что мы сейчас вложимся в джуниоров, они всему научатся, а потом уйдут?
— Это не страшно. Страшно, если они ничему не научатся и останутся.
-1
JS-разработчикам надо понимать, что они должны уметь верстать.


JS-разработчикам гораздо важнее быть хорошими программистами. Со всем входящим в этот перечень.
0
Вот эту часть не понял:
… мы в какой-то момент просто уперлись в производительность. Изначально все было написано на нативном JavaScript, но с выходом очередной фичи мы поняли, что дальше развивать продукт на этом ядре мы не можем.

Как такое возможно? Может быть есть конкретные примеры? Просто инетересно. Я всегда думал, что «голый» JS всегда будет производительнее и гибче, чем любой фреймворк.
0

Любое большое жизнеспособное решение на "голом JS" это тоже фреймворк, просто свой. А гибче он и производительнее ли — зависит от обстоятельств.

0
В популярных фреймворках обычно много усилий прилагают для оптимизаций. Успех React некоторые считают заслугой единственной оптимизации — инкрементный ререндинг DOM для достижения целевого состояния.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.