Сообщество - Лига программистов
Добавить пост
719 постов 8 298 подписчиков

Популярные теги в сообществе:

9901

АнтиЧеловечность

Вот все пишут про человечность, а у меня противоположный пример. Мой "квартиродатель" увеличил плату на 3 000 руб. Тара тара там.

P.S. тыжпрограммист вам все равно з/п платят.

6551

Появился новый тренд — наносить ущерб компам из РФ

В opensource появился новый тренд - наносить ущерб компам, с ip из рф.

авторы некоторых библиотек, например, добавили код в последних версиях,

который удаляет все файлы на компе. вот примеры:

https://github.com/medikoo/es5-ext/commit/28de285ed433b45113...

- просто выводят сообщения на экран

https://github.com/vuejs/vue-cli/issues/7054 - удаляют всё с самого корня

https://github.com/RIAEvangelist/node-ipc/issues/233 - перезатирают все

файлы

6382

5 стадий разработки софта

5 стадий разработки софта
4933

Почему трудно устроиться программистом? Взгляд со стороны руководителя

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


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


Конечно, IT-компании требовали "от миддла и выше" всегда. Так почему же, если работодателям нужны миддлы, они столь неохотно берут джунов с целью вырастить его и получить лояльного работника? Основных причин две.


Первая - это тяжело. Многие компании действительно готовы брать джунов - проблема в том, что любой руководитель в команде разработки может позволить себе иметь лишь небольшое количество джунов. Основную часть сбалансированной команды должны составлять миддлы/сеньоры. Мой личный опыт показывает, что в нормальной команде разработки не должно быть более 20% джунов, иначе темп разработки просядет, а вероятность ошибки существенно возрастёт. Печальные примеры пренебрежения этим правилом, вероятно, известны и вам - в IT не раз случалось такое, что опытные разработчики уходили из-за плохих условий (или выгонялись из-за высоких запросов), а на их место приглашались малоопытные, и через какое-то время разработка попросту вставала, качество продукта резко падало, а босс влетал в долги перед заказчиком.


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


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


Почему так? Лучше всего показать на примере. Давайте представим себя на месте руководителя, и посмотрим, что будет, если мы возьмём джуна. И здесь нас ждут проблемы: работник, не добравшийся хотя бы до грейда джун+ - это работник, который пока что бесполезен. Его полезность заключается в перспективности - в расчёте, что он прокачается, и наше время и силы окупятся. А пока что наша задача - постоянно его обучать и приглядывать за ним, чтобы помочь ему избежать ошибок. Мы тратим не только своё время (стоящее денег, между прочим), но и время разрабов-наставников, и аналитиков, и тестировщиков. Из-за этого скорость разработки снижается, дедлайны... Дедлайны остаются, ибо они есть всегда. Мы ведь в курсе, что в отрасли вечный кадровый голод?)


Итак, мы тратим много времени и сил на взращивание джуна. К счастью, период "полной бесполезности" долго это не длится, через какое-то время новичок осваивается, контроль над ним можно снижать. Разраб прокачивается до уровня джун+ не раньше, через полгода-год, и тогда-то он начинает приносить компании прибыль. Но скорость и качество хромают на обе ноги, а дедлайны продолжают поджимать. Наш джун прокачивается, скорость работы потихоньку растёт, мы проводим его через аттестации, стимулируем его на рост. Примерно так проходит ещё примерно год-полтора - вот уже скоро он станет полноценным миддлом, и можно вздохнуть спокойно. Он протягивает нам заявление на увольнение.


- Что произошло? Давай обсудим варианты! Почему ты вдруг решил уволиться?

- Получил предложение от другой компании. Там обещают более высокую ЗП и более интересную работу, а так же стек покруче вашего.


Стоит ли объяснять, что это весьма неприятно? И наверняка многие из вас скажут - "значит, надо было создать такие условия, чтобы он остался". Конечно, мы стараемся, только вот если бы всё было так просто... И ЗП тут не первая из проблем. Возвращаемся на место руководителя.


Естественно, если это действительно стоящий работник, мы предложим ему больше денег, чтобы не отставать от конкурента. Если повезёт - разраб останется. Но, скорее всего, он просто уйдёт в отказ. Он хочет уволиться, "чтобы двигаться дальше". Ему хочется в новый коллектив, попробовать новый стек, ведь он хочет развиваться, а тут он уже всё видел! Объяснить, что у него и тут ещё полно пространства для развития? Что новый стек невозможно ввести на старых проектах, а эту новую HuyakHuyakJS планировалось опробовать на следующем проекте, который сейчас в пресейле? Что у конкурента тоже есть старые проекты? Увы, разработчик уже решил, а потому наши слова он пропустит мимо ушей.


В таких случаях мы стараемся разойтись на хорошем тоне. В конце концов, разраб нам ничего не обещал и гарантий не давал. Но осадочек, конечно, остаётся. Потом мы корим себя, ищем причины - как так случилось, где мы недосмотрели? Что предпринять, чтобы такое не повторялось? Платить столько денег, чтобы разрабы на сторону даже не смотрели? Мы не Гугл. Заниматься плотнее их обучением, чтобы они чувствовали заботу? Это было бы замечательно, но откуда на это время взять? Нам бы хоть штат до конца укомплектовывать. Постоянно выливать на разрабов новые технологии, чтобы они чувствовали, что у нас всё стильно-модно-молодёжно? Мы бы рады, но чтобы новый проект начать, надо старые закрыть. Так что мы будем делать?

Правильно! Мы идём к HR открывать вакансию, где пишем новую ЗП, и описываем кандидатам наш новый запускаемый проект - теперь с новомодной HuyakHuyakJS, всё, как вы хотели, стильно-модно-молодёжно! И да, нам желательно найти миддла!


Думаю, многие руководители (и не только в IT) сталкивались с подобным. Это случай из моей практики. По различным подсчётам коллег, в течение двух лет уходят от половины до 2/3 джунов. Конечно, не все работники уходят вот так, как в истории выше. Случается, что проблема в семье, переезд. Нередко случается, что джун просто не справляется с работой и не способен держать темп развития - как я уже говорил, входной порог в IT высок, а насколько приспособлен к программированию человек, заранее сказать сложно даже по высшему образованию. Когда у меня случается, что разраб не справляется с работой, я стараюсь найти ему место в отделе попроще.


Ох, ну и простыню я уже накатал. Закругляемся!

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

Надеюсь, вам было интересно представить себя на месте работодателя. Кто знает, может, однажды вам и представлять ничего не понадобится. А пока что - желаю вам успехов в обретении работы своей мечты. Не прощаюсь ;)

Показать полностью
4880

Грамотный ход

В 2013 году американский айтишник «делегировал» свои служебные обязанности китайцу, которого «нанял» на аутсорсе и которому платил 1/5 своей зарплаты, а сам проводил рабочее время, просто бродя по интернету. Служба безопасности сумела выявить эту схему, только обратив внимание на какую-то странную VPN-активность.

4377

Если тимлид сказал...

Если тимлид сказал...
3914

Дедлайн

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


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


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


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


P.S. не умею я в концовки. Ну пока, работаем так, и мне это капец нравится. Дедлайн пугает, но уже не так сильно.

Показать полностью
3186

Верстальщик? Наверстай упущенное

Верстальщик? Наверстай упущенное
Отличная работа, все прочитано!