Comments 180
Кроме того специфика профессии в том что действительно красивые и интересные задачи попадаются крайне редко (и не тебе!). А применять системное и логическое мышление в задачах вида «выведи там окошечко, там цифру из той ячейки, а когда пользователь нажмет 'ок', значение положи вот в ту табличку» — крайне не простое занятие:-)
Я же разделил hard-skills на 2 части
- hard-skills — это фундаментальные знания и опыт
- tech-skills — это знания именно в конкретной технологии, надстройка, как вы говорите
Например, 10 лет назад я писал десктопные приложение в одной очень известной RAD и что у меня из этого осталось? Ну общие подходы и опыт работы с многопоточностью.
Если выучить веб фреймворк, то технические знания увеличатся, но если при этом не разбираться в его работе, на задумываться о безопасности, и.т.д. то `hard-skills` будут минимальными.
Если взять формулу, то получится примерно следующее
value = ( 0.5 * <знание фреймворка> + 1,0 * <знание принципов программирования> + 1,5 * <умение работать в коллективе>) / 3
Потому что у автора скилсы получается как в известном анекдоте:
— вы имеете опыт работы с американским махгони?
— я столяр и умею работать с любым деревом, включая красное дерево
— нас интересует, есть ли у вас опыт работы именно с американским махгони, весь остальной ваш опыт нас не интересует!
ВЫВОД: аффтар — гуманитрий-менеджер, а возможно даже кадровик, совсем ничего не смыслящий в IT!
А он отвечает не на заданный вопрос, а на абсолютно левый — «Я умею работать с ЛЮБЫМ фреймворком.»
Во-первых, «умею» != «есть опыт» (грань тонкая, но есть), во-вторых, меня не интересуют любые фреймворки, иначе я бы так и спросил, я спросил конкретно про фреймворк Х и жду ответа конкретно про него.
А у RomanKu по его формулировкам в статье — получается, что джуниор погода назад освоивший фреймворк «круче по hard-skills», чем тот кто с этой Джавой уже 15 лет работает, но именно с этим конкретным фреймворком не работал.
Суть в том, что незнание конкретного фреймворка не аннулирует весь прошлый опыт работы с похожими фреймворками.
Если в работе нужен конкретный фреймворк — то до опыта в других фреймворках мне нет дела, поэтому и был задан конкретный вопрос, на который следовало ответить четко и ясно, а не растекаться по древу «а я и на машинке умею, и вышивать тоже».
«а я и на машинке умею, и вышивать тоже»
Столяр ответил, что умеет работать с красным деревом, а «американский махгони» — всего лишь конкретная разновидность красного дерева.
Значит ты гуманитарий ничего в IT не смыслящий
Удивительно, как я умудрился получить почти двадцать лет стажа в ICT.
Потому что подойдёт и просто похожий по концепции фреймворк.
Повторяю еще раз — похожих по концепции не надо, надо конкретный вот этот вот, на котором у меня всё построено. Мне не нужно, чтобы человек разбирался, чем то, что он знает, отличается от того, что есть у меня — я не на обучение его беру, а на работу.
Столяр ответил, что умеет работать с красным деревом
Его не об этом спрашивали.
похожих по концепции не надо, надо конкретный вот этот вот, на котором у меня всё построено. Мне не нужно, чтобы человек разбирался, чем то, что он знает, отличается от того, что есть у меня — я не на обучение его беру, а на работу.
Похожий по концепции возможно быстро освоить — вплоть до того, что может являться возможным написать на нём что-нибудь вразумительное в первый же день.
Не обязательно иметь опыт работы на MicroSoft SQL, чтобы писать на нём зная Oracle PL/SQL, и обратное — тоже верно.
Его спросили про «американский махгони», а это — разновидность красного дерева.Столяр ответил, что умеет работать с красным деревомЕго не об этом спрашивали.
Удивительно, как я умудрился получить почти двадцать лет стажа в ICT.
«Видно льва по когтям» ©
То есть, в вашем случае не видно, что вы — разбираетесь в этом.
Похожий по концепции возможно быстро освоить
Да, только как я уже написал, мне не нужно, чтобы он осваивал, мне нужно, чтобы он писал.
Его спросили про «американский махгони»
Ну так и отвечал бы про махАгони.
мне не нужно, чтобы он осваивал, мне нужно, чтобы он писал
Если достаточно похож — писать можно в первый же день. Пример с разными версиями SQL я уже привёл.
Его спросили про «американский махгони"Ну так и отвечал бы про махАгони.
Махагони — это красное дерево, его конкретная разновидность.
p.s. безотносительно джунов, баз данных и всего такого. Я терпеть не могу людей, которые отвечают не на поставленный вопрос, а на тот, который выдумали сами себе из головы и считают, что так и надо.
Вам — чашечки или ехать? Вам нужно, чтобы он писал, или не это нужно?
Хотяяяя… он же джун. Тогда да, возможно мне просто нужен мидл. Нанимая джуна — будь готов к тому, что он будет сравнивать, познавать и разбираться. Плох тот джун, который не хочет стать сеньором :)
Но при прочих равных, даже нанимая джуна, на джуновскую позицию, я бы однозначно взял того, который ответил бы честно — «Нет, я не знаю этого фреймворка, но горю желанием разобраться», нежели того, который ответил бы «Да я все фреймворки знаю, чё там — они одинаковые же!».
Компании дерутся за адекватных обучаемых людей, прекрасно понимая что конкретный фреймворк или технология совершенно вторичны и легко осваиваются (плюс в крупных как правило все равно все свое), и грамотно инвестированные в человека пара недель-месяц на старте потом с лихвой окупятся.
А с вашей позицией я смутно представляю себе как можно кого-то вменяемого нанять.
С любой подобной особенностью — можно разобраться меньше чем за день.Если Вам до 30, у Вас голова параллельно не забита уймой других проблем (допустим, личного характера) и вообще Вы обучаемы — да. В противном случае — по разному бывает.
Увольнять людей вообще плохая политика, особенно, если они не косячили, а работали честно.
Судя по вашим рассуждениям вы JC_IIB — сами код никогда серьёзно не писали и никогда ничему не самообучались.
Если вы не врёте, что работаете в IT — то вы явно начали свою работу сразу в качестве самодура-менеджера, и продолжаете вашу ТОКСИЧНУЮ деятельность уже десяток лет.
… и за эту честность вы JC_IIB — незамедлительно накажете отказом!
Ну, если я такой «самодур-менеджер, никогда не самообучавшийся и не писавший код» (а утверждение это абсолютно несостоятельно, ни целиком, ни в какой-либо его части) — то мой отказ это не наказание, кто ж захочет с таким мной работать? :)
Повторюсь, у меня из внимания выскользнуло то, что вакансия-то джуновская. Так что никакой токсичности, сплошное недопонимание.
Справедливости ради скажу, что слово «джун» появилось в рассуждении позже, в исходном «анекдоте», из-за которого разгорелся весь сыр-бор — слова «джун» нет, вообще неясно, на какую позицию нанимается человек.
Между тем, есть замечательная тактика. Если тебе отвечают не на тот вопрос, который ты задал — повтори его слово в слово. Два, три, восемь раз. Пока человек не ответит тебе то, что хочешь знать ты, а не то, что он тебе рассказывает. Работает, рекомендую.
Из ваших слов вытекает, что вы вместо опытного разработчика предпочтёте взять джуна, если джун знает именно это фреймворк.
Слово «джун» появилось после ваших слов об отказе от опытного разработчику не знающего конкретный фреймворк, зная похожие.
Я честно несколько раз перечитал эту фразу. Может, ее как-то переформулировать? Особенно, если учесть, что слово «джун» появилось в вашем комментарии в данной ветке.
Из ваших слов вытекает, что вы вместо опытного разработчика предпочтёте взять джуна, если джун знает именно это фреймворк.
Это зависит еще от ряда факторов, не только от «джун, знающий фреймворк — миддл, фреймворк не знающий».
И уж точно случайный программист с улицы не будет в силах взять и разрулить всё «вотпрямщас».
О чем я и говорю.
А по поводу катастроф — обычно фактор автобуса же все таки стараются минимизировать. Не могу представить другой катастрофы которая бы решалась именно экстренным поиском разработчика.
Лично мне кажется что останется лишь смириться с тем что разработка станет колом на какое-то время и искать не человека который работал с в точности таким стеком, а с человеком способным въехать в ваш проект, с достаточным опытом в разных фреймворках и проектах. И уж тут точно не стоит нанимать джунов первое время.
А говорить синьор программисту — «извини чувак, меня не колышет что ты работал с похожими фреймворками, меня интересует конкретно этот» — это как-то даже проявить неуважение и таким образом сказать «извини, я совершенно не верю в то что программисты способны обучаться и въезжать в технологии, поэтому мне нужен человек который будет в точности знать именно наш стек, а то что ему надо быстро въезжать в наш проект, так это просто мои тараканы в голове договориться не могут».
Не говоря о том, что если случилась именно катастрофа, то тут уже не приходится долго и нудно перебирать, надо брать первых попавшихся адекватных.
Удивительно, как я умудрился получить почти двадцать лет стажа в ICT.
Да я вообще всегда когда комменты на хабре читаю, себя каким-то конченным дауном чувствую.
"умеет" != "имеет опыт"
В соответствии с означенным эффектом Даннинга-Крюгера столяр (джун-программист) может быть совершенно уверен, что он справится с красным деревом (последним ангуляром), вот только опыта такой работы у него не было. Только сосна, только php.
Ну кстати с сосной реально тяжко работать, у неё плотность волокон страшно неоднородная. Так что если нужно что-то сложнее грубо сколоченных конструкций, а то и резное — с твердым деревом муторнее, но проще.
В соответствии с означенным эффектом Даннинга-Крюгера столяр (джун-программист) может быть совершенно уверен, что он справится с красным деревом (последним ангуляром), вот только опыта такой работы у него не было
О чем я и говорю. Человек (джун, не джун — неважно!) на собеседовании может брякнуть что-то типа «Да че там, эти фреймворки все одинаковые!», а потом внезапно обнаружить, что они разные.
Тут будет куда более уместен ответ — «Нет, я не знаю этот фреймворк, но я готов учиться». И, в зависимости от состояния проекта, кандидат вполне может быть принят с таким ответом.
p.s. я пробовал работать с хвойной фанерой ФСФ. Та еще развлекуха, доложу я вам.
— Вы работали с Git?
— Нет, но я работал с Mercurial
— Извините, но вы нам не подходите.
Что резко выдаёт уровень вашей квалификации как собеседующего. С тем же успехом можно просто фильтры выставить, будет на 2 порядка эффективнее.
Джун, который сменил 3-4 проекта за год, для работодателя намного предпочтительней джуна, который год сидел в одиночку на одном проекте, потому что он:Может кто-нибудь из серьезных бородатых тимлидов еще отписаться? Мне всегда казалось, что прыгание по проектам характеризует человека как неусидчивого\неуживчивого\туповатого(но это не точно), в целом, человека, на которого как раз нельзя положиться.
У меня знакомый был который как то 4 места работы за год сменил. Разгильдяй редкий.
Так что джун-попрыгун скорее всего обладает какими то несовместимыми с нормальной работой дефектами.
PS Тоже касается и людей которые просидели на одном стуле 10 лет.
Тоже касается и людей которые просидели на одном стуле 10 лет.
Зависит от масштаба предприятия. В маленьком за 10 лет может не поменяться ничего.
В большом несколько раз сменились технологии и оборудование.
Возьмите сотовых операторов. 10 лет назад превалирующей технологией была 2G и звонки.
Потом пошли 3G нескольких вариантов, LTE нескольких вариантов, уже тестируется 5G. Сотовики стали магистралами с соответствующим развитием пакетного транспорта. Пошли в ход бигдата и нейросети для анализа данных. Да много чего ещё. Да даже госконторы прошли путь от небольших сетей на тонком езернете, модемной связи и серверов на Netware до современных мплс сетей на всю страну, мощных кластеров с облачными сервисами и т.п.
У меня в компании, например, за год в среднем проектов 4-5.
Приходят какие-то доработки, например, и тебя просят сделать
+ поддержка своих 2-3 проектов или параллельно тебя продают еще в аренду =)
В итоге, у меня почти за 5 лет около 20 проектов
Если я в течении одного года поработаю в Газпроме, Сбербанке, Роснефти и ВТБ24 то безопасники и HR в, например, Альфа-банке у меня обязательно спросят почему я так прыгаю. И, очень вероятно, откажут.
Но без сомнения можно выдумать (или привести) ситуацию в которой такое поведение не будет подозрительным, а напротив достойным всяческих похвал.
Понятно, что многое зависит от человека. Может он сидит на стуле где то «для виду», а сам ишачит фрилансом параллельно или перпендикулярно по совместительству.
Но в общем случае человек(ИТ) который 10 лет работает на одном месте прекрасно знает именно ту область (и как правило достаточно узкую) в которой он «живет» уже 10 лет. И начисто не знает всего остального… Более того попытка выйти из зоны комфорта и узнать что то новое причиняет ему такое неудобство, что он будет сопротивляться чему то новому до последнего.
Понятно, что если человек собрался просидеть на том же стуле еще 10 лет и уйти на пенсию то флаг ему в руки.
Мой опыт говорит что нет. Может, но нет.
Ужас не только в одних и тех же технологиях.
Ужас еще в тех вот скилах о которых пишет автор поста.
Например, человек привык(10 лет!), что он с клиентами не разговаривает.
И не умеет этого делать. И учиться не хочет. И не будет.
И все. И ты ему не объяснишь, что игра в испорченный телефон это плохо для проекта и работы может лишиться именно он. Ему пофиг. И 10 лет когда он шел по одним и тем же жизненно-рабочим шаблонам говорят ему что он прав. Но он не прав…
Все таки каждому свое, и лучше искать место где ты будешь максимально эффективен, чем выгорать на нелюбимой работе.
Человек с плохим умением себя «продавать» как правило даже донести до предполагаемого работодателя не сможет какой он классный специалист.
Человек с низкими соц навыками вряд ли сможет успешно учиться у окружающих. Может он гений конечно и сам до всего дойдет, но… вряд ли.
Почему вы думаете что асоциальный затворник будет лучше прогать чем человек с нормальными соц навыками? Откуда такая вера в заросших свитерами чудаков?
Более того, сейчас я вот еще по сути являюсь полуархитектором/полунаставником/полуменеджером над парой вчерашних стажеров, как раз потому что у меня есть как тех. скилы, так и софт скилы. Но при всем этом (и все об этом в курсе) я интроверт, решать вопросы предпочитаю больше в почте, с клиентами предпочитаю общаться как можно меньше, как и с коллегами за пределами текущей группы (да и внутри если нет обсуждения интересного мне вопроса или мнение мое по производственному вопросу в целом с общим совпадает тоже активность не проявляю). Ну, если конечно нет производственной необходимости для обратного.
Да, софт скилы у меня конечно не идеальны, но вполне достаточны, и, по моим ощущениям, вовсе выше среднего. Хотя, повторюсь, я очень ярко выраженный интроверт в плане ментального комфорта и склада характера.
Откуда у вас равенство между интровертами и асоциальными затворниками\людьми с низкими соц навыками?
А вы почему то взяли один пример и пытаетесь «умять\ужать» все мое мнение до этого одного единственного примера.
У нас с вами очень разная градация о «часто» и «редко»…
Мне вот очень не хочется в 9 из 10 случаев получить такого коллегу. Или что гораздо хуже подчиненного.
Это скорее вы (ну или я) поменяете работу и придя в компанию обнаружите этих сидельцев в виде ваших коллег\подчиненных.
Безусловный фильтр выставлять не будем. Но тут какое дело… Принцип ленивых вычислений. Если оценивать\оглядывать каждого человека на планете в предмет нужности и ценности. Не обязательно как коллегу\сотрудника\подчиненного\начальника\тимлида. Но и например как подруги жизни или собутыльника. То… не хватит всей жизни. Поэтому используется так не любимое многими (в первую очередь теми кто получает «неприятный» ярлык) «навешивание ярлыков».
Ярлыки позволяют не тратить в каждом случае месяцы и годы жизни на одного человека, а быстро по ряду признакам его забраковать. Или напротив(!) прийти к выводу что данный кандидат весьма перспективен.
Конкретно данный ярлык-фильтр вам без сомнения не нравится. Вы попадаете по нему в отрицательный «отсев». Повод задуматься. Как минимум можно поинтересоваться у знакомых HRов что они на эту тему думают.
На самом деле если он уборщик он вообще может быть немым и писать\читать не уметь. И мыть пол будет хорошо.
Программирование как и другое ИТ гораздо больше требует коммуникаций между людьми. Сложный программный продукт немыслим без совместной работы многих людей. И думать что их можно рассадить по каморкам, общаться будут менагеры (которые будем честными ничерта не понимают в тех стороне вопроса) как то… поверхностно.
Я «начинал» с инертности мышления.
И про нежелание (вплодь до совершенно агрессивной реакции) делать что то новое.
А неумение и нежелание общения с клиентами лишь пример из личной практики.
«не имеет навыков эффективного делового общения с клиентами» — поверьте, я имел ввиду отнють не такую высоту. :)
А какую высоту имели в виду? Вот прямой отказ «я с ними разговаривать не буду»? Или отказ клиентов разговаривать с ним после первого разговора?
Представьте, что клиенту навешали на уши лапши про, к примеру, круглосуточную поддержку. И ваш менеджмент, разумеется, нашел способ сэкономить.
Проще говоря не нанимать дополнительных людей, а понадеяться на «авось». Что ничего критичного ночью не произойдет, а если произойдет то… как нибудь выкрутимся. :)
Ночью происходит серьезная проблема. Система мониторинга о ней сообщает..., но все спят:)
Утром же ваш подчиненный (он прекрасно знает про «круглосуточную поддержку» и прекрасно знает что ее нет!) пока вы отходили в туалет\за булочкой\еще куда то в ответ на требование начальства:
— Срочно ответь клиенту!
— Ну тимлида ж нет… он с клиентом разговаривает, а я нет!
— Ответь! Тим лид придет свое получит!
Пишет хамоватое письмо примерно следующего смысла:
«Мониторинг у нас есть, но проблема произошла ночью и все спали. Поэтому починили только в 9-15 когда начался рабочий день.»
Из чего заказчик понимает что с круглосуточной поддержкой его кинули:-) Кинули на деньги. А в копии стоял серьезный менеджмент заказчика который эти деньги и выделял…
Объяснять этому человечку который «не разговаривает с клиентами», что в результате его письма проект могут закрыть и он сам же вылетит на улицу бесполезно. Для него все равно виноват будет начальник который «заставил ответить» и ты потому что «вот сам бы и отвечал, а не шлялся непойми где».
По хамоватости тут у каждого свои понятия. Кто то и деловую переписку считает нормальным открывать «здароф, мужики!»
Как у вас интересно получается. Менеджеры обманули клиента, а виноват программист. Да еще и оказывается он из-за этого не является "хорошим ИТшником". При этом не он принимал решение об обмане и не он принимал решение об ответе. Почему, собственно, начальство не может ответить клиенту, раз уж он такой важный? Почему нельзя подождать того, кто обычно "с клиентом разговаривает"? Всю ночь значит ждали, а тут вдруг несколько минут что-то решат. Почему нельзя явно сказать "Напиши то-то и то-то", раз уж всем остальным лень разгребать последствия своих интриг?
Еще один повод отказываться от общения с клиентами — фиг его знает что им менеджеры наплели.
Если он меняет компании и проекты потому, что не может нормально работать, то это один вопрос, но если ему дали 1-2 мелких проекта (например он + более опытный напарник) и он их выполнил, потом до полугода его подсадили на крупный и долгий проект для помощи и роста + ему подкинули внутреннюю штуку сделать, то тут уже совершенно другой разговор идет.
Проектов != рабочих мест. 3 проекта за год = 4 месяца на проект.
Т.е. если в компании, где работает джун большая текучка проектов, он неусидчивый\неуживчивый\туповатый?
-исправил опечатку в окне «О программе».
-добавил выбор «г-н»\«г-жа» на экране регистрации
-добавил окно с надписью «Спасибо за визит» после нажатия на «крестик»
И в резюме можно писать еще три успешных проекта:)
Хотя не могу не признать что за исключением чего-то типа Proof of concept проектов всего в 4 месяца активной разработки не припомню
Крутые сеньоры подрядчика полгода обсуждают детали проекта со спецами заказчика.
А когда все наконец согласовано вместо сеньоров приходят джуны которые не умеют ничего.
Денег за них заказчик платит как за сеньоров, конечно же.
Я знаю изрядно людей, которым тупо неинтересно быть управленцами, им это не надо, они сидят и пишут кот.
Более того, если человек в 50 лет продолжает развиваться — он скорее всего в принципе лучше любой молодёжи. Вижу такие примеры.
Ну и есть проекты, где «тупое легаси, надо просто поддерживать» — и человек, который уже спокойно строит дачу и имеет нужный скиллсет, подойдёт туда значительно лучше молодого парня, которому всё хочется переписать.
К сожалению, далеко не все работодатели это понимают.
человек, который уже спокойно строит дачу и имеет нужный скиллсет, подойдёт туда значительно лучше молодого парня, которому всё хочется переписать.
Поддержу, скиллованный консерватор на этой позиции будет куда полезнее хипстера, потрясающего очередной bleeding egde hype-driven технологией. Потому, что если все работает, работает как надо и всех всё устраивает — не трогай.
И не известно, что лучше, остаться технарём или стать управленцем нижнего звена, которому постоянно выносят мозг, постоянный стресс.
Дорасти до топов не получится с большой вероятность.
«У генералов свои дети есть» (С)
Субъективно отличаю первых от вторых по отношению к людям, деньгам и технике(включая софт): для одних объект управления деньги и люди, а техника — ресурсы, для других наоборот. Первые в целом метят на позиции CEO/CFO, вторые на архитекторов/CTO.
Интроверту искать проекты с минимальной коммуникацией и там, где софтскилы не так важны.
Я отдавал себе отчет о последствиях этой фразы. Тем более что я сам "из этих", пытавшийся работать менеджером, с эпик фейлом в конце. Пока решил, что могу обучать молодняк, так как хорошо умею обьяснять то, что понимаю сам. Но как представлю вот эти все бесконечные митинги и договоры, прям знобит.
Другое дело, что в основом о soft skills приходится слышать как раз от экстравертов, потому что это их «тема». Вот и получается, что интраверты пытаются натянуть шкуру экстравертов в плане soft skills на себя и идут за мылом и веревкой.
Кажется ты путаешь социофоба и социопата, последний вообще может вполне неплохие soft skills иметь, просто ему будет плевать на то, что случится с людьми вокруг него.
Но вообще же разница между интровертами и экстравертами прежде всего в том, что вторые заряжаются при общении, а первые разряжаются и поэтому они стараются его дозировать, чтобы не тратить силы по пусту.
Но вообще же разница между интровертами и экстравертами прежде всего в том, что вторые заряжаются при общении, а первые разряжаютсяДля себя нашел еще одну аналогию: люди — это усилители. Не даром ведь существует выражение «на одной волне с кем-то». Экстраверты — широкополосные усилители. У них большой рабочий диапазон частот, т.е. им легче с ходу найти общий язык со многими. Интроверты же — узкополосные усилители, они резонируют с определенными категориями людей. Но ширина полосы обратно пропорциональна возможному коэффициенту усиления. Интроверты способны на кратно большую интенсивность в общении на своих рабочих частотах (попробуйте остановить интроверта, который рассказывает Вам что-то, что ему действительно интересно). Т.е. нужно учиться перестраиваться в некоторых границах и искать окружения единомышленников. И отдыхать, восстанавливаться, конечно.
2) Сдвинуть немного представления людей в нужную мне сторону.
3) Сформировать мнение о себе у потенциально полезного мне сообщества.
4) Получить информацию о мнениях и поведении людей со схожими интересами для уточнения своего мнения. (пересекается частично с пунктом 1)
Самое главное что тут иницииатором общения всегда выступаю я и только когда мне надо. До тех пор пока не проверю наличие уведомлений вполне отдыхаю.
Все таки люди существа стайные, соответственно приходится часто мимикрировать чтобы занять в стае нормальное место, получить нужные плюшки, эффективно выполнять работу.
Очень часто люди говоря: "ох, да я интроверт" имеют в виду что им не нравится оказываться в новой и некомфортно социальной ситуации и что им лень интересоваться другими людьми. Для успешной карьеры в управлении людьми и предприятиями нужен интеллект, желание учиться и немного эмпатии. Да и само это разделение больше связано с ролью индивидуума в конкретном коллективе и меняется со временем и с обстоятельствами. После 30 вообще разница несущественна, поколение взрослых диктуется требованиями социума.
Я даже скажу что в корпорациях (по крайней мере инженерно- промышленных) на верхних этажах вы не встретите ярких экстравертов, зато ярко выраженных интровертов (или ведущих себя так) сколько угодно
30-летний старик
молодому 33—летнему тимлиду
занятная же у вас классификация… :)
• лет через 5 он уже разницу не так сильно ощущает, да и разрыв в возрасте и опыте уже не такой большой.
• еще через 5 лет он смотрит на молодое поколение и начинает чувствовать себя старым
Все относительно…
По крайней мере у меня были именно такие мысли во всех IT компаниях города, где мне довелось поработать.
Или Коля забил на умные статьи и стал точиться в наиболее сложных и дорогих для рынка навыках, например, ML, DL, распределенные вычисления какие, highload с какими-нибудь >1M rps, разработка бд и так далее.
Рынок его сузился, но востребованность после очередного периода джунства резко выросла.
Коля ушел в суровую специализацию, но одновременно расширил свои навыки и скорее всего по дороге освоил еще несколько ЯП.
И Коля стал настоящим senior с хорошей ставкой и полным непониманием, зачем ему переходить в лиды, PM и так далее.
Это если он технологию угадал, а мог ведь уйти в какой-нить семантиквеб и все...
Сейчас за 5-10 лет IT технологии меняются настолько, что востребованность на рынке может упасть в сотни раз. Потреряет Коля работу? Если закрепится за продукт, который будет поддерживать ещё лет 10, то нет, но автор об этом и так писал несколько раз.
Современный IT ещё и движется в сторону упрощения технологий в плане доступности. Если лет 12 назад я пробовал реализовывать перцептроны на C++, то сейчас практически любой облачный сервис предоставляет ML подсервисы, а по Интернету гуляют курсы по AI за 21 день. Я не говорю, что любой сможет ML сейчас, но в 90% проектов д.т.н. по AI/ML/Dl становятся не нужны, а в крупных R&D отделах нужны специалисты топового уровня всегда.
Особенно если уйти в RnD проекты.
ML — реализации ничто, понимание, что делаешь — все. ML — это не столько про код писать, сколько задачу исследовать. Базовых подходов к типовым задачам десятки, у каждой реализации десятки параметров, у каждой задачи бесконечно много возможных фич. Верно выбрать, верно сделать прототип, верно внедрить в инфраструктуру — это мастерство.
Про 90% — все так. Я и говорил, что рынок доя Коли сузится, но его качество и доход повысятся. И частенько Коля будет не понимать, зачем люди рвутся в лиды и убивают себя, как способных инженеров и исследователей. Особенно это ему будет трудно понять с оплатой, скажем, 150$/час. В общем-то и коинов сможеь купить…
5-10 лет вы говорите. Ну устареет определенная технология, но я ведь говорю не о технологии, а о специализации. То есть об умении круто решать определенный класс задач. DL, ML, поиск, распределённые системы. Отдельные алгоритмы уйдут. Область останется.
У нас в заказной разработке по городу ЗП менеджеров колеблется в довольно узком диапазоне. ЗП разработчиков же начинается с очень низкой и начинает очень быстро расти, сеньоры уже легко перегоняют менеджеров по ЗП. Сильный технический специалист практически не имеет потолка по ЗП, главное тут — продолжать учиться и совершенствоваться, ни понимать, что для получения очень больших сумм надо очень много работать (в плане движения) и рассматривать возможность смены города и даже страны. Пройдясь по своему списку друзей в соцсетях, могу найти несколько подобных вариантов.
Мой основной посыл был в другом: переход из инженера в управленца — это не единственный путь развития. Можно уйти в узкую специализацию, можно в RnD, можно в преподавание. При наличии soft skills любой из этих путей принесет достойный заработок. Но некоторые из них обладают уникальными качествами, как возможность исследовать ранее не решенные задачи, учить новые поколения, достигать тонкого мастерства в узном деле. Если Коле хочется чего-то из этого, то вряд ли стоит идти по пути управленца.
Да и про деньги тоже. Мой опыт говорит, что хороший спец ищет работу максимум месяц, выбирая наиболее клевую, а вот управленец может и на полгода и более застрять без достойной работы.
Я специально в заключении выделил несколько путей дальнейшего развития разработчика: программирование, обучение, руководство. А так же специально акцентировал внимание на то, что если не хочется быть управленцем, то и не стоит это делать даже не смотря на то, что тебя к этому принуждают. Если же нравится заниматься менеджментом, то привел одну из книг, которая помогает двигаться в этом направлении.
Хорошая работа с конфликтами. Действительно хорошая. Начали с конфликта, сказав про биткоины, но последовательно сместили внимание с острых вопросов на те, где возможно единое мнение, к которому и подвели.
С такой отличной работой грех не согласиться!
Конечно, я согласен. Как и с тем, что в крипту недальновидно вкладываться.
ЗП менеджеров колеблется в довольно узком диапазоне
Менеджер, работающий за ЗП — это днище жизни. Менеджер должен работать за ДОХОД. Или как минимум, учиться этому у старших, тех, кто с экрана телевизора не сходит.
Менджер — это упраяляющий, очень разные слои. Если он управляющий лавки — то да, доход ему близок (из-за малого размера предприятия), если предприятие большое, то вклад каждого отдельного минимален и ставить зависимость от прибыли — так себе идея (усложнение, не дающее профита). Так что ваш совет для управляющих лавки, не все хотят такими быть (даже менеджеры).
А вот личный опыт и основанные на нем советы — это полезно, для тех, кому этого достаточно.
Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.
Я бы с радостью построил математическую модель и проверил бы ее на основе каких-либо исследований, но дать объективную оценку скилам практически невозможно. Даже сам поиск способа оценки может вылиться в нехилое исследование. Даже технические скилы, например, тесты на апворке не всегда отражают объективной ситуации и могу как минимум быть набиты с N попытки.
Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
Думаю, в медицине да и во многих отраслях примерно так же. По прошествии определенного этапа за тобой заботливо закрывают двери. В этом плане программерская среда, конечно, более демократичная.
Приведу пример, который меня лично периодически беспокоит. На этапе становления на фронте принял решение изучать angularjs. Со временем я сделал ставку на angular 2 вместо react. С течением времени я стал замечать новые вакансии вида react и vue, и реже angular 2(6+), что обеспокоило меня. Изменение стека разработки влечет уменьшения твоей продуктивности. К примеру в angular у тебя уже есть архитектурный подход и т.п. Это влечет за собой изменения твоей вакансии (скажем синьера на мидла) и я бы описал это так ( бьет по самоооценке ) — автор назвал это Кризис возраста. Встает вопрос ( это уже к программистом со стажем ) при изменении стека технологий на сколько релевантен твой опыт, который можно перенять с прошлых технологий. К примеру на вряд ли занимая должность TeamLead в extjs или backbone ты станешь тимлидом в angular, react, vue и т.п. С удовольствием бы услышал мнение на этот счет)
В целом можно получить хороший оффер, подразумевающий даже смену языка (не диалектов) и целевой ОС, если есть хорошие знания предметной области и какие-то свидетельства, что ты умеешь решать бизнес-задачи с помощью программирования на разных языках, а не просто программировать на конкретном.
Прочитав статью, порадовало мышление автора.
А меня — не порадовало.
Потому что у него hard-skill жёстко прибит гвоздями к конкретному фреймворку, без какого-либо учёта предыдущего опыта и лёгкости изучить новое на основании знаний похожего.
Потому что у него hard-skill жёстко прибит гвоздями к конкретному фреймворку
Предлагаю перечитать статью еще раз и комментарий к ней, а потом уже «нерадоваться»
Автор специально ввел понятие tech-skills для того, чтобы убрать из hard-skills фреймворки, библиотеки и прочее, а оставить именно опыт и фундаментальные знания.
с 2006 по 2016 годы основным ЯП был PHP (c 2008 фуллтайм)+jQuery+фреймворки Symfony, Laravel, Bitrix, YII. Но при этом писал плагины для jQuery, на Java, C++ и прочем. Были проекты с использованием Perl, были и корп. порталы и всякий e-commerce. В качестве тимлида продавал проекты, участвовал в разработке ТЗ, управлял командой разработчиков и проводил сдачу проекта заказчику.
В 2015 я и мои товарищи слышали фразу: ваш стек технологий устарел, это слышать было довольно тяжело.
В 2016 году с переходом в студию освоил React + Angular 1.5/2+ + NodeJS — скажу честно, что временами было очень тяжело. Но стал Mean фуллстеком.
Что помогало?
- Глубокое знание веба (в свое время занимался разбором пакетов в wireshark)
- Опыт работы с БД
- Опыт работы и администрирования Linux. (сейчас приходится DevOpsить при необходимости)
- Опыт разработки многопоточных приложений, межпроцессного взаимодействия, тестирования безопасности, нагрузочного тестирования, разработки высоконагруженных систем.
- Опыт работы с кучей языков программирования (больше половины я не указывал в этом комментарии)
- Опыт работы в качестве тимлида (уделять внимание мелочам, развивать младших товарищей, общаться с клиентом, не давать необдуманных обещаний, проактивность и клиентоориентированность)
- Привычка работать в режиме постоянного стресса
- Привычка разбираться в том, что ты делаешь, а не скакать по вершкам
Возможно, что-то еще.
Могу сказать, что смена стека технологий прошла тяжело, однако, относительно быстро, за 1.5+ года nodeJS знаю больше, чем среднестатистический молодой nodeJS разработчик, который пишет 3 года в резюме (переходы были без понижения ЗП)
На текущий момент именно программированием занимаюсь только при необходимости (когда надо, а людей нет), но основная проблема с кодированием — постоянные задачи, которые надо решать, делегировать, контролировать.
Хотя я вроде читал, что объективно лет после 12 только спад.
Мозг брал отпуск на время пубертата =)
то с возрастом когнитивные способности сильно падают (когда-то наступит момент, после которого ты уже не сможешь каждый день по новому фреймворку разбирать). И к этому имеет смысл готовиться заранее
Напомните средний возраст Нобелевских лауреатов? И вообще большинства известных ученых с мировым именем? Если что ссылка. Дело даже не в том, что нужно время, чтобы оценили заслуги, большинство 70-90 летних профессоров в разы лучше разбираются в новейших исследованиях по своей области, чем аспиранты.
Медики говорят, что если постоянно заниматься мысленной деятельностью, когнитивные способности не снижаются, более того ВОЗ считает что до 44 лет это возраст молодости, когда еще практически нет возрастных изменений (ну если вы не проф. спортсмен).
Поэтому нет, это не ваши когнитивные способности снизились, это ваш мозг лентяйничает (он это любит, да).
Хорошая статья, но опять типичная ошибка, когда путают сеньора и лида:
была должность аналогичная Синьору, называлась она Ведущий программист — такой специалист не просто много знает, но и еще ведет проекты или коллектив.
Раньше были старший и ведущий инженеры(-программисты).
Сейчас это называется Senior и Lead.
Нужно понимать, что это Lead ведет за собой, а Senior это такой заслуженный товарищ, которые много знает и умеет, решает сложные задачи, но работает в основном в одиночку.
А если и ведет/делится опытом, то больше на неформальном уровне.
Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),
Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.
Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),
Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.
Автор решил не акцентировать на этом внимание в данной статье по той причнине, что если разобраться, то Team/Teach не выбивается из общей концепции, а еще и техлидов не хотелось бы обижать.
Но если появился такой вопрос, то могу на него ответить исходя из опыта и наблюдения как за одними, так и за другими.
TeamLead — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин
- Он ближе к разработчикам и может их адекватно оценивать
- Разработчики к нему относятся лучше, чем к проектному менеджеру
- Можно убрать из проекта или снизить роль проектного менеджера (а он не приносит прямой доход)
- Он может общаться с клиентом с точки зрения бизнесса, а не технологий.
- Совещает в себе роли TechLead и PM
TechLead — техническй специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли. почему конкретный человек именно TechLead, а не TeamLead:
- Он может быть технически очень сильным и отвлекать его не стоит, например, может участвовать в большем количестве проектов
- Он интроверт или мизантроп, ему очень сложно общаться с людьми, а им с ним
- Он очень сильно любит программировать, а управленческие задачи ему не интересны
- PM не хочет делиться с ним обязанностями
- В компании нет необходимости в TeamLead и больше требуется технические специалисты
Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца и об этом было упоминание в заключении, однако, при отсутствии очень сложных проектов он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за универсальности.
Вот прям "не хочет и не может"?
Народ, сколько здесь бывших лидов, руководителей всех мастей, которые на каком-то этапе не возвращался чисто в программирование?
- Наемным программистам больше платят, чем наемным управленцам
- Он в какой-то момент понял, что «не хочет и не может» и решает вернуться в программирование
- Упал спрос на менеджеров, а программисты нужны
Нежелание может быть не так выражено, либо они еще не решили, что ему будет лучше, но они же уходят в программисты со словами «не мое это»?
Вам видимо трудно представить вариант мотивации "могу проекты и управление, но хочу в спокойное программирование". И деньги, бывает, не главная мотивация.
Либо я плохо выразился, либо вы не так поняли. Я потексту указывал именно не хочет ИЛИ не может, а тут была контраста предыдущего комментатора.
Я могу представить себе такую ситуацию (и даже знаю примеры), когда хорошо получается управлять, но это отнимает слишком много сил, времени и т.д. + если ты ПМ, а твой заказчик в другом часовом поясе, то приходится подстраиваться под него, а переработки не оплачиваются.
Не являясь ПМом могу сказать, что это самая неблагодарная работа — на него давит и команда и клиент и работодатель. И плох тот менеджер, котррый это давление просто передает дальше поцепочке.
Ну и общение с бизнесом с точки зрения бизнес-задач позиция техлида ничуть не отменяет, а скорее предполагает большее, чем у тимлида и пма (если все трое есть в команде): чтобы выбрать правильный стек, правильную архитектуру нужно досконально понять бизнес-задачу. Собственно прямая задача техлида — выбирать или предлагать на выбор технические решения бизнес-задач.
Исходный комментарий связан с тем, что в некоторых окмпаниях и в понимании некоторых управленцев, сеньору приписываются навыки и полномочия лида.
Можно делализировать тот момент, что в сеньоры попадают как те, кто просто «заслуженный», и вроде на мидл-позицию его не поставишь, но сам разработчик и не хочет развиваться особо — так и те, кто мог бы стать архитектором и тех лидом, но, как вы заметили, что «архитекторы и тех лиды не нужны», поэтому они тоже идут в сеньоры, если не хотят идти в тим лиды и тем более в управленцы.
Кривые развития программиста и немного об эффекте Даннинга — Крюгера