Существует два основных пути становления топ-менеджмента в IT-компаниях:
- Менеджерский — когда менеджер проекта начинает управлять другими менеджерами.
- Технарский — когда разработчик начинает управлять другими разработчиками и количество управляемого им персонала увеличивается.
Первый путь является более естественным, поскольку, подразумевает развитие основных качеств менеджера по мере его роста. По сути менеджер остается менеджером, только становится специалистом более высокого звена.
Второй путь является более долгим и не гарантирует успеха, так как является противоречащим сути интроверта-программиста. Однако, на этом пути я бы хотел заострить внимание и поделиться опытом и знаниями.
Внимание, спойлер.
- Все имена — вымышленные
- Повествование относится в большей степени к заказной разработке
- Скилы, а в особенности софт скилы, сложно оценить формально, все графики в этой статье являются условными и отражают мое личное мнение
Начало пути программиста
Итак, мы в самом начале пути программиста.
Знакомьтесь: Николай (имя изменено). Николай — молодой программист, он хорошо учится в универе и уже пробовал писать простенькие сайты. Он устроился в студию на должность джуна-фронтендера, его посадили на проект, который уже пишется два года с использованием современного фреймворка Angular версии 1.5. Мальчик Коля не работал с ним, но он увидел знакомый знак доллара, а он уже успел написать пару плагинов для jQuery. Этот факт ободрил Николая, но потом старшие товарищи рассказали ему, что это — совсем не jQuery, и, вообще, тут надо директиву написать, а вот тут два фильтра надо сделать. Николай подавлен, но твердо намерен влиться в этот проект.
И вот уже пролетел год, Николай мастерски пишет директивы и не проходит и дня без нового модуля. Коля на коне, оптимизма ему прибавляет тот факт, что полгода назад к нему на проект подсадили молодого джуна, а тот даже не знает, что такое директива. Щенок! Николай подружился со старшими товарищами, и только 30-летний старик в углу вечно чем-то недоволен.
Собственно, на графиках мы видим технические навыки для проекта и все скилы Николая, что у него есть. Поскольку это его первый проект, то по факту это все, что знает Николай. Через некоторое время он идет к начальству и просит два мешка денег — ведь он мастерски создаёт директивы на проекте, и вообще, он посчитал, что в два раза больше оставляет комментариев в MR, чем тот 30-летний старик. Очевидно, что он — лучше своего тимлида. На это получает вполне резонный отказ и начинает искать новую работу, возможно задумывается о переходе на другой проект или в другую команду. В любом случае он сталкивается с ситуацией, когда только что полученные знания становятся уже неактуальными и ему надо учиться дальше.
Это — первый кризис Николая «Эффект первого проекта».
На новом месте Николаю дают проект на Ангуляре 5, ну он же мастерски пишет директивы! Но там он видит какую-то дичь! Какой ещё TypeScript? Какой RxJs и потоки? Старшие товарищи смеются над ним, а 30-летний старик кидает недобрые взгляды. Я видел огромное количество таких звёздочек и очень много звездопада, когда разработчик понимал, что оказывается-то он ничего ещё не знает! И чем раньше это произойдет, тем лучше. Это называется Эффектом Даннинга — Крюгера — метакогнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации.
Джун, который сменил 3-4 проекта за год, для работодателя намного предпочтительней джуна, который год сидел в одиночку на одном проекте, потому что он:- Объективно оценивает свои знания и навыки
- Постоянно развивается
- Больше общается в коллективе
- Больше понимает цену ошибки, потому что он видел больше дедлайнов и релизов
Коллегам, которые оказались на этом этапе, хочется пожелать следующего:
- Не унывать при неудачах
- Постоянно учиться и осваивать новые библиотеки и технологии
- Не звездиться
Junior > Middle > Senior
Ну вот прошло еще пару лет и что же мы видим?
Николай уже освоил несколько фреймворков и понял, что фреймворки — это только инструмент для решения конкретных задач. Он смирился с тем, что знает не все, но при этом старается все время развиваться. В какой-то момент он подходит к молодому 33—летнему тимлиду и говорит: слушай, Петя (имя изменено), вон к нам пришло несколько джунов, они ничего не знают и медленно делают задачи на проекте. Давай я им проведу несколько лекций или мастер-классов для того, чтобы они быстрее влились в нашу работу. И именно в этот момент Николай переходит на следующий уровень.Сейчас существует разделение на Junior, Middle, Senior. Мидл думает, что для того чтобы стать Синьором, ему надо освоить новый язык программирования и подтянуть матчасть. Это не совсем так. На заре отечественной разработки была должность аналогичная Синьору, называлась она Ведущий программист — такой специалист не просто много знает, но и еще ведет проекты или коллектив. Без соответствующих софт скиллз Синьором не стать.
Николай научился находить подходы ко всем членам команды, он постоянно развивается и развивает остальных. Он повидал уже «звездунов первого проекта», но ему гораздо комфортнее работать с такими же профессионалами, как и он сам. Ведь они понимают, что успех проекта — это успех каждого, а прокол одного члена команды в конечном счете сказывается на всех его участниках.
На этом этапе возможно два пути: быть простым исполнителем, не напрягаться и решать поставленные задачи; второй — развиваться в направлении ведущего программиста, брать на себя ответственность и инициативу.
На этом этапе развития программиста команда и руководство ценят такие его качества:
- Ответственность
- Надежность
- Коммуникабельность
- Проактивность
Куда стоит развиваться?
- Углубленное понимание технологий, которые он использует
- Расширение кругозора
- Брать на себя ответственность за проекты и людей
Причем, скилы из последнего пункта надо обязательно прокачивать, если он хочет развиваться по кривой до руководителя. Если же ему это не интересно, то можно сконцентрироваться именно на умениях технического специалиста.
Кризис технологии
В какой-то момент Николай с ужасом осознает, что уже никто не пишет на JS, а большинство его знаний никому не нужны. Вот так наступает кризис технологии. Я застал такой кризис с десктоп-приложениями. Чуть позже просто верстальщики стали никому не нужны — везде стали требоваться фронтендеры. Потом PHP стал резко не моден, и на рынке стали нужны JS-разработчики.
Тут есть три выхода:
- Переучиваться под новый стек
- Становиться лучше в старом и хвататься за последние заказы. Тот же Delphi все ещё востребован в узких кругах с огромным количеством legacy кода
- Уходить в менеджмент при наличии соответствующих навыков
Сильные специалисты нужны будут всегда, но, при снижении спроса на определенную технологию, увеличивается конкуренция между соискателями. Заказная разработка страдает в этой степени больше, нежели продуктовая. Освоившись в крупной продуктовой компании, разработчик может не бояться возраста или устаревания его стека технологий — он будет востребован, пока живет продукт. По моей статистике, средний возраст разработчиков в продуктовых компаниях выше, нежели в студиях.
TeamLead. Кризис возраста
Ну вот, Николай сменил стек технологий, и вроде бы все хорошо, но мы видим, что новые навыки даются все медленнее, а подрастающее поколение схватывает все быстрее.
Вот тут наступает последний кризис — кризис возраста.
Николай стал одним из тех тимлидов, на которых он смотрел несколько лет назад, как на стариков, вечно ворчащих и недовольных, но вот он стал писать меньше.
Можно подумать, что если ты пишешь меньше кода, то ты медленней развиваешься, а ребята, которые его пишут больше — соответственно и развиваются быстрее, и они скоро тебя догонят. Я встречал и такую фобию у молодых специалистов.
Какие тут могут быть варианты:
- Если ты работаешь в продуктовой компании, то, наверное, это для тебя не так критично, и можно оставить все как есть
- Уйти в обучение, например, стать консультантом, архитектором и т.д.
- Таки уйти в менеджмент
Перейдем к кривым
Удовлетворенность. Она не может быть всегда на высоте, качественные проекты попадаются не всегда, а идеальную команду сложно подобрать и воспитать.
Я уверен, что, несмотря на падение удовлетворенности, надо всегда оставаться человеком. Я говорю о том, что если горят сроки на проекте и все бегают в мыле, то лишняя нервозность делу не поможет. Команде будет намного комфортней работать с людьми, которые не подведут в критические моменты.
Технические скилы относительно быстро приобретаются и ещё быстрее забываются и устаревают, если посмотреть со стороны.
Получается, что программист имеет свой пик развития, а потом начинает «стареть», и в какой-то момент ему пора уходить на пенсию?
И да и нет. На самом деле, вместо одного графика можно нарисовать 3 (опять же IMHO, как и значения).
- tech skills — это знания именно в технологии, языке программирования, фреймворке. Вы помните, что я ранее писал о том, что тимлид начинает меньше писать код и больше управлять? Эти скилы имеют свой пик именно в момент наибольшей востребованности специалиста в роли кодера.
- hard skills — это совокупность знаний и опыта разработчика, со временем рост их снижается по той причине, что старые знания уже устаревают и становятся не востребованы, но остается полезен из них именно сухой остаток.
- soft skills — это именно те личностные качества, которые нельзя посчитать, но которые надо развивать. Это качества, которые важны всегда, но в разной степени даны всем от рождения.
Но давайте добавим еще один график
value = (0,5*tech + 1*hard + 1,5*soft)/3
В третий раз повторюсь, что это лично моя формула, а коэффициенты я вывел за более чем 10 лет профессиональной деятельности в области разработки.
Зеленый график отражает совокупность всех качеств специалиста, и это является его итоговой ценностью.
Почему технические скиллы ценятся в три раза меньше, чем софт скилз? Вспомните фразу «как специалист он хороший, а как человек — не очень» и тех, к кому она применялась. Руководитель более охотно выберет соискателя, на которого всегда можно положиться, чем соискателя, который пригоден только для одного единственного проекта, и то над ним нужен глаз да глаз. Даже джуну легче работать и быстрее развиваться в команде, где ему помогут и направят, а не будут стремиться подставить при первом удобном случае.
Поэтому же HR-ы в компаниях проводят отсев кандидатов в том числе по софт скилам еще до проведения технического собеседования. Токсичный сотрудник может принести больше вреда компании, нежели технически слабый. Да и если технически слабый сотрудник принес вред, то это скорее вина его руководителя. Есть золотое правило: давай задачи по силам, а если хочешь, чтобы человек подрос, то немного сложнее (именно немного, а не в виде неподъемной ноши).
2 варианта развития программиста
Я описывал вариант, когда разработчик двигается по следующему пути:
Junior > Middle > Senior > TeamLead? > Project manager? > Head Of * > Chief * Officer
Но что делать если это не получается или не надо?
Та же самая формула работает и в случае, если вы хотите развивать свои софт скиллз и становиться менеджером: можно развивать технические скиллы и быть востребованным специалистом без необходимости двигаться в сторону менеджмента. Но тут надо понимать, что технические скилы имеют свойство устаревания: сегодня ты отличный программист на Фортране, а завтра ты уже никому не нужен.
TechLead vs TeamLead
В связи с укором со стороны читателей за то, что эта тема была не раскрыта в статье (соглашусь, что стоило бы добавить материал), то я дополню отличиями двух видов лидов.
TeamLead (вариант 1 из предыдущей главы) — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин:
- Он ближе к разработчикам и может их адекватно оценивать
- Разработчики к нему относятся лучше, чем к проектному менеджеру
- Можно убрать из проекта или снизить участие проектного менеджера (а он не приносит прямого дохода)
- Он может общаться с клиентом с точки зрения бизнеса, а не технологий.
- Совмещает в себе роли TechLead и PM
TechLead (вариант 2 из предыдущей главы) — технический специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли.
Почему конкретный человек — именно TechLead, а не TeamLead:
- Он может быть технически очень сильным, и отвлекать его не стоит, например, может участвовать в большем количестве проектов
- Он — интроверт или мизантроп, ему очень сложно общаться с людьми, а им — с ним
- Он очень сильно любит программировать, и управленческие задачи ему не интересны
- PM не хочет делиться с ним обязанностями
- В компании нет необходимости в TeamLead, и больше требуются технические специалисты
Грамотный руководитель, при наличии необходимости как в тимлидах, так и техлидах, выберет правильную должность конкретному сотруднику (ну или постарается), тем самым сделав взаимовыгодное сотрудничество более качественным для обеих сторон.
Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца, и об этом будет сказано дальше, однако при отсутствии очень сложных проектов, он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за его универсальности.
Заключение
Софт скилы очень важны для специалиста, они позволяют ему быть востребованным в те моменты, когда его технологический уровень не очень высок, например, при переходе между проектами, компаниями или технологиями. При прочих равных, руководитель отдаст предпочтение специалисту с более развитыми софт скилами.
Переход от разработчика в менеджеры (под менеджером я подразумеваю скорее не продуктового менеджера, а руководителя, тот же тимлид сочетает в себе менеджерские и технические роли) стоит делать, если софт скилы превосходят технические, и если инициатива исходит от самого разработчика.
Плохие варианты, которые не дадут хороших результатов:
- Я хочу стать ПМом, потому что люблю власть, да и они ничего не делают
- Я хочу стать ПМом, потому что я не востребован в качестве разработчика, а есть вакансия ПМа
- Я не хочу быть ПМом, но руководство заставляет
- Я мастерски пишу директивы и готов уже руководить командой разработчиков
Если вам не нравится или не получается менеджерить, но вас заставляет руководитель, то лучше сразу ему об этом сказать, а не пересиливать себя, а потом в какой-то момент сорваться и «улететь кодить на Бали». Помните: если вам нравится писать код, а не руководить, то и пишите его.
Если же вы не можете/не хотите уйти в менеджеры, но при этом просто программировать вам уже не интересно, то можно рассмотреть вариант перехода в коучи: продавать свои услуги архитектора, вести свои курсы и т.д.
Если же вам хочется и нравится руководить командой разработчиков, то стоит двигаться в этом направлении и стремиться искоренять из себя разработчика — это самое сложное. Надо стараться делегировать задачи, а не делать их самому. Кстати, рекомендую отличную книгу Как пасти котов, в которой собраны советы программистам, которые хотят стать руководителями.
Neikist
Я не совсем согласен с графиком для tech-skills, возможно я еще слишком мало проработал, но на мой взгляд на 90% эти навыки состоят из базовых знаний и навыков (системное, логическое мышление, навыки декомпозиции, навыки самообучения, навыки решения задач, понимания задач, математика, алгоритмы, предметная область), а конкретный стек технологий скорее как надстройка над этим.
Vantela
Без опыта с конкретным стеком технологий применять все эти базовые знания и навыки очень «неуютно». Так что 10% это вы маловато выдали.
Кроме того специфика профессии в том что действительно красивые и интересные задачи попадаются крайне редко (и не тебе!). А применять системное и логическое мышление в задачах вида «выведи там окошечко, там цифру из той ячейки, а когда пользователь нажмет 'ок', значение положи вот в ту табличку» — крайне не простое занятие:-)
RomanKu Автор
Тут есть один нюанс: В классическом разделении есть только soft-skills и hard-skills.
Я же разделил hard-skills на 2 части
Например, 10 лет назад я писал десктопные приложение в одной очень известной RAD и что у меня из этого осталось? Ну общие подходы и опыт работы с многопоточностью.
Если выучить веб фреймворк, то технические знания увеличатся, но если при этом не разбираться в его работе, на задумываться о безопасности, и.т.д. то `hard-skills` будут минимальными.
Если взять формулу, то получится примерно следующее
GeekberryFinn
Поддерживаю!
Потому что у автора скилсы получается как в известном анекдоте:
— вы имеете опыт работы с американским махгони?
— я столяр и умею работать с любым деревом, включая красное дерево
— нас интересует, есть ли у вас опыт работы именно с американским махгони, весь остальной ваш опыт нас не интересует!
JC_IIB
Ну кстати, анекдот-то, если вдуматься, не совсем и анекдот. Человеку задали четкий вопрос — «Имеете ли вы опыт с фреймворком Х?»
А он отвечает не на заданный вопрос, а на абсолютно левый — «Я умею работать с ЛЮБЫМ фреймворком.»
Во-первых, «умею» != «есть опыт» (грань тонкая, но есть), во-вторых, меня не интересуют любые фреймворки, иначе я бы так и спросил, я спросил конкретно про фреймворк Х и жду ответа конкретно про него.
GeekberryFinn
Суть в том, что незнание конкретного фреймворка не аннулирует весь прошлый опыт работы с похожими фреймворками.
А у RomanKu по его формулировкам в статье — получается, что джуниор погода назад освоивший фреймворк «круче по hard-skills», чем тот кто с этой Джавой уже 15 лет работает, но именно с этим конкретным фреймворком не работал.
JC_IIB
Если в работе нужен конкретный фреймворк — то до опыта в других фреймворках мне нет дела, поэтому и был задан конкретный вопрос, на который следовало ответить четко и ясно, а не растекаться по древу «а я и на машинке умею, и вышивать тоже».
GeekberryFinn
Значит ты гуманитарий ничего в IT не смыслящий. Потому что подойдёт и просто похожий по концепции фреймворк.
Столяр ответил, что умеет работать с красным деревом, а «американский махгони» — всего лишь конкретная разновидность красного дерева.
JC_IIB
Удивительно, как я умудрился получить почти двадцать лет стажа в ICT.
Повторяю еще раз — похожих по концепции не надо, надо конкретный вот этот вот, на котором у меня всё построено. Мне не нужно, чтобы человек разбирался, чем то, что он знает, отличается от того, что есть у меня — я не на обучение его беру, а на работу.
Его не об этом спрашивали.
GeekberryFinn
Похожий по концепции возможно быстро освоить — вплоть до того, что может являться возможным написать на нём что-нибудь вразумительное в первый же день.
Не обязательно иметь опыт работы на MicroSoft SQL, чтобы писать на нём зная Oracle PL/SQL, и обратное — тоже верно.
Его спросили про «американский махгони», а это — разновидность красного дерева.
«Видно льва по когтям» ©
То есть, в вашем случае не видно, что вы — разбираетесь в этом.
JC_IIB
Да, только как я уже написал, мне не нужно, чтобы он осваивал, мне нужно, чтобы он писал.
Ну так и отвечал бы про махАгони.
GeekberryFinn
Если достаточно похож — писать можно в первый же день. Пример с разными версиями SQL я уже привёл.
Махагони — это красное дерево, его конкретная разновидность.
JC_IIB
Удачи ему, когда он, умеючи в mysql, попытается понять, почему его удаленный клиент не цепляется к постгресу. Про pg_hba он, конечно же, не слышал.
p.s. безотносительно джунов, баз данных и всего такого. Я терпеть не могу людей, которые отвечают не на поставленный вопрос, а на тот, который выдумали сами себе из головы и считают, что так и надо.
GeekberryFinn
С любой подобной особенностью — можно разобраться меньше чем за день.
Вам — чашечки или ехать? Вам нужно, чтобы он писал, или не это нужно?
JC_IIB
Мне нужно, чтобы он писал, а не «разбирался за день».
Хотяяяя… он же джун. Тогда да, возможно мне просто нужен мидл. Нанимая джуна — будь готов к тому, что он будет сравнивать, познавать и разбираться. Плох тот джун, который не хочет стать сеньором :)
Но при прочих равных, даже нанимая джуна, на джуновскую позицию, я бы однозначно взял того, который ответил бы честно — «Нет, я не знаю этого фреймворка, но горю желанием разобраться», нежели того, который ответил бы «Да я все фреймворки знаю, чё там — они одинаковые же!».
bo0rsh201
Простите за прямоту, но ваши ответы показывают что вы либо фантазер-максималист, совершенно оторванный от реалий индустрии, либо у вас какой-то уж очень специфический опыт.
Компании дерутся за адекватных обучаемых людей, прекрасно понимая что конкретный фреймворк или технология совершенно вторичны и легко осваиваются (плюс в крупных как правило все равно все свое), и грамотно инвестированные в человека пара недель-месяц на старте потом с лихвой окупятся.
А с вашей позицией я смутно представляю себе как можно кого-то вменяемого нанять.
JC_IIB
Все проще. Я, признаться, был несколько невнимателен и упустил слово «джун». Да, разумеется, нанимая джуна, будь готов к тому, что он какое-то время будет курить мануалы.
Neikist
Вот не пойму, то ли среди разработчиков за вас конкуренция дикая, то ли вы что то не договариваете. Наша компания готова людей с любого стека брать, лишь бы показал что умеет программировать и обучаться достаточно быстро и качественно, и то дикая нехватка людей и вакансии постоянно висят.
sasha1024
GeekberryFinn
Если человек имеет опыт изучения фреймоворков — то он да обучаем.
sasha1024
Та любой челевек обучаем, вопрос в том, насколько быстро это происходит.
0xd34df00d
А когда проект на этом фреймворке закончится, вы его уволите?
JC_IIB
Ну совсем нет же. Во-первых, проект может быть ОЧЕНЬ долгим. Во-вторых, он может научиться чему-то еще (абсолютно добровольно, из интереса) и сможет взять и другие проекты.
Увольнять людей вообще плохая политика, особенно, если они не косячили, а работали честно.
0xd34df00d
Ну, на мой взгляд, синиор с кучей опыта в куче разных фреймворков за спиной, этим доказал, что учиться чему-то ещё он может хорошо и эффективно, а про джуна это ещё не так очевидно.
JC_IIB
Согласен, но главное, как я уже писал выше — чтобы он отвечал честно.
GeekberryFinn
… и за эту честность вы JC_IIB — незамедлительно накажете отказом!
Судя по вашим рассуждениям вы JC_IIB — сами код никогда серьёзно не писали и никогда ничему не самообучались.
Если вы не врёте, что работаете в IT — то вы явно начали свою работу сразу в качестве самодура-менеджера, и продолжаете вашу ТОКСИЧНУЮ деятельность уже десяток лет.
JC_IIB
Ну, если я такой «самодур-менеджер, никогда не самообучавшийся и не писавший код» (а утверждение это абсолютно несостоятельно, ни целиком, ни в какой-либо его части) — то мой отказ это не наказание, кто ж захочет с таким мной работать? :)
Повторюсь, у меня из внимания выскользнуло то, что вакансия-то джуновская. Так что никакой токсичности, сплошное недопонимание.
Справедливости ради скажу, что слово «джун» появилось в рассуждении позже, в исходном «анекдоте», из-за которого разгорелся весь сыр-бор — слова «джун» нет, вообще неясно, на какую позицию нанимается человек.
Между тем, есть замечательная тактика. Если тебе отвечают не на тот вопрос, который ты задал — повтори его слово в слово. Два, три, восемь раз. Пока человек не ответит тебе то, что хочешь знать ты, а не то, что он тебе рассказывает. Работает, рекомендую.
GeekberryFinn
Слово «джун» появилось после ваших слов об отказе от опытного разработчику не знающего конкретный фреймворк, зная похожие.
Из ваших слов вытекает, что вы вместо опытного разработчика предпочтёте взять джуна, если джун знает именно это фреймворк.
JC_IIB
Я честно несколько раз перечитал эту фразу. Может, ее как-то переформулировать? Особенно, если учесть, что слово «джун» появилось в вашем комментарии в данной ветке.
Это зависит еще от ряда факторов, не только от «джун, знающий фреймворк — миддл, фреймворк не знающий».
GeekberryFinn
Я и говорю, что спросил про джуна, после ваших слов, от том что вы откажете мидлу не знающего именно этот конкретный фреймворк, но работавшего с похожими фреймворками.
JC_IIB
Я же говорю — зависит от ситуации. Если мы неспешно пилим MVP — добро пожаловать, а если надо вот прям щас садиться и спасать мир… не знаю, что хуже — искать компетентного человека или ждать, пока мидл выучит нужный фреймворк.
VolCh
Если бюджет под позицию ограничен, не выше среднего по рынку, то искать человека в точности знающего ваш стек, можно очень долго. Скорее правильней будет взять того, кто какую-то его часть не знает с надеждой, что изучит в работе.
mapron
Да я вообще всегда когда комменты на хабре читаю, себя каким-то конченным дауном чувствую.
sshmakov
"умеет" != "имеет опыт"
В соответствии с означенным эффектом Даннинга-Крюгера столяр (джун-программист) может быть совершенно уверен, что он справится с красным деревом (последним ангуляром), вот только опыта такой работы у него не было. Только сосна, только php.
Usmekhaiouschiysia
Ну кстати с сосной реально тяжко работать, у неё плотность волокон страшно неоднородная. Так что если нужно что-то сложнее грубо сколоченных конструкций, а то и резное — с твердым деревом муторнее, но проще.
JC_IIB
О чем я и говорю. Человек (джун, не джун — неважно!) на собеседовании может брякнуть что-то типа «Да че там, эти фреймворки все одинаковые!», а потом внезапно обнаружить, что они разные.
Тут будет куда более уместен ответ — «Нет, я не знаю этот фреймворк, но я готов учиться». И, в зависимости от состояния проекта, кандидат вполне может быть принят с таким ответом.
p.s. я пробовал работать с хвойной фанерой ФСФ. Та еще развлекуха, доложу я вам.
roscomtheend
Если там есть особенности (типа неравномерностей, а цена велика и не зная этого на первых работах можно запороть несколько дорогих заготовок), то опыт работы с аналогами не поможет. Возможно, работодатель хочет просто учесть риски.
RomanKu Автор
Интересные выводы. Информацию об аффторе можно найти в интернетах (например, LI)
Никогда не считал себя гуманитарием
Columnistdc
А по поводу
Может кто-нибудь из серьезных бородатых тимлидов еще отписаться? Мне всегда казалось, что прыгание по проектам характеризует человека как неусидчивого\неуживчивого\туповатого(но это не точно), в целом, человека, на которого как раз нельзя положиться.Vantela
Кстати, да. Тоже очень подозрительным показалось.
У меня знакомый был который как то 4 места работы за год сменил. Разгильдяй редкий.
Так что джун-попрыгун скорее всего обладает какими то несовместимыми с нормальной работой дефектами.
PS Тоже касается и людей которые просидели на одном стуле 10 лет.
wlr398
Зависит от масштаба предприятия. В маленьком за 10 лет может не поменяться ничего.
В большом несколько раз сменились технологии и оборудование.
Возьмите сотовых операторов. 10 лет назад превалирующей технологией была 2G и звонки.
Потом пошли 3G нескольких вариантов, LTE нескольких вариантов, уже тестируется 5G. Сотовики стали магистралами с соответствующим развитием пакетного транспорта. Пошли в ход бигдата и нейросети для анализа данных. Да много чего ещё. Да даже госконторы прошли путь от небольших сетей на тонком езернете, модемной связи и серверов на Netware до современных мплс сетей на всю страну, мощных кластеров с облачными сервисами и т.п.
VolCh
Мой опыт в разработке говорит скорее об обратном: небольшие предприятия менее инерционны в плане использования актуальных технологий. По крайней мере если говорить о небольших ИТ-компаниях или больших не ИТ-компаниях с своим отделом разработки. В больших же ИТ-компаниях очень часто в иерархии управления найдётся человек отказывающийся брать на себя риски обновления без очень сильной бизнес-нужды. В небольших компаниях гораздо чаще понимают, что актуальные технологии на проекте — это дополнительный способ мотивации разработчиков, гораздо более важный для многих чем печеньки и фитнес.
VolCh
Речь не идёт об ИТ-гигантах, создающих массовые технологии.
eXoToL
Плохо смотрится когда часто меняешь работу, а не проекты!
У меня в компании, например, за год в среднем проектов 4-5.
Приходят какие-то доработки, например, и тебя просят сделать
+ поддержка своих 2-3 проектов или параллельно тебя продают еще в аренду =)
В итоге, у меня почти за 5 лет около 20 проектов
michael_vostrikov
У меня первая работа была неофициальная, сдельная с непонятной зарплатой, с кучей легаси, и в одиночку. Потом 3 месяца в веб-студии джуниором за 3 тыщи. Потом была работа относительно нормальная по региону (10-15), но через несколько месяцев предложили в соседнем городе с зарплатой в 2 раза выше. И параллельно еще разовый проект был на несколько месяцев. Это всё в течение года. Где я по-вашему должен был долго работать?)
RomanKu Автор
Это достойно отдельной статьи и обсуждения.
Если он меняет компании и проекты потому, что не может нормально работать, то это один вопрос, но если ему дали 1-2 мелких проекта (например он + более опытный напарник) и он их выполнил, потом до полугода его подсадили на крупный и долгий проект для помощи и роста + ему подкинули внутреннюю штуку сделать, то тут уже совершенно другой разговор идет.
jaxxreal
Отписываюсь.
Проектов != рабочих мест. 3 проекта за год = 4 месяца на проект.
Т.е. если в компании, где работает джун большая текучка проектов, он неусидчивый\неуживчивый\туповатый?
Vantela
Как же я далек от народа. Я привык, что за 4 месяца хорошо если ТЗ согласуют хотя бы наполовину.
jaxxreal
Проекты разных масштабов бывают. Например, экранов добавить, верстку поправить и т.д.
Vantela
А, тогда понял.
-исправил опечатку в окне «О программе».
-добавил выбор «г-н»\«г-жа» на экране регистрации
-добавил окно с надписью «Спасибо за визит» после нажатия на «крестик»
И в резюме можно писать еще три успешных проекта:)
kosmonaFFFt
Не обязательно. Например бывают проекты вида «нужно быстро запилить какую-нибудь штуку для обработки заявок, интегрировать ее с системой1, системой2 и сделать API для системы3». 90% проекта 2 человека * 2 недели, срок жизни системы 1-2 года максимум.
RomanKu Автор
И уже мидл, переходящий в сеньеоры. Я даже и не припомню сколько народу ко мне приходило на собеседование с такими резюме
aknew
Вполне возможно что синьоры и мидлы подключились еще на стадии пресейла оценивая техническую часть по затратам и задавая вопросы по хотелкам юзера и это все длится несколько месяцев (те самые ваши 4 месяца на согласование), а вот когда все уже согласованно и надо писать конкретные маленькие кусочки подключают джунов. Также возможно что гарантийным багфиксингом тоже занимается синьор или мидл, а джуниора перекидывают на другой проект, вот и получается что джун на проекте 4 месяца, а более старшие товарищи год.
Хотя не могу не признать что за исключением чего-то типа Proof of concept проектов всего в 4 месяца активной разработки не припомню
Vantela
Этот сценарий мне тоже знаком.
Крутые сеньоры подрядчика полгода обсуждают детали проекта со спецами заказчика.
А когда все наконец согласовано вместо сеньоров приходят джуны которые не умеют ничего.
Денег за них заказчик платит как за сеньоров, конечно же.
aknew
Я имел в виду именно вариант без мошенничества когда джуниоры изначально согласованны и просто приступают к работе не сразу, но сценарий как у вас тоже возможен.
0xd34df00d
У меня есть проект, на реализацию которого ушло 50 дней де-факто и месяцев восемь календарно (т.к. это сайд-проект). Не самый тривиальный оптимизирующий компилятор для не самого тривиального языка. И это, пожалуй, одна из тех вещей, которыми можно гордиться по результату.
Я его на хаскеле писал, правда. На плюсах было бы на порядок дольше.
JC_IIB
Вспомнилось старенькое, но отличное :)
0xd34df00d
ASN.1 таки покруче будет :)
JC_IIB
Валкин вообще какой-то демон, прости господи :) интересно, где он сейчас, что пишет…
roscomtheend
Вопрос что за проект, есть большой Проект с большой буквы, но в него входят несколько (десяток+) самостоятельных и в меру независимых проектов со своими этапами и задачами, сроки на каждый — несколько месяцев (делаются частично параллельно), но кодинга там — недели на две-четыре на каждом (остальное — выработка и согласование ТЗ, оформление документации и оттчётов), нет смысла держать джуна на нём весь срок — подключили после готового ТЗ на этап работ, отключили после, перевели на следующий, подошедший к этапу реализации. Для него это два проекта (да и солиднее цифра 2, чем 1), «но мы-то знаем...»(Ц) о глобальности всего этого и можем сказать что проект один.
SergejT
А бывает история, прийдешь такой 35 летний в новый проект по переписыванию пхп на с#, а там сидят «старички» и косо смотрят, а могут и «съесть».
JC_IIB
Хорошая статья, хотя бы потому, что она не пушит обрыдлую идею «Программист, развивайся в управленца!».
Я знаю изрядно людей, которым тупо неинтересно быть управленцами, им это не надо, они сидят и пишут кот.
wlr398
Не только программист. Есть куча других специализаций, работающие по которым не хотят быть управленцем. Вопрос в том, как искать работу, если работодатель схлопнется, а тебе 50 лет. И ты не Роб Пайк или типа того. И живёшь в провинции.
asoukhoruchko
Занимаясь набором людей и видя много проектов — в какой-то момент понимаешь, что 50+ -летние дядечки для некоторых проектов подходят сильно лучше молодёжи.
Более того, если человек в 50 лет продолжает развиваться — он скорее всего в принципе лучше любой молодёжи. Вижу такие примеры.
Ну и есть проекты, где «тупое легаси, надо просто поддерживать» — и человек, который уже спокойно строит дачу и имеет нужный скиллсет, подойдёт туда значительно лучше молодого парня, которому всё хочется переписать.
К сожалению, далеко не все работодатели это понимают.
JC_IIB
Поддержу, скиллованный консерватор на этой позиции будет куда полезнее хипстера, потрясающего очередной bleeding egde hype-driven технологией. Потому, что если все работает, работает как надо и всех всё устраивает — не трогай.
wlr398
Проблема ещё в том, что переход из технаря в управленцы скорее всего закончится управленцем нижнего, в лучшем случае среднего звена. Которым жестоко, нещадно выносят мозги. Дорасти до топов не получится с большой вероятность. Там всё оккупировано управленцами, которые были сразу управленцами, с дипломами МБА и прочими управленческими регалиями.
И не известно, что лучше, остаться технарём или стать управленцем нижнего звена, которому постоянно выносят мозг, постоянный стресс.
JC_IIB
«У генералов свои дети есть» (С)
VolCh
Смотря чем стремиться управлять. «Ваши» управленцы настроены, по-моему, на управление людьми и(или) финпотоками и с удовольствием отдают управление техническими вещами техническими специалистами. Когда искал себе (как ведущий разработчик, нежелающий много времени тратить на управление людьми и рутинные задачи) тимлида или ПМа очень чётко резюме делились на две группы даже при одинаковом послужном списке: в одних акценты на численности команды, выстраивании процессов разработки, обычно scrum, успехах в мотивации и т. п., «продажах» бизнесу, а в других на технологиях, технических решениях бизнес-задач, количественных и качественных технических характеристиках проектов. И на собеседованиях первые с точностью до человека могли назвать сколько народу было в подчинении в любой день, какие бюджеты были у проектов, а другие список технологий и количество серверов.
Субъективно отличаю первых от вторых по отношению к людям, деньгам и технике(включая софт): для одних объект управления деньги и люди, а техника — ресурсы, для других наоборот. Первые в целом метят на позиции CEO/CFO, вторые на архитекторов/CTO.
snuk182
Вывод для интроверта — без софт скиллов ты не нужен (тм). Вот тебе мылко и веревка.
RomanKu Автор
Я так понимаю, что вместе с этим комментарием прилетел и — в карму ;-)
Интроверту искать проекты с минимальной коммуникацией и там, где софтскилы не так важны.
snuk182
Я отдавал себе отчет о последствиях этой фразы. Тем более что я сам "из этих", пытавшийся работать менеджером, с эпик фейлом в конце. Пока решил, что могу обучать молодняк, так как хорошо умею обьяснять то, что понимаю сам. Но как представлю вот эти все бесконечные митинги и договоры, прям знобит.
RomanKu Автор
Из комментария следует, что заключение верно на все 100%: пересиливаешь себя — лучше сразу остановиться и не мучать себя. Не хочешь менеджерить и кодить — попробуй обучать.
defuz
Я думаю это ложный вывод. Быть интровертом вовсе не означает быть социопатом (и соответсвенно иметь очень низкий уровень soft skills). Интроверты тоже вполне способны развивать soft skills, разве что немного в другом направлении в отличии от экстравертов. Например, более менее известно, что интроверты гораздо более чуткие, и потому скорее всего смогут лучше осознать проблему подопечного разработчика и подобрать нужные слова, чем экстроверты. Интроверты предпочтут тет-а-тет комунникацию глобальному брейнштормингу и т. д.
Другое дело, что в основом о soft skills приходится слышать как раз от экстравертов, потому что это их «тема». Вот и получается, что интраверты пытаются натянуть шкуру экстравертов в плане soft skills на себя и идут за мылом и веревкой.
Gorthauer87
Кажется ты путаешь социофоба и социопата, последний вообще может вполне неплохие soft skills иметь, просто ему будет плевать на то, что случится с людьми вокруг него.
Но вообще же разница между интровертами и экстравертами прежде всего в том, что вторые заряжаются при общении, а первые разряжаются и поэтому они стараются его дозировать, чтобы не тратить силы по пусту.
Debug_all
А по поводу интровертов и их soft skills интересный взгляд есть в книге Девора Зак «Нетворкинг для интровертов» («Networking for People Who Hate Networking: A Field Guide for Introverts, the Overwhelmed, and the Underconnected» by Devora Zack в оригинале).
Для себя нашел еще одну аналогию: люди — это усилители. Не даром ведь существует выражение «на одной волне с кем-то». Экстраверты — широкополосные усилители. У них большой рабочий диапазон частот, т.е. им легче с ходу найти общий язык со многими. Интроверты же — узкополосные усилители, они резонируют с определенными категориями людей. Но ширина полосы обратно пропорциональна возможному коэффициенту усиления. Интроверты способны на кратно большую интенсивность в общении на своих рабочих частотах (попробуйте остановить интроверта, который рассказывает Вам что-то, что ему действительно интересно). Т.е. нужно учиться перестраиваться в некоторых границах и искать окружения единомышленников. И отдыхать, восстанавливаться, конечно.Neikist
Хз, я считаю себя интровертом, но либо эту категорию людей не нашел, либо ее не существует, либо вы не совсем правы. Мне в принципе комфортней быть одному, чем общаться с кем либо. И от общения на работе приходится отдыхать дома. Хотя со стороны это менее заметно, поскольку без общения решать рабочие задачи трудно, поэтому временами вполне интенсивно общаюсь.
sasha1024
«От общения на работе приходится отдыхать дома» — из этого не следует «мне в принципе комфортней быть одному, чем общаться с кем-либо». Просто у Вас среднедневное количество общения немного (или не немного, не знаю) превышает наиболее комфортное для Вас. Но фактическое количество общения может быть и ниже оптимального (даже для Вас), например, если Вы годик посидите дома, никуда особо не ходя. Хотя я не знаю, может быть лично для Вас оптимальное количество общения и 0, но я сомневаюсь, что оно ровно 0. По крайней мере, у меня не ровно нуль (причём за много лет жизни я привык к тому, что люди «мешают» и нужно всеми средствами «отвоёвывать» себе возможность от них отдыхать, так что, когда в какой-то момент количество фактического общения стало ниже количества оптимального, это стало некой неожиданностью (причём не очень приятной, потому что у меня не было привычек по поводу того, что стоит делать в такой ситуации, в отличие от противоположной)).
Neikist
Ну вот недавно две недели отпуска брал от общения отдохнуть. Вообще ни с кем не общался голосом. На работе общения от 30 минут в день до пары часов, дома слава богу один живу и ни с кем не общаюсь.
sasha1024
Две недели — очень мало. За этот интервал Вы, наверное, даже и не ощутили этот режим как постоянный («всегда так будет»), а только наслаждались разнообразием (по сравнению с основным режимом). Хотя я не спорю, что у Вас может быть действительно нуль (или очень близко к 0).
VolCh
А зачем вы тут общаетесь? )
Neikist
1) Узнать что то новое, что то спросить полезное.
2) Сдвинуть немного представления людей в нужную мне сторону.
3) Сформировать мнение о себе у потенциально полезного мне сообщества.
4) Получить информацию о мнениях и поведении людей со схожими интересами для уточнения своего мнения. (пересекается частично с пунктом 1)
Самое главное что тут иницииатором общения всегда выступаю я и только когда мне надо. До тех пор пока не проверю наличие уведомлений вполне отдыхаю.
Все таки люди существа стайные, соответственно приходится часто мимикрировать чтобы занять в стае нормальное место, получить нужные плюшки, эффективно выполнять работу.
Zverik
Интроверт ? плохие soft-skills. Вот я интроверт, но медленно прокачиваю. Просто отдыхать между подходами приходится дольше.
hippohood
Очень часто люди говоря: "ох, да я интроверт" имеют в виду что им не нравится оказываться в новой и некомфортно социальной ситуации и что им лень интересоваться другими людьми. Для успешной карьеры в управлении людьми и предприятиями нужен интеллект, желание учиться и немного эмпатии. Да и само это разделение больше связано с ролью индивидуума в конкретном коллективе и меняется со временем и с обстоятельствами. После 30 вообще разница несущественна, поколение взрослых диктуется требованиями социума.
Я даже скажу что в корпорациях (по крайней мере инженерно- промышленных) на верхних этажах вы не встретите ярких экстравертов, зато ярко выраженных интровертов (или ведущих себя так) сколько угодно
werklop
занятная же у вас классификация… :)
RomanKu Автор
Ответил ниже
RomanKu Автор
• ну так в пермом случае главному герою было лет 20-22 и он смотрит на тимлида, как на старика.
• лет через 5 он уже разницу не так сильно ощущает, да и разрыв в возрасте и опыте уже не такой большой.
• еще через 5 лет он смотрит на молодое поколение и начинает чувствовать себя старым
Все относительно…
По крайней мере у меня были именно такие мысли во всех IT компаниях города, где мне довелось поработать.
lipkij
Главное, ребята, сердцем не стареть! :)
JekaMas
Или Коля забил на умные статьи и стал точиться в наиболее сложных и дорогих для рынка навыках, например, ML, DL, распределенные вычисления какие, highload с какими-нибудь >1M rps, разработка бд и так далее.
Рынок его сузился, но востребованность после очередного периода джунства резко выросла.
Коля ушел в суровую специализацию, но одновременно расширил свои навыки и скорее всего по дороге освоил еще несколько ЯП.
И Коля стал настоящим senior с хорошей ставкой и полным непониманием, зачем ему переходить в лиды, PM и так далее.
ganqqwerty
Это если он технологию угадал, а мог ведь уйти в какой-нить семантиквеб и все...
lxsmkv
Думаю, не стоило показывать графики если на самом деле никаких цифр нет. Даже оси не подписаны. К модели тоже, мягко выражаясь, вопросы. Создается видимость фактического подкрепления сказанного, а оно является чистой эмпирией. (поэтому нажал стрелочку вниз)
А вот личный опыт и основанные на нем советы — это полезно, для тех, кому этого достаточно.
RomanKu Автор
Я долго ждал подобного комментария и был удивлен, что он долго не появлялся.
Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.
Я бы с радостью построил математическую модель и проверил бы ее на основе каких-либо исследований, но дать объективную оценку скилам практически невозможно. Даже сам поиск способа оценки может вылиться в нехилое исследование. Даже технические скилы, например, тесты на апворке не всегда отражают объективной ситуации и могу как минимум быть набиты с N попытки.
Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
geisha
Довольно занятно было почитать с перспективы развития в научной среде. Сначала ты, действительно, кодишь / выполняешь другую работу в лабе. Потом ты пишешь заявки на гранты чтобы кодить / работать в лабе. Затем добавляются студенты, которых ты должен чему-то научить. Потом ты пишешь гранты за студентов и нанимаешь их чтобы они кодили и работали в лабе. Наконец, на работу в лабе и кодинг уже нет времени: ты становишься 100% «менеджером».
Думаю, в медицине да и во многих отраслях примерно так же. По прошествии определенного этапа за тобой заботливо закрывают двери. В этом плане программерская среда, конечно, более демократичная.
RomanKu Автор
В ряде сфер есть привязка в выслуге лет. В IT я про такое не слышал и программировать можно хоть до победного. Я знаю и знал специалистов, которые были очень сильны именно как технари, но при этом в плане общения были очень тяжелы. Правильный руководитель создаст для такого сотрудника условия, при которых он сможет комфортно для себя и других выполнять свои обязанности (при условии, что такая возможность есть).
Daddy_Cool
Да, тоже стал сравнивать как у нас происходит. В научной среде задачи все же другие — надо не производить материальный продукт, а выяснять как и что происходит в природе. И чем выше скилл гм… соображения тем меньше нужно заниматься непосредственно технической работой. Я вот сейчас пишу формулы и думаю, а кодит аспирант. Хотя некоторые формулы уже и он написать может. А какая у вас область?
geisha
Физика тв тела + материалы + кв. химия, всё теория.
VolCh
На заре отечественной разработки (и реалиях контор, работающих по классификаторам) аналог сеньора — старший инженер. Ведущий инженер — именно лид. Может быть ближе к техлиду, может лид инженер, но лид.
Sergamers
Прочитав статью, порадовало мышление автора. Мне вот интересно кто как себя ведет когда приходит осознание того, что его основная технология устарела и ему требуется переквалифицироваться. Скорее всего в этот момент ему придется проиграть в з.п.
Приведу пример, который меня лично периодически беспокоит. На этапе становления на фронте принял решение изучать angularjs. Со временем я сделал ставку на angular 2 вместо react. С течением времени я стал замечать новые вакансии вида react и vue, и реже angular 2(6+), что обеспокоило меня. Изменение стека разработки влечет уменьшения твоей продуктивности. К примеру в angular у тебя уже есть архитектурный подход и т.п. Это влечет за собой изменения твоей вакансии (скажем синьера на мидла) и я бы описал это так ( бьет по самоооценке ) — автор назвал это Кризис возраста. Встает вопрос ( это уже к программистом со стажем ) при изменении стека технологий на сколько релевантен твой опыт, который можно перенять с прошлых технологий. К примеру на вряд ли занимая должность TeamLead в extjs или backbone ты станешь тимлидом в angular, react, vue и т.п. С удовольствием бы услышал мнение на этот счет)
VolCh
Сильно зависит от конкретных вакансий. Одни компании больше ценят широкий кругозор, чем конкретную технологию, другие требуют знаний конкретного стека (по факту их вакансии могут месяцами висеть, хотя за это время вполне можно стек изучить было), третьи где-то балансируют, реально требуя, скажем, 50% из списка «требуется», ещё с 30% что-то близкое (скажем за тайпскрипт легко проходит даже javascript+java/c#, а то и PHP, не говоря о flow), а 20% можно на уровне «читал вводный пост на хабре».
В целом можно получить хороший оффер, подразумевающий даже смену языка (не диалектов) и целевой ОС, если есть хорошие знания предметной области и какие-то свидетельства, что ты умеешь решать бизнес-задачи с помощью программирования на разных языках, а не просто программировать на конкретном.
GeekberryFinn
А меня — не порадовало.
Потому что у него hard-skill жёстко прибит гвоздями к конкретному фреймворку, без какого-либо учёта предыдущего опыта и лёгкости изучить новое на основании знаний похожего.
RomanKu Автор
Предлагаю перечитать статью еще раз и комментарий к ней, а потом уже «нерадоваться»
Автор специально ввел понятие tech-skills для того, чтобы убрать из hard-skills фреймворки, библиотеки и прочее, а оставить именно опыт и фундаментальные знания.
Peretyaka
Мне кажется, для TL изучить React, а тем более Vue, зная стек и Angular — это пара выходных.
VolCh
Если говорить о изучении собственно react+react-dom, то да, что писать можно даже в день когда начал изучать. Но одна из особенностей react по сравнению с Angular и Vue — это не фулстэк фреймворк даже близко, а голый слой представления с довольно примитивным встроенным управлением состояния. Очень многие компоненты полноценного приложения надо будет выбирать дополнительно без чёткого понимания плюсов и минусов выбора даже для простейших приложений. В фуллстэк фреймворках такой выбор уже сделан.
Sergamers
Согласен, что ознакомиться с ним делов пару дней. А вот реализовать проект на том же уровне, что на родном стеке — нет)
RomanKu Автор
У меня 2003-2006 годы — Pascal, Delphi, C++.
с 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 фуллстеком.
Что помогало?
Возможно, что-то еще.
Могу сказать, что смена стека технологий прошла тяжело, однако, относительно быстро, за 1.5+ года nodeJS знаю больше, чем среднестатистический молодой nodeJS разработчик, который пишет 3 года в резюме (переходы были без понижения ЗП)
На текущий момент именно программированием занимаюсь только при необходимости (когда надо, а людей нет), но основная проблема с кодированием — постоянные задачи, которые надо решать, делегировать, контролировать.
VolCh
Не путайте вранье и стремление донести максимум ревалентной информации вместо односложного «правдивого» ответа. Если вам так важен опыт работы с конкретной технологией конкретной версии, но до собеседования вообще не стоит дело доводить с теми, у кого его нет. Это очень большой минус компании, если потратив много времени на контакты с ней выясняешь, что ты не прошёл по необладанию опыта какой-то технологии, о котором ты никогда не заявлял.
sasha1024
Что важного затрагивает эта статья и что прямым текстам, по-моему, стоит втолковывать ещё в школах (сейчас может, и говорят, но как-то неакцентированно) — что с возрастом когнитивные способности сильно падают (когда-то наступит момент, после которого ты уже не сможешь каждый день по новому фреймворку разбирать). И к этому имеет смысл готовиться заранее (либо заранее приобретать необходимые навыки (что не всегда возможно, потому что ты заранее не знаешь, что тебе потом понадобится), либо постепенно смещаться в сферы с меньшей динамикой требуемых компетенций или готовиться туда смещаться (что не всегда интересно, потому что хочется быть «на пределе»)). К сожалению, раньше я этого не понимал, (хоть старшие и упоминали не раз, что молодые быстрее соображают, но) был уверен, что это ко мне не относится и я всегда останусь таким, так тогда, и соответственно, заранее приобретать необходимые навыки не считал нужным.
Neikist
У меня когнитивные способности и способности к обучению года в 22-23 резко подскочили, а также лет до 14-15 высокими были. А промежуток как будто потерял. Я за год осваиваю сейчас или до 14 столько же сколько осваивал за 3-4 года учебы в вузе.
sasha1024
У меня (субъективно) пик был в 25, а потом стали резко падать.
Хотя я вроде читал, что объективно лет после 12 только спад.
vedenin1980
Напомните средний возраст Нобелевских лауреатов? И вообще большинства известных ученых с мировым именем? Если что ссылка. Дело даже не в том, что нужно время, чтобы оценили заслуги, большинство 70-90 летних профессоров в разы лучше разбираются в новейших исследованиях по своей области, чем аспиранты.
Медики говорят, что если постоянно заниматься мысленной деятельностью, когнитивные способности не снижаются, более того ВОЗ считает что до 44 лет это возраст молодости, когда еще практически нет возрастных изменений (ну если вы не проф. спортсмен).
Поэтому нет, это не ваши когнитивные способности снизились, это ваш мозг лентяйничает (он это любит, да).
sasha1024
Причём тут возраст нобелевских лауреатов?
Эффективность человека — это, если что, не только соображалка, но и количество знаний, а также доступ к информации (и прочим ресурсам) извне и прочее — комбинация этого всего достигает пика явно не в 12 лет.
Но соображалка с возрастом падает — это факт.
PerlPower
С возрастом становится меньше здоровья и выносливости, что в конечном итоге может восприниматься как падение обучаемости. Но, конечно, в уровне конечного влияния на карьеру разницы нет, устал ты или отупел. На своем личном примере я могу сказать, что после тяжелой работы вечером не остается сил даже на формошлепство, даже если оно до этого было на автоматизме. При это в последние годы я начал понимать то, что не понимал в математике ни в школе, ни в институте. В любом случае отбракуйте вариант со здоровьем и утомляемостью.
Также типовая работа веб-разработчика, мобильного разработчика или энрепрайзера не требует колоссальных умственных затрат. Прохождение собеседований — другое дело, но там что называется нужно заставить себя готовиться. Учить же все что есть на рынке невозможно. Обилие php-фреймворков конца нулевых было примерно такого же уровня как и сейчас фронтендовых фреймворков. Ни тогда, ни сейчас я не в состоянии это выучить на таком уровне чтобы меня нельзя было бы завалить на собеседовании. И среди программистов часто попадается такое дно, что понимаешь, что не в знаниях дело. Те кто громко кукарекают об иммутабельности, лямбдах, реактивном программировании и т.д. далеко не всегда настолько хорошие программисты как может показаться на первый взгляд. Наличия самородков это не исключает, но самородков на всех и не хватит.
sand14
Хорошая статья, но опять типичная ошибка, когда путают сеньора и лида:
Раньше были старший и ведущий инженеры(-программисты).
Сейчас это называется Senior и Lead.
Нужно понимать, что это Lead ведет за собой, а Senior это такой заслуженный товарищ, которые много знает и умеет, решает сложные задачи, но работает в основном в одиночку.
А если и ведет/делится опытом, то больше на неформальном уровне.
Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),
Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.
RomanKu Автор
Автор решил не акцентировать на этом внимание в данной статье по той причнине, что если разобраться, то Team/Teach не выбивается из общей концепции, а еще и техлидов не хотелось бы обижать.
Но если появился такой вопрос, то могу на него ответить исходя из опыта и наблюдения как за одними, так и за другими.
TeamLead — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин
TechLead — техническй специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли. почему конкретный человек именно TechLead, а не TeamLead:
Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца и об этом было упоминание в заключении, однако, при отсутствии очень сложных проектов он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за универсальности.
RomanKu Автор
Могу под UPD добавить этот комментарий в статью.
JekaMas
Вот прям "не хочет и не может"?
Народ, сколько здесь бывших лидов, руководителей всех мастей, которые на каком-то этапе не возвращался чисто в программирование?
RomanKu Автор
Если возвращается чисто в программирование то по 3м причинам:
Нежелание может быть не так выражено, либо они еще не решили, что ему будет лучше, но они же уходят в программисты со словами «не мое это»?
JekaMas
Вам видимо трудно представить вариант мотивации "могу проекты и управление, но хочу в спокойное программирование". И деньги, бывает, не главная мотивация.
RomanKu Автор
Либо я плохо выразился, либо вы не так поняли. Я потексту указывал именно не хочет ИЛИ не может, а тут была контраста предыдущего комментатора.
Я могу представить себе такую ситуацию (и даже знаю примеры), когда хорошо получается управлять, но это отнимает слишком много сил, времени и т.д. + если ты ПМ, а твой заказчик в другом часовом поясе, то приходится подстраиваться под него, а переработки не оплачиваются.
Не являясь ПМом могу сказать, что это самая неблагодарная работа — на него давит и команда и клиент и работодатель. И плох тот менеджер, котррый это давление просто передает дальше поцепочке.
VolCh
Почему «не хочет или не может»? Звучит так, как будто техлид — это какой-то фолбэк для программиста, желающего карьерного роста: по умолчанию тимлид или пм, а если нет желания или возможностей, то можно и техлидом. Как по мне, то ровно наоборот, если говорит о человеке уже пошедшим работать программистом, а не менеджером: по умолчанию рост в сторону лидинженера/техлида/архитектора, но вот если оказывается, что не хочет или не может, то идти в сторону тимлида.
Ну и общение с бизнесом с точки зрения бизнес-задач позиция техлида ничуть не отменяет, а скорее предполагает большее, чем у тимлида и пма (если все трое есть в команде): чтобы выбрать правильный стек, правильную архитектуру нужно досконально понять бизнес-задачу. Собственно прямая задача техлида — выбирать или предлагать на выбор технические решения бизнес-задач.
sand14
Отлично, что добавили в статью — описания этих ролей как раз не хватало.
Исходный комментарий связан с тем, что в некоторых окмпаниях и в понимании некоторых управленцев, сеньору приписываются навыки и полномочия лида.
Можно делализировать тот момент, что в сеньоры попадают как те, кто просто «заслуженный», и вроде на мидл-позицию его не поставишь, но сам разработчик и не хочет развиваться особо — так и те, кто мог бы стать архитектором и тех лидом, но, как вы заметили, что «архитекторы и тех лиды не нужны», поэтому они тоже идут в сеньоры, если не хотят идти в тим лиды и тем более в управленцы.
Exponent
Почти согласен с автором, но в статье отсутствует еще один путь развития, даже два. В один момент, проработав 15 лет разработчиком, я понял что надо самому действовать. Перешел во фрилансеры, выполнил успешно 3 средних проекта. Затем открыл свою фирму и стал индивидуаальным предпринимателем, продолжил программировать, но больше поддерживать нескол-ко продуктов. Так зарабатываю больше, график гибкий, с детьми целый день. Из минусов нет платного отпуска, но зато отпуск может быть в любое время, да и на море можно поработать.
lightmaann
Хотелось бы увидеть больше мыслей людей, идущих в таком направлении. Как вариант, не своя фирма, а инвестиции. Например, если не хочет человек быть зависимым от компаний, можно подумать о создании пассивного дохода, хотя бы минимального, а там уже заниматься тем, что интересно, касательно программирования. Хоть фирму свою, хоть фриланс, хоть на наёмную.
YellowTriangleMKV
Сделайте пост про ваш опыт перехода, интересно было бы его прочитать.