Comments 47
Человек, который чуток поучится и потом «свалит» на большую зп — да, удержать нельзя, но выглядит это не совсем честно.
Нанять бы новичка, научить его и продолжать платить так, как будто он ничего не умеет — вот было бы честно и справедливо.
Одно дело — когда ты десяток лет занимался разработкой интернет-магазинов и видеть их уже не можешь. Но учитывая опыт, который ты за эти 10 лет накопил и навыки, которые получил — смело уходи куда душа лежит! И совсем другое, когда ты за какие то жалкие 3 месяца теряешь интерес к проекту. А чем ты думал, когда брался за него? Разумеется, такое случается у всех. Но это не тенденция, это случайность! А в статье это расписано чуть ли не как норма. Я абсолютно не согласен с такой интерпретацией, это лишь оправдания недостойные профессионала.
https://habrastorage.org/files/fa2/836/16e/fa283616edfa4a5d8a6ab59336965fab.jpg
А чем ты думал, когда брался за него?
А есть выбор? На собеседовании говорят об одном, а потом дают совсем другое.
Что за проект? Какая точная зарплата? Белая ли зарплата? На каких условиях стоит ожидать роста зарплаты? Есть ли перспективы для роста карьерного? Стабильные ли инвестиции в проект (не обанкротится ли фирма завтра)? Сколько уже сделано и сколько предстоит сделать? Есть ли утвержденный план работ? Определены ли точные роли в команде? Кто руководит, какой у него стаж руководства, есть ли успешные завершенные проекты? А у команды? А кто в команде, сколько их, давно ли они работают в команде, чем занимались? Кому вы непосредственно будете подчиняться и какие границы у этого подчинения? Каковы корпоративные правила в этом месте? Есть ли гарантии оплаты сверхурочных? Заинтересована ли компания в вашем обучении? Оплачивает ли она курсы/сертификаты? И т.д. думаю вы уловили мысль.
В конце-концов, это вам в этом месте и над этим проектом работать (не)определенное время. Ну так выясните на берегу во что вы собираетесь ввязаться, чтобы потом не скулить на хабре, не приходя в сознание, о том как вам скучно и что все плохо!
А толку от диктофона? Вот и остается только менять работу.
И да, 5 лет — это очень много. А 10 лет — это путь от школьника до кандидата наук.
И вот в обратную сторону так же будет по вашему предложению — компания будет обязана не увольнять в течении 5 лет за то, что работник облагодетельствовал компанию своим присутствием и своими знаниями?
Разбираться со сложными проблемами — интересно, это я как разработчик с почти девятилетним стажем говорю. Неважно откуда эти проблемы пришли — от бизнеса или от другого разработчика или от несовершенства используемого фреймворка. Скучно — заниматься рутиной, которую ты уже не раз делал. Надо отдавать такую работу не крутым разработчикам, а тем для кого это ещё не рутина.
А всё, кроме пожалуй примера с потоками, это я бы всё-таки не назвал обучением. Обучение, это когда студент не имеет представления о паттернах, о адекватном применении наследования, о том какие существую приёмы, чтобы избежать дублирования и т. п. и ему объясняется «как надо». Просто то, что описано звучит, как код ревью вне зависимости от уровня специалиста. («У тебя кнопки ОК и Отмена наоборот, в винде не так» это вообще скорее к проектированию UI, а не к разработке)
Но в случае, когда у человека реально вырос уровень, вы, как компания, получаете хорошего специалиста, которого плюс ко всему не надо вводить в проект, который в нём уже +- разбирается и может достаточно хорошо выполнять большой класс задач, так почему ему платить на порядок ниже рыночной цены? Так как он пришёл к вам студентом и якобы он вам «обязан», хотя он так же работал? Это достаточно странное обоснование.
Не занимайтесь благотворительностью, считайте деньги, чтобы сотрудник, которого вы взяли «на обучение», всё равно приносил вам прибыль. Вместо того чтобы потом писать обиженные комментарии. И да, это ваше «обучение» обычно сводится к работе над самой «плохой» работой — багфиксингом, написанием тестов, копанием в легаси коде. Словом, всем тем, чем остальные разработчики заниматься не хотят.
О как. Получается, что стороны конфликта это не бизнес и программист, а программист, который ушёл и программисты, которые остались. Внезапно.
На тех кто остался — «ну спасибо, Вася, теперь твой громадный модуль нам досталось вести!».
Bus factor? Если да, то руководство виновато, что ничего не делало.
Не занимайтесь благотворительностью, считайте деньги
Подсчет денег бизнесом, как правило, приводит просто к отказу от найма студентов.
Профессионалы стоят дороже, но толку от них на единицу капиталовложений все равно больше.
В принципе нам, программистам, в каком-то смысле это выгодно, т.к. новички создают нам конкуренцию.
Но я согласен с darthandrew, с гуманистических позиций это выглядит довольно паршиво.
Человек, который чуток поучится и потом «свалит» на большую зп — да, удержать нельзя, но выглядит это не совсем честно.
Вот этого я в IT-менеджменте совершенно не понимаю. Неужели нельзя заранее посчитать, сколько будет стоить на рынке человек, который получил у нас опыт, и заложить соответствующее повышение зарплаты в расходы сразу? Зачем заставлять человека «скакать»?
Кто-то должен уйти в минус, или начать работать эффективнее.
Человек, который чуток поучится и потом «свалит» на большую зп — да, удержать нельзя, но выглядит это не совсем честно.
Ну так платить нужно так, чтобы человека не тянуло в сторону. И это относится ко всем, будь то джуниор или сеньёр и т.д. Но в любом случае человек работает не за идею, а за деньги. И это нужно понимать.
На второй фотке: куча студентов делают лабу, но точно не работают.
На третьей фотке: два студента сидят в метро и хз что делают (не работают).
Собственно все хорошо, по статье вы как мама вашему персоналу. Подтираете, ложку в ротик кладете, еще и прожевываете. Это гуд когда есть деньги, и я посмотрю на вас когда у вас будет дедлайн\другие обязательства со штрафами.
В целом желаю вам успехов. Хорошо когда хорошо платят.
А почему вы не пометили статью, как перевод?
Поддерживать старый код — скучно
Пускай у вас идеальный продукт, пускай поддержка в нём не заключается в борьбе с устаревшей архитектурой. Вы никуда не убежите от поддержки массива крайних случаев, бизнес-ограничений, спец. подходов в сторонних АПИ и сервисах, корректировок ТЗ от клиентов, итд итп. Но это если продукт успешный. Если у продукта нет клиентов (например, только пока) — то вполне можно мечтать об идельной архитектуре в стиле «написал и забыл».
Внутренние инструменты обычно скучны
Здесь прям к каждой посылке противоположный вывод. С друзьями интересно обсуждать очередной сетап докера, а не самопальный скрипт с самопальным рендерером для полной переупаковки ассетов проекта? Ну-ну.
Это то, что на глаза попалось только.
1) Тоталитаризм в отношениях «руководство-программист». У нас такого нет, и слава Богу! С начальником всегда можно нормально пообщаться, в чём-то убедить или переубедить.
2) Общение. Да мы всем коллективом собираемся у начальника, рассказываем, «кактус-пеки» (от «как успехи?»), как закончим, начинаем мозговать и обсуждать идеи. К начальнику всегда можно зайти и рассказать о задумке, поразмыслить о её востребованности.
3) Есть простыня идей — листы бумаги, куда мы пишем идеи. Иногда поднимаем, создаём собственное ТЗ и реализуем в формате «инициативного проекта» (контора у нас — подчинённая).
В принципе, нам не бывает особо скучно. Бывает трудно, долго, сложно, но чтоб скучать? А когда скучать, если задачи разные и никогда не заканчиваются?) Каждый сам выбирает, за какую задачу возьмётся. Но все считаются с очерёдностью.
А любой крупный живой (не на искусственной вентиляции) проект рано или поздно расслаивается на набор субкомпонентов. Библиотеки, модули, классы, микросервисы — называйте как хотите.
Вы, как соучредитель, продали бы свою квартиру, чтобы выплатить зарплату своим программистам при недостатке финансирования?
Мне не удавалось, как разработчику, задерживаться на одной работе больше двух лет.
Из LinkedIn:
Bruno Marnette
Enki.com
January 2015 – Present (1 year 8 months)
Естественно, он пишет, что его «стратегия против скуки» вроде-бы «до сих пор хорошо работает». Два года-то еще не прошло…
Программировать скучно, но…