Кривые развития программиста и немного об эффекте Даннинга — Крюгера

    image

    Существует два основных пути становления топ-менеджмента в IT-компаниях:

    1. Менеджерский — когда менеджер проекта начинает управлять другими менеджерами.
    2. Технарский — когда разработчик начинает управлять другими разработчиками и количество управляемого им персонала увеличивается.

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

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

    Внимание, спойлер.

    1. Все имена — вымышленные
    2. Повествование относится в большей степени к заказной разработке
    3. Скилы, а в особенности софт скилы, сложно оценить формально, все графики в этой статье являются условными и отражают мое личное мнение

    Начало пути программиста


    Итак, мы в самом начале пути программиста.

    Знакомьтесь: Николай (имя изменено). Николай — молодой программист, он хорошо учится в универе и уже пробовал писать простенькие сайты. Он устроился в студию на должность джуна-фронтендера, его посадили на проект, который уже пишется два года с использованием современного фреймворка Angular версии 1.5. Мальчик Коля не работал с ним, но он увидел знакомый знак доллара, а он уже успел написать пару плагинов для jQuery. Этот факт ободрил Николая, но потом старшие товарищи рассказали ему, что это — совсем не jQuery, и, вообще, тут надо директиву написать, а вот тут два фильтра надо сделать. Николай подавлен, но твердо намерен влиться в этот проект.

    И вот уже пролетел год, Николай мастерски пишет директивы и не проходит и дня без нового модуля. Коля на коне, оптимизма ему прибавляет тот факт, что полгода назад к нему на проект подсадили молодого джуна, а тот даже не знает, что такое директива. Щенок! Николай подружился со старшими товарищами, и только 30-летний старик в углу вечно чем-то недоволен.

    image
    Собственно, на графиках мы видим технические навыки для проекта и все скилы Николая, что у него есть. Поскольку это его первый проект, то по факту это все, что знает Николай. Через некоторое время он идет к начальству и просит два мешка денег — ведь он мастерски создаёт директивы на проекте, и вообще, он посчитал, что в два раза больше оставляет комментариев в MR, чем тот 30-летний старик. Очевидно, что он — лучше своего тимлида. На это получает вполне резонный отказ и начинает искать новую работу, возможно задумывается о переходе на другой проект или в другую команду. В любом случае он сталкивается с ситуацией, когда только что полученные знания становятся уже неактуальными и ему надо учиться дальше.

    image
    Это — первый кризис Николая «Эффект первого проекта».

    На новом месте Николаю дают проект на Ангуляре 5, ну он же мастерски пишет директивы! Но там он видит какую-то дичь! Какой ещё TypeScript? Какой RxJs и потоки? Старшие товарищи смеются над ним, а 30-летний старик кидает недобрые взгляды. Я видел огромное количество таких звёздочек и очень много звездопада, когда разработчик понимал, что оказывается-то он ничего ещё не знает! И чем раньше это произойдет, тем лучше. Это называется Эффектом Даннинга — Крюгера — метакогнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации.

    imageДжун, который сменил 3-4 проекта за год, для работодателя намного предпочтительней джуна, который год сидел в одиночку на одном проекте, потому что он:

    • Объективно оценивает свои знания и навыки
    • Постоянно развивается
    • Больше общается в коллективе
    • Больше понимает цену ошибки, потому что он видел больше дедлайнов и релизов

    Коллегам, которые оказались на этом этапе, хочется пожелать следующего:

    • Не унывать при неудачах
    • Постоянно учиться и осваивать новые библиотеки и технологии
    • Не звездиться

    Junior → Middle → Senior


    Ну вот прошло еще пару лет и что же мы видим?

    imageНиколай уже освоил несколько фреймворков и понял, что фреймворки — это только инструмент для решения конкретных задач. Он смирился с тем, что знает не все, но при этом старается все время развиваться. В какой-то момент он подходит к молодому 33—летнему тимлиду и говорит: слушай, Петя (имя изменено), вон к нам пришло несколько джунов, они ничего не знают и медленно делают задачи на проекте. Давай я им проведу несколько лекций или мастер-классов для того, чтобы они быстрее влились в нашу работу. И именно в этот момент Николай переходит на следующий уровень.

    Сейчас существует разделение на Junior, Middle, Senior. Мидл думает, что для того чтобы стать Синьором, ему надо освоить новый язык программирования и подтянуть матчасть. Это не совсем так. На заре отечественной разработки была должность аналогичная Синьору, называлась она Ведущий программист — такой специалист не просто много знает, но и еще ведет проекты или коллектив. Без соответствующих софт скиллз Синьором не стать.

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

    На этом этапе возможно два пути: быть простым исполнителем, не напрягаться и решать поставленные задачи; второй — развиваться в направлении ведущего программиста, брать на себя ответственность и инициативу.

    На этом этапе развития программиста команда и руководство ценят такие его качества:

    • Ответственность
    • Надежность
    • Коммуникабельность
    • Проактивность

    Куда стоит развиваться?

    • Углубленное понимание технологий, которые он использует
    • Расширение кругозора
    • Брать на себя ответственность за проекты и людей

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

    Кризис технологии


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

    image
    Тут есть три выхода:

    1. Переучиваться под новый стек
    2. Становиться лучше в старом и хвататься за последние заказы. Тот же Delphi все ещё востребован в узких кругах с огромным количеством legacy кода
    3. Уходить в менеджмент при наличии соответствующих навыков

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

    TeamLead. Кризис возраста


    Ну вот, Николай сменил стек технологий, и вроде бы все хорошо, но мы видим, что новые навыки даются все медленнее, а подрастающее поколение схватывает все быстрее.

    image
    Вот тут наступает последний кризис — кризис возраста.

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

    Какие тут могут быть варианты:

    • Если ты работаешь в продуктовой компании, то, наверное, это для тебя не так критично, и можно оставить все как есть
    • Уйти в обучение, например, стать консультантом, архитектором и т.д.
    • Таки уйти в менеджмент

    Перейдем к кривым


    Удовлетворенность. Она не может быть всегда на высоте, качественные проекты попадаются не всегда, а идеальную команду сложно подобрать и воспитать.

    image

    Я уверен, что, несмотря на падение удовлетворенности, надо всегда оставаться человеком. Я говорю о том, что если горят сроки на проекте и все бегают в мыле, то лишняя нервозность делу не поможет. Команде будет намного комфортней работать с людьми, которые не подведут в критические моменты.

    Технические скилы относительно быстро приобретаются и ещё быстрее забываются и устаревают, если посмотреть со стороны.

    image
    Получается, что программист имеет свой пик развития, а потом начинает «стареть», и в какой-то момент ему пора уходить на пенсию?

    И да и нет. На самом деле, вместо одного графика можно нарисовать 3 (опять же IMHO, как и значения).

    image
    • tech skills — это знания именно в технологии, языке программирования, фреймворке. Вы помните, что я ранее писал о том, что тимлид начинает меньше писать код и больше управлять? Эти скилы имеют свой пик именно в момент наибольшей востребованности специалиста в роли кодера.
    • hard skills — это совокупность знаний и опыта разработчика, со временем рост их снижается по той причине, что старые знания уже устаревают и становятся не востребованы, но остается полезен из них именно сухой остаток.
    • soft skills — это именно те личностные качества, которые нельзя посчитать, но которые надо развивать. Это качества, которые важны всегда, но в разной степени даны всем от рождения.

    Но давайте добавим еще один график
    value = (0,5*tech + 1*hard + 1,5*soft)/3
    

    image
    В третий раз повторюсь, что это лично моя формула, а коэффициенты я вывел за более чем 10 лет профессиональной деятельности в области разработки.
    Зеленый график отражает совокупность всех качеств специалиста, и это является его итоговой ценностью.

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

    Поэтому же HR-ы в компаниях проводят отсев кандидатов в том числе по софт скилам еще до проведения технического собеседования. Токсичный сотрудник может принести больше вреда компании, нежели технически слабый. Да и если технически слабый сотрудник принес вред, то это скорее вина его руководителя. Есть золотое правило: давай задачи по силам, а если хочешь, чтобы человек подрос, то немного сложнее (именно немного, а не в виде неподъемной ноши).

    2 варианта развития программиста


    Я описывал вариант, когда разработчик двигается по следующему пути:

    Junior → Middle → Senior → TeamLead? → Project manager? → Head Of * → Chief * Officer

    Но что делать если это не получается или не надо?
    Та же самая формула работает и в случае, если вы хотите развивать свои софт скиллз и становиться менеджером: можно развивать технические скиллы и быть востребованным специалистом без необходимости двигаться в сторону менеджмента. Но тут надо понимать, что технические скилы имеют свойство устаревания: сегодня ты отличный программист на Фортране, а завтра ты уже никому не нужен.

    image

    TechLead vs TeamLead



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

    TeamLead (вариант 1 из предыдущей главы) — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин:
    1. Он ближе к разработчикам и может их адекватно оценивать
    2. Разработчики к нему относятся лучше, чем к проектному менеджеру
    3. Можно убрать из проекта или снизить участие проектного менеджера (а он не приносит прямого дохода)
    4. Он может общаться с клиентом с точки зрения бизнеса, а не технологий.
    5. Совмещает в себе роли TechLead и PM

    TechLead (вариант 2 из предыдущей главы) — технический специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли.
    Почему конкретный человек — именно TechLead, а не TeamLead:
    1. Он может быть технически очень сильным, и отвлекать его не стоит, например, может участвовать в большем количестве проектов
    2. Он — интроверт или мизантроп, ему очень сложно общаться с людьми, а им — с ним
    3. Он очень сильно любит программировать, и управленческие задачи ему не интересны
    4. PM не хочет делиться с ним обязанностями
    5. В компании нет необходимости в TeamLead, и больше требуются технические специалисты

    Грамотный руководитель, при наличии необходимости как в тимлидах, так и техлидах, выберет правильную должность конкретному сотруднику (ну или постарается), тем самым сделав взаимовыгодное сотрудничество более качественным для обеих сторон.

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

    Заключение


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

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

    Плохие варианты, которые не дадут хороших результатов:

    • Я хочу стать ПМом, потому что люблю власть, да и они ничего не делают
    • Я хочу стать ПМом, потому что я не востребован в качестве разработчика, а есть вакансия ПМа
    • Я не хочу быть ПМом, но руководство заставляет
    • Я мастерски пишу директивы и готов уже руководить командой разработчиков

    Если вам не нравится или не получается менеджерить, но вас заставляет руководитель, то лучше сразу ему об этом сказать, а не пересиливать себя, а потом в какой-то момент сорваться и «улететь кодить на Бали». Помните: если вам нравится писать код, а не руководить, то и пишите его.

    Если же вы не можете/не хотите уйти в менеджеры, но при этом просто программировать вам уже не интересно, то можно рассмотреть вариант перехода в коучи: продавать свои услуги архитектора, вести свои курсы и т.д.

    Если же вам хочется и нравится руководить командой разработчиков, то стоит двигаться в этом направлении и стремиться искоренять из себя разработчика — это самое сложное. Надо стараться делегировать задачи, а не делать их самому. Кстати, рекомендую отличную книгу Как пасти котов, в которой собраны советы программистам, которые хотят стать руководителями.

    Lodoss Team

    59,00

    Сложные системы, мобильные приложения, дизайн и AR

    Поделиться публикацией
    Комментарии 180
      +3
      Я не совсем согласен с графиком для tech-skills, возможно я еще слишком мало проработал, но на мой взгляд на 90% эти навыки состоят из базовых знаний и навыков (системное, логическое мышление, навыки декомпозиции, навыки самообучения, навыки решения задач, понимания задач, математика, алгоритмы, предметная область), а конкретный стек технологий скорее как надстройка над этим.
        0
        Без опыта с конкретным стеком технологий применять все эти базовые знания и навыки очень «неуютно». Так что 10% это вы маловато выдали.

        Кроме того специфика профессии в том что действительно красивые и интересные задачи попадаются крайне редко (и не тебе!). А применять системное и логическое мышление в задачах вида «выведи там окошечко, там цифру из той ячейки, а когда пользователь нажмет 'ок', значение положи вот в ту табличку» — крайне не простое занятие:-)
          +6
          Тут есть один нюанс: В классическом разделении есть только soft-skills и hard-skills.
          Я же разделил hard-skills на 2 части
          • hard-skills — это фундаментальные знания и опыт
          • tech-skills — это знания именно в конкретной технологии, надстройка, как вы говорите

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

          Если выучить веб фреймворк, то технические знания увеличатся, но если при этом не разбираться в его работе, на задумываться о безопасности, и.т.д. то `hard-skills` будут минимальными.

          Если взять формулу, то получится примерно следующее
          value = ( 0.5 * <знание фреймворка> + 1,0 * <знание принципов программирования> + 1,5 * <умение работать в коллективе>) / 3
            +3
            Поддерживаю!
            Потому что у автора скилсы получается как в известном анекдоте:
            — вы имеете опыт работы с американским махгони?
            — я столяр и умею работать с любым деревом, включая красное дерево
            — нас интересует, есть ли у вас опыт работы именно с американским махгони, весь остальной ваш опыт нас не интересует!

            Заголовок спойлера
            американский махгони — сорт красного дерева, но собседующий в этом ничего не смыслит


            ВЫВОД: аффтар — гуманитрий-менеджер, а возможно даже кадровик, совсем ничего не смыслящий в IT!
              0
              Ну кстати, анекдот-то, если вдуматься, не совсем и анекдот. Человеку задали четкий вопрос — «Имеете ли вы опыт с фреймворком Х?»
              А он отвечает не на заданный вопрос, а на абсолютно левый — «Я умею работать с ЛЮБЫМ фреймворком.»

              Во-первых, «умею» != «есть опыт» (грань тонкая, но есть), во-вторых, меня не интересуют любые фреймворки, иначе я бы так и спросил, я спросил конкретно про фреймворк Х и жду ответа конкретно про него.
                0
                Суть в том, что незнание конкретного фреймворка не аннулирует весь прошлый опыт работы с похожими фреймворками.

                А у RomanKu по его формулировкам в статье — получается, что джуниор погода назад освоивший фреймворк «круче по hard-skills», чем тот кто с этой Джавой уже 15 лет работает, но именно с этим конкретным фреймворком не работал.
                  –4
                  Суть в том, что незнание конкретного фреймворка не аннулирует весь прошлый опыт работы с похожими фреймворками.


                  Если в работе нужен конкретный фреймворк — то до опыта в других фреймворках мне нет дела, поэтому и был задан конкретный вопрос, на который следовало ответить четко и ясно, а не растекаться по древу «а я и на машинке умею, и вышивать тоже».
                    –3
                    Значит ты гуманитарий ничего в IT не смыслящий. Потому что подойдёт и просто похожий по концепции фреймворк.
                    «а я и на машинке умею, и вышивать тоже»

                    Столяр ответил, что умеет работать с красным деревом, а «американский махгони» — всего лишь конкретная разновидность красного дерева.
                      –1
                      Значит ты гуманитарий ничего в IT не смыслящий


                      Удивительно, как я умудрился получить почти двадцать лет стажа в ICT.

                      Потому что подойдёт и просто похожий по концепции фреймворк.


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

                      Столяр ответил, что умеет работать с красным деревом


                      Его не об этом спрашивали.
                        –1
                        похожих по концепции не надо, надо конкретный вот этот вот, на котором у меня всё построено. Мне не нужно, чтобы человек разбирался, чем то, что он знает, отличается от того, что есть у меня — я не на обучение его беру, а на работу.

                        Похожий по концепции возможно быстро освоить — вплоть до того, что может являться возможным написать на нём что-нибудь вразумительное в первый же день.
                        Не обязательно иметь опыт работы на MicroSoft SQL, чтобы писать на нём зная Oracle PL/SQL, и обратное — тоже верно.
                        Столяр ответил, что умеет работать с красным деревом
                        Его не об этом спрашивали.
                        Его спросили про «американский махгони», а это — разновидность красного дерева.
                        Удивительно, как я умудрился получить почти двадцать лет стажа в ICT.

                        «Видно льва по когтям» ©
                        То есть, в вашем случае не видно, что вы — разбираетесь в этом.
                          –2
                          Похожий по концепции возможно быстро освоить


                          Да, только как я уже написал, мне не нужно, чтобы он осваивал, мне нужно, чтобы он писал.

                          Его спросили про «американский махгони»


                          Ну так и отвечал бы про махАгони.
                            –1
                            мне не нужно, чтобы он осваивал, мне нужно, чтобы он писал

                            Если достаточно похож — писать можно в первый же день. Пример с разными версиями SQL я уже привёл.
                            Его спросили про «американский махгони"
                            Ну так и отвечал бы про махАгони.

                            Махагони — это красное дерево, его конкретная разновидность.
                              +1
                              Удачи ему, когда он, умеючи в mysql, попытается понять, почему его удаленный клиент не цепляется к постгресу. Про pg_hba он, конечно же, не слышал.

                              p.s. безотносительно джунов, баз данных и всего такого. Я терпеть не могу людей, которые отвечают не на поставленный вопрос, а на тот, который выдумали сами себе из головы и считают, что так и надо.
                                –1
                                С любой подобной особенностью — можно разобраться меньше чем за день.
                                Вам — чашечки или ехать? Вам нужно, чтобы он писал, или не это нужно?
                                  –1
                                  Мне нужно, чтобы он писал, а не «разбирался за день».
                                  Хотяяяя… он же джун. Тогда да, возможно мне просто нужен мидл. Нанимая джуна — будь готов к тому, что он будет сравнивать, познавать и разбираться. Плох тот джун, который не хочет стать сеньором :)

                                  Но при прочих равных, даже нанимая джуна, на джуновскую позицию, я бы однозначно взял того, который ответил бы честно — «Нет, я не знаю этого фреймворка, но горю желанием разобраться», нежели того, который ответил бы «Да я все фреймворки знаю, чё там — они одинаковые же!».
                                    +6
                                    Простите за прямоту, но ваши ответы показывают что вы либо фантазер-максималист, совершенно оторванный от реалий индустрии, либо у вас какой-то уж очень специфический опыт.
                                    Компании дерутся за адекватных обучаемых людей, прекрасно понимая что конкретный фреймворк или технология совершенно вторичны и легко осваиваются (плюс в крупных как правило все равно все свое), и грамотно инвестированные в человека пара недель-месяц на старте потом с лихвой окупятся.
                                    А с вашей позицией я смутно представляю себе как можно кого-то вменяемого нанять.
                                      0
                                      вы либо фантазер-максималист, совершенно оторванный от реалий индустрии, либо у вас какой-то уж очень специфический опыт.


                                      Все проще. Я, признаться, был несколько невнимателен и упустил слово «джун». Да, разумеется, нанимая джуна, будь готов к тому, что он какое-то время будет курить мануалы.
                                      +2
                                      Вот не пойму, то ли среди разработчиков за вас конкуренция дикая, то ли вы что то не договариваете. Наша компания готова людей с любого стека брать, лишь бы показал что умеет программировать и обучаться достаточно быстро и качественно, и то дикая нехватка людей и вакансии постоянно висят.
                                      +1
                                      С любой подобной особенностью — можно разобраться меньше чем за день.
                                      Если Вам до 30, у Вас голова параллельно не забита уймой других проблем (допустим, личного характера) и вообще Вы обучаемы — да. В противном случае — по разному бывает.
                                        0
                                        Если человек имеет опыт изучения фреймоворков — то он да обучаем.
                                          0
                                          Та любой челевек обучаем, вопрос в том, насколько быстро это происходит.
                              0
                              А когда проект на этом фреймворке закончится, вы его уволите?
                                0
                                Ну совсем нет же. Во-первых, проект может быть ОЧЕНЬ долгим. Во-вторых, он может научиться чему-то еще (абсолютно добровольно, из интереса) и сможет взять и другие проекты.
                                Увольнять людей вообще плохая политика, особенно, если они не косячили, а работали честно.
                                  0
                                  Ну, на мой взгляд, синиор с кучей опыта в куче разных фреймворков за спиной, этим доказал, что учиться чему-то ещё он может хорошо и эффективно, а про джуна это ещё не так очевидно.
                                    –2
                                    Согласен, но главное, как я уже писал выше — чтобы он отвечал честно.
                                      +2
                                      … и за эту честность вы JC_IIB — незамедлительно накажете отказом!

                                      Судя по вашим рассуждениям вы JC_IIB — сами код никогда серьёзно не писали и никогда ничему не самообучались.
                                      Если вы не врёте, что работаете в IT — то вы явно начали свою работу сразу в качестве самодура-менеджера, и продолжаете вашу ТОКСИЧНУЮ деятельность уже десяток лет.
                                        –2
                                        … и за эту честность вы JC_IIB — незамедлительно накажете отказом!


                                        Ну, если я такой «самодур-менеджер, никогда не самообучавшийся и не писавший код» (а утверждение это абсолютно несостоятельно, ни целиком, ни в какой-либо его части) — то мой отказ это не наказание, кто ж захочет с таким мной работать? :)

                                        Повторюсь, у меня из внимания выскользнуло то, что вакансия-то джуновская. Так что никакой токсичности, сплошное недопонимание.

                                        Справедливости ради скажу, что слово «джун» появилось в рассуждении позже, в исходном «анекдоте», из-за которого разгорелся весь сыр-бор — слова «джун» нет, вообще неясно, на какую позицию нанимается человек.

                                        Между тем, есть замечательная тактика. Если тебе отвечают не на тот вопрос, который ты задал — повтори его слово в слово. Два, три, восемь раз. Пока человек не ответит тебе то, что хочешь знать ты, а не то, что он тебе рассказывает. Работает, рекомендую.
                                          +1
                                          Слово «джун» появилось после ваших слов об отказе от опытного разработчику не знающего конкретный фреймворк, зная похожие.
                                          Из ваших слов вытекает, что вы вместо опытного разработчика предпочтёте взять джуна, если джун знает именно это фреймворк.
                                            0
                                            Слово «джун» появилось после ваших слов об отказе от опытного разработчику не знающего конкретный фреймворк, зная похожие.


                                            Я честно несколько раз перечитал эту фразу. Может, ее как-то переформулировать? Особенно, если учесть, что слово «джун» появилось в вашем комментарии в данной ветке.

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


                                            Это зависит еще от ряда факторов, не только от «джун, знающий фреймворк — миддл, фреймворк не знающий».
                                              0
                                              Я и говорю, что спросил про джуна, после ваших слов, от том что вы откажете мидлу не знающего именно этот конкретный фреймворк, но работавшего с похожими фреймворками.
                                                0
                                                Я же говорю — зависит от ситуации. Если мы неспешно пилим MVP — добро пожаловать, а если надо вот прям щас садиться и спасать мир… не знаю, что хуже — искать компетентного человека или ждать, пока мидл выучит нужный фреймворк.
                                                  0
                                                  Если бюджет под позицию ограничен, не выше среднего по рынку, то искать человека в точности знающего ваш стек, можно очень долго. Скорее правильней будет взять того, кто какую-то его часть не знает с надеждой, что изучит в работе.
                                                    0
                                                    Если вот прямо сейчас (даже не через неделю) надо садиться и спасать мир, то поздравляю — вы некомпетентны как менеджер
                                                      0
                                                      А если произошла беда, авария, катастрофа?
                                                        0
                                                        Тем более. Вы должны были выстроить процесс так чтобы они (беды, катастрофы) не случались. И уж точно случайный программист с улицы не будет в силах взять и разрулить всё «вотпрямщас».
                                                          0
                                                          Я не случайно употребил слово «катастрофа». Бывает форс-мажор, обстоятельства непреодолимой силы.

                                                          И уж точно случайный программист с улицы не будет в силах взять и разрулить всё «вотпрямщас».


                                                          О чем я и говорю.
                                                            0
                                                            Нет, если у вас действительно ситуация что можно найти человека на том же стеке почти моментально, и при этом в проекты можно вникнуть так же быстро — то возможно вам этот вариант и подходит. В ином же случае есть подозрения (и судя по всему не у меня одного), что грамотный мидл которого нашли уже сейчас принесет больше пользы чем специалист на том же стеке (да еще и в целом навыками не ниже чем тот же грамотный мидл с другого стека которого мы не взяли) которого не удается найти.
                                                            А по поводу катастроф — обычно фактор автобуса же все таки стараются минимизировать. Не могу представить другой катастрофы которая бы решалась именно экстренным поиском разработчика.
                                                              +1
                                                              Так как вы собираетесь решать катастрофу вида «автобус с разработчиками ехавшими на тимбилдинг упал в пропасть»?
                                                              Лично мне кажется что останется лишь смириться с тем что разработка станет колом на какое-то время и искать не человека который работал с в точности таким стеком, а с человеком способным въехать в ваш проект, с достаточным опытом в разных фреймворках и проектах. И уж тут точно не стоит нанимать джунов первое время.
                                                              А говорить синьор программисту — «извини чувак, меня не колышет что ты работал с похожими фреймворками, меня интересует конкретно этот» — это как-то даже проявить неуважение и таким образом сказать «извини, я совершенно не верю в то что программисты способны обучаться и въезжать в технологии, поэтому мне нужен человек который будет в точности знать именно наш стек, а то что ему надо быстро въезжать в наш проект, так это просто мои тараканы в голове договориться не могут».
                                                              Не говоря о том, что если случилась именно катастрофа, то тут уже не приходится долго и нудно перебирать, надо брать первых попавшихся адекватных.
                                    +3
                                    Удивительно, как я умудрился получить почти двадцать лет стажа в ICT.

                                    Да я вообще всегда когда комменты на хабре читаю, себя каким-то конченным дауном чувствую.
                                    +2

                                    "умеет" != "имеет опыт"
                                    В соответствии с означенным эффектом Даннинга-Крюгера столяр (джун-программист) может быть совершенно уверен, что он справится с красным деревом (последним ангуляром), вот только опыта такой работы у него не было. Только сосна, только php.

                                      0

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

                                        0
                                        В соответствии с означенным эффектом Даннинга-Крюгера столяр (джун-программист) может быть совершенно уверен, что он справится с красным деревом (последним ангуляром), вот только опыта такой работы у него не было


                                        О чем я и говорю. Человек (джун, не джун — неважно!) на собеседовании может брякнуть что-то типа «Да че там, эти фреймворки все одинаковые!», а потом внезапно обнаружить, что они разные.
                                        Тут будет куда более уместен ответ — «Нет, я не знаю этот фреймворк, но я готов учиться». И, в зависимости от состояния проекта, кандидат вполне может быть принят с таким ответом.

                                        p.s. я пробовал работать с хвойной фанерой ФСФ. Та еще развлекуха, доложу я вам.
                                        0
                                        Если там есть особенности (типа неравномерностей, а цена велика и не зная этого на первых работах можно запороть несколько дорогих заготовок), то опыт работы с аналогами не поможет. Возможно, работодатель хочет просто учесть риски.
                                        0
                                        Т.е. (реальный пример, хотя и не со мной) приходит к вам человек и вы его спрашивате:
                                        — Вы работали с Git?
                                        — Нет, но я работал с Mercurial
                                        — Извините, но вы нам не подходите.

                                        Что резко выдаёт уровень вашей квалификации как собеседующего. С тем же успехом можно просто фильтры выставить, будет на 2 порядка эффективнее.
                                    0
                                    Интересные выводы. Информацию об аффторе можно найти в интернетах (например, LI)
                                    • Высшее техническое — математик-программист
                                    • 10 лет работы в качестве программиста


                                    Никогда не считал себя гуманитарием
                                0
                                А по поводу
                                Джун, который сменил 3-4 проекта за год, для работодателя намного предпочтительней джуна, который год сидел в одиночку на одном проекте, потому что он:
                                Может кто-нибудь из серьезных бородатых тимлидов еще отписаться? Мне всегда казалось, что прыгание по проектам характеризует человека как неусидчивого\неуживчивого\туповатого(но это не точно), в целом, человека, на которого как раз нельзя положиться.
                                  0
                                  Кстати, да. Тоже очень подозрительным показалось.
                                  У меня знакомый был который как то 4 места работы за год сменил. Разгильдяй редкий.

                                  Так что джун-попрыгун скорее всего обладает какими то несовместимыми с нормальной работой дефектами.
                                  PS Тоже касается и людей которые просидели на одном стуле 10 лет.
                                    0
                                    Тоже касается и людей которые просидели на одном стуле 10 лет.

                                    Зависит от масштаба предприятия. В маленьком за 10 лет может не поменяться ничего.
                                    В большом несколько раз сменились технологии и оборудование.
                                    Возьмите сотовых операторов. 10 лет назад превалирующей технологией была 2G и звонки.
                                    Потом пошли 3G нескольких вариантов, LTE нескольких вариантов, уже тестируется 5G. Сотовики стали магистралами с соответствующим развитием пакетного транспорта. Пошли в ход бигдата и нейросети для анализа данных. Да много чего ещё. Да даже госконторы прошли путь от небольших сетей на тонком езернете, модемной связи и серверов на Netware до современных мплс сетей на всю страну, мощных кластеров с облачными сервисами и т.п.
                                      +2
                                      Мой опыт в разработке говорит скорее об обратном: небольшие предприятия менее инерционны в плане использования актуальных технологий. По крайней мере если говорить о небольших ИТ-компаниях или больших не ИТ-компаниях с своим отделом разработки. В больших же ИТ-компаниях очень часто в иерархии управления найдётся человек отказывающийся брать на себя риски обновления без очень сильной бизнес-нужды. В небольших компаниях гораздо чаще понимают, что актуальные технологии на проекте — это дополнительный способ мотивации разработчиков, гораздо более важный для многих чем печеньки и фитнес.
                                        0
                                        Речь не идёт об ИТ-гигантах, создающих массовые технологии.
                                      0
                                      Плохо смотрится когда часто меняешь работу, а не проекты!
                                      У меня в компании, например, за год в среднем проектов 4-5.
                                      Приходят какие-то доработки, например, и тебя просят сделать
                                      + поддержка своих 2-3 проектов или параллельно тебя продают еще в аренду =)
                                      В итоге, у меня почти за 5 лет около 20 проектов
                                        0
                                        У меня первая работа была неофициальная, сдельная с непонятной зарплатой, с кучей легаси, и в одиночку. Потом 3 месяца в веб-студии джуниором за 3 тыщи. Потом была работа относительно нормальная по региону (10-15), но через несколько месяцев предложили в соседнем городе с зарплатой в 2 раза выше. И параллельно еще разовый проект был на несколько месяцев. Это всё в течение года. Где я по-вашему должен был долго работать?)
                                          0
                                          Вероятно, мы говорим несколько про разные вещи.

                                          Если я в течении одного года поработаю в Газпроме, Сбербанке, Роснефти и ВТБ24 то безопасники и HR в, например, Альфа-банке у меня обязательно спросят почему я так прыгаю. И, очень вероятно, откажут.

                                          Но без сомнения можно выдумать (или привести) ситуацию в которой такое поведение не будет подозрительным, а напротив достойным всяческих похвал.
                                          0
                                          Интересно, а сидящий по 10-15 лет на одном месте какими именно «несовместимыми с нормальной работой дефектами» обладает?
                                            0
                                            Я таких видел.

                                            Понятно, что многое зависит от человека. Может он сидит на стуле где то «для виду», а сам ишачит фрилансом параллельно или перпендикулярно по совместительству.

                                            Но в общем случае человек(ИТ) который 10 лет работает на одном месте прекрасно знает именно ту область (и как правило достаточно узкую) в которой он «живет» уже 10 лет. И начисто не знает всего остального… Более того попытка выйти из зоны комфорта и узнать что то новое причиняет ему такое неудобство, что он будет сопротивляться чему то новому до последнего.

                                            Понятно, что если человек собрался просидеть на том же стуле еще 10 лет и уйти на пенсию то флаг ему в руки.
                                              0
                                              В общем случае мы не можем судить о том, что человек знает актуального кроме технологий на текущем месте, если он сидит на нём 10 лет. Может всё свободное время он активно развивается (не важно в ходе «халтур» или просто по зову души), а может и в своих текущих технологиях освоил необходимый минимум и всё.
                                                0
                                                Может. Да.

                                                Мой опыт говорит что нет. Может, но нет.

                                                Ужас не только в одних и тех же технологиях.
                                                Ужас еще в тех вот скилах о которых пишет автор поста.
                                                Например, человек привык(10 лет!), что он с клиентами не разговаривает.
                                                И не умеет этого делать. И учиться не хочет. И не будет.
                                                И все. И ты ему не объяснишь, что игра в испорченный телефон это плохо для проекта и работы может лишиться именно он. Ему пофиг. И 10 лет когда он шел по одним и тем же жизненно-рабочим шаблонам говорят ему что он прав. Но он не прав…
                                                  +1
                                                  Ммм… Если он не хочет — то ему лучше поискать другое место где это делать нужно по минимуму, а не подстраивать жизненные принципы. И нет, нежелание общаться с клиентами не говорит о том что человек не развивался/развивается.
                                                    0
                                                    Неумение общаться с клиентами это лишь пример.
                                                      0
                                                      Плохой пример, поскольку как о специалисте в тех сферах которые человеку интересны не говорит ни о чем.
                                                        0
                                                        Вы думаете что можно не уметь говорить с людьми (клиентами!) и быть хорошим ИТшником?
                                                          +2
                                                          Можно быть хорошим программистом и без этого. Во первых продуктовая разработка этого вообще не требует. Во вторых не приравнивайте «людей» и «клиентов», это все же разные множества, и мы говорим про человека который конкретно с клиентами не любит разговаривать. В третьих — разделение труда не зря придумали, с тех пор как это случилось человечество в целом стало заметно продуктивнее. В четвертых — есть вообще R&D где тоже с клиентами общаться не нужно. В пятых — с учетом дефицита кадров при прочих равных лучше взять человека который не любит общаться с клиентами и очень хорошо понимает в разработке отделив его менеджером или аналитиками от клиентов, чем суперкоммуникабельного человека который как разработчик почти никакой (понятно что есть вакансии где это прям нужно-нужно, но не думаю что их более 90% всех вакансий, скорее сильно меньше).
                                                          Все таки каждому свое, и лучше искать место где ты будешь максимально эффективен, чем выгорать на нелюбимой работе.
                                                            0
                                                            А вы на собеседование сами ходите? Или вместо вас менеджеры ходят?

                                                            Человек с плохим умением себя «продавать» как правило даже донести до предполагаемого работодателя не сможет какой он классный специалист.

                                                            Человек с низкими соц навыками вряд ли сможет успешно учиться у окружающих. Может он гений конечно и сам до всего дойдет, но… вряд ли.

                                                            Почему вы думаете что асоциальный затворник будет лучше прогать чем человек с нормальными соц навыками? Откуда такая вера в заросших свитерами чудаков?
                                                              0
                                                              Откуда у вас равенство между интровертами и людьми с низкими софт скилами? Насчет собеседований ничего сказать не могу, в моей жизни оно было одно, после которого меня и приняли, но если честно по навыкам я не проходил, прошел как раз из за софт скилов, и тому что показал себя как обучаемого человека.
                                                              Более того, сейчас я вот еще по сути являюсь полуархитектором/полунаставником/полуменеджером над парой вчерашних стажеров, как раз потому что у меня есть как тех. скилы, так и софт скилы. Но при всем этом (и все об этом в курсе) я интроверт, решать вопросы предпочитаю больше в почте, с клиентами предпочитаю общаться как можно меньше, как и с коллегами за пределами текущей группы (да и внутри если нет обсуждения интересного мне вопроса или мнение мое по производственному вопросу в целом с общим совпадает тоже активность не проявляю). Ну, если конечно нет производственной необходимости для обратного.
                                                              Да, софт скилы у меня конечно не идеальны, но вполне достаточны, и, по моим ощущениям, вовсе выше среднего. Хотя, повторюсь, я очень ярко выраженный интроверт в плане ментального комфорта и склада характера.
                                                                0
                                                                Хотя выше среднего все же маху дал, вполне на среднем уровне, в принципе в любую компанию влиться могу при желании и адаптироваться, но «душой компании» все же не стану.
                                                                  0
                                                                  Я тоже интроверт.

                                                                  Откуда у вас равенство между интровертами и асоциальными затворниками\людьми с низкими соц навыками?

                                                                    0
                                                                    Ну так это вы выстраиваете равенство (не хочет/не любит общаться с клиентами = не развивающийся человек с низкими софт скилами вредный для работы). При том что совершенно необязательно общаться с клиентами во многих случаях (изредка только, когда действительно нужно, это если клиенты в принципе есть), а коммуникация внутри команды это совсем не то же что общение с клиентами, и средних софт скилов (да даже ниже средних на самом деле) для хорошей работы вполне достаточно. И уж точно если у человека есть выбор — если у него нет большого желания к общению идти нужно туда где его количество будет меньше, а не подстраиваться под какие то вакансии к которым душа не лежит.
                                                                      0
                                                                      Я говорю об инертности мышления людей которые по 10 лет сидят на одном стуле.:)
                                                                      А вы почему то взяли один пример и пытаетесь «умять\ужать» все мое мнение до этого одного единственного примера.
                                                                        0
                                                                        Ну, собственно я как раз с примером и спорил, потому что он на мой взгляд неверен. Да и в целом, не придерживаюсь позиции что работ должно быть много, и уж точно не вижу ничего плохого если кто то сидел на одном месте и при этом развивался активно.
                                                                          0
                                                                          А вы часто видите этих людей которые сидят на одном месте и развиваются активно?
                                                                            0
                                                                            Не так уж редко. Не меньше чем каждый десятый наверно, скорее больше. Если мы про программистов.
                                                                              0
                                                                              Каждый 10ый это «не так уж редко»?!
                                                                              У нас с вами очень разная градация о «часто» и «редко»…

                                                                              Мне вот очень не хочется в 9 из 10 случаев получить такого коллегу. Или что гораздо хуже подчиненного.
                                                                                0
                                                                                Ну так никто не заставляет брать тех 9. Десятого на самом деле тоже не заставляет никто, но сам по себе факт сидения на одном месте не логично выставлять как безусловный фильтр на отсев.
                                                                                  0
                                                                                  Почему вы думаете что этих 9рых надо брать или не брать?:) Они ж на месте сидят и никуда и уходят;-)

                                                                                  Это скорее вы (ну или я) поменяете работу и придя в компанию обнаружите этих сидельцев в виде ваших коллег\подчиненных.

                                                                                  Безусловный фильтр выставлять не будем. Но тут какое дело… Принцип ленивых вычислений. Если оценивать\оглядывать каждого человека на планете в предмет нужности и ценности. Не обязательно как коллегу\сотрудника\подчиненного\начальника\тимлида. Но и например как подруги жизни или собутыльника. То… не хватит всей жизни. Поэтому используется так не любимое многими (в первую очередь теми кто получает «неприятный» ярлык) «навешивание ярлыков».

                                                                                  Ярлыки позволяют не тратить в каждом случае месяцы и годы жизни на одного человека, а быстро по ряду признакам его забраковать. Или напротив(!) прийти к выводу что данный кандидат весьма перспективен.

                                                                                  Конкретно данный ярлык-фильтр вам без сомнения не нравится. Вы попадаете по нему в отрицательный «отсев». Повод задуматься. Как минимум можно поинтересоваться у знакомых HRов что они на эту тему думают.
                                                                                    0
                                                                                    Я по нему не попадаю и вряд ли когда попаду, отработал 4-й год только что, и думаю не то что о смене места, а о смене стэка в течении следующих года-двух. Тем не менее мне в принципе не нравятся ярлыки, на мой взгляд важнее всегда оценивать конкретного человека с которым приходится пересечься с минимумом ярлыков.
                                                                                      0
                                                                                      Как было бы прекрасно если б можно было оценить каждого подробно и беспристрастно:)
                                                                                      Где бы время и силы на это взять.
                                                              0
                                                              Поставьте «уборщицей», «электриком», «краснодеревщиком». Если это не ИП, который сам ищет клиентов, то вполне может быть хорошим специалистом в _своей_ области.
                                                                0
                                                                Может. Может быть. А может и не быть.
                                                                На самом деле если он уборщик он вообще может быть немым и писать\читать не уметь. И мыть пол будет хорошо.

                                                                Программирование как и другое ИТ гораздо больше требует коммуникаций между людьми. Сложный программный продукт немыслим без совместной работы многих людей. И думать что их можно рассадить по каморкам, общаться будут менагеры (которые будем честными ничерта не понимают в тех стороне вопроса) как то… поверхностно.
                                                                  0
                                                                  В действительно большом проекте как раз не надо всем общаться с заказчиком, это должен делать аналитик (не манагер), который превращает хотелки в чёткое и однозначное ТЗ. «Приходите все общаться» — это уже бардак.
                                                                    0
                                                                    Не надо всем общаться с заказчиком. А вот с коллегами придется.
                                                                      0
                                                                      Начинали вы с общения с «людьми (клиентами)» и, вероятно, под «не умеет общаться» имели в виду «не имеет навыков эффективного делового общения с клиентами». Мне сложно представить человека, который вообще не умеет общаться с людьми, разве что Маугли какой-то.
                                                                        0
                                                                        Видимо плохо я донес мысль.
                                                                        Я «начинал» с инертности мышления.
                                                                        И про нежелание (вплодь до совершенно агрессивной реакции) делать что то новое.

                                                                        А неумение и нежелание общения с клиентами лишь пример из личной практики.

                                                                        «не имеет навыков эффективного делового общения с клиентами» — поверьте, я имел ввиду отнють не такую высоту. :)

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

                                                                          А какую высоту имели в виду? Вот прямой отказ «я с ними разговаривать не буду»? Или отказ клиентов разговаривать с ним после первого разговора?
                                                                            0
                                                                            У вас в компании все всегда делается идеально?:) В других тоже нет.

                                                                            Представьте, что клиенту навешали на уши лапши про, к примеру, круглосуточную поддержку. И ваш менеджмент, разумеется, нашел способ сэкономить.
                                                                            Проще говоря не нанимать дополнительных людей, а понадеяться на «авось». Что ничего критичного ночью не произойдет, а если произойдет то… как нибудь выкрутимся. :)
                                                                            Ночью происходит серьезная проблема. Система мониторинга о ней сообщает..., но все спят:)
                                                                            Утром же ваш подчиненный (он прекрасно знает про «круглосуточную поддержку» и прекрасно знает что ее нет!) пока вы отходили в туалет\за булочкой\еще куда то в ответ на требование начальства:
                                                                            — Срочно ответь клиенту!
                                                                            — Ну тимлида ж нет… он с клиентом разговаривает, а я нет!
                                                                            — Ответь! Тим лид придет свое получит!
                                                                            Пишет хамоватое письмо примерно следующего смысла:
                                                                            «Мониторинг у нас есть, но проблема произошла ночью и все спали. Поэтому починили только в 9-15 когда начался рабочий день.»

                                                                            Из чего заказчик понимает что с круглосуточной поддержкой его кинули:-) Кинули на деньги. А в копии стоял серьезный менеджмент заказчика который эти деньги и выделял…

                                                                            Объяснять этому человечку который «не разговаривает с клиентами», что в результате его письма проект могут закрыть и он сам же вылетит на улицу бесполезно. Для него все равно виноват будет начальник который «заставил ответить» и ты потому что «вот сам бы и отвечал, а не шлялся непойми где».
                                                                              0
                                                                              Я бы не назвал это простым неумением программиста общаться с людьми(клиентами). Это как раз отсутствие навыков эффективного делового общения. Клиент, я думаю, даже благодарен будет получив такое письмо а не «наши лучшие архитекторы работали всю ночь и к 9-15 проблему устранили». Кстати, ничего хамоватого я не вижу.
                                                                                0
                                                                                Ох, как будет благодарен клиент узнав, что его кинули на деньги:) А как этому рад менеджмент подрядчика:)

                                                                                По хамоватости тут у каждого свои понятия. Кто то и деловую переписку считает нормальным открывать «здароф, мужики!»
                                                                                  0
                                                                                  Клиент будет благодарен человеку, сообщившему что его кидают на деньги. Лучше поздно, чем никогда.
                                                                                  0
                                                                                  Ребята, не надо переходить в плоскость общения с заказчиком. В большинстве нормальных компаний для этого есть специально обученные люди. А вот общение с коллегами никто не отменял. Примеры: человек свою работу делает, как одолжение — ты его просишь что-то сделать, а он это преподносит, как будто ты должен будешь ему до конца жизни; не воспринимает критику в свой адрес, вместо принятия жалуется всем на того, кто критикует или спорит; перекладывает ответственность или прикрывает свою пятую точку; строит из себя всезнайку и на вопросы отвечает не как более опытный товарищ, а как бог всея с г**ом. Да много примеров можно привести, но результат, как правило, один: взаимодействия с подобными людьми стараются избегать, а важные задачи не давать.
                                                                                    0
                                                                                    Ну так в ветке именно общение с заказчиком изначально обсуждалось как пример минусов человека который на одном месте десять лет сидит.
                                                                                  0

                                                                                  Как у вас интересно получается. Менеджеры обманули клиента, а виноват программист. Да еще и оказывается он из-за этого не является "хорошим ИТшником". При этом не он принимал решение об обмане и не он принимал решение об ответе. Почему, собственно, начальство не может ответить клиенту, раз уж он такой важный? Почему нельзя подождать того, кто обычно "с клиентом разговаривает"? Всю ночь значит ждали, а тут вдруг несколько минут что-то решат. Почему нельзя явно сказать "Напиши то-то и то-то", раз уж всем остальным лень разгребать последствия своих интриг?
                                                                                  Еще один повод отказываться от общения с клиентами — фиг его знает что им менеджеры наплели.

                                                  +2
                                                  Это достойно отдельной статьи и обсуждения.
                                                  Если он меняет компании и проекты потому, что не может нормально работать, то это один вопрос, но если ему дали 1-2 мелких проекта (например он + более опытный напарник) и он их выполнил, потом до полугода его подсадили на крупный и долгий проект для помощи и роста + ему подкинули внутреннюю штуку сделать, то тут уже совершенно другой разговор идет.
                                                    +2
                                                    Отписываюсь.

                                                    Проектов != рабочих мест. 3 проекта за год = 4 месяца на проект.

                                                    Т.е. если в компании, где работает джун большая текучка проектов, он неусидчивый\неуживчивый\туповатый?
                                                      +2
                                                      Как же я далек от народа. Я привык, что за 4 месяца хорошо если ТЗ согласуют хотя бы наполовину.
                                                        0
                                                        Проекты разных масштабов бывают. Например, экранов добавить, верстку поправить и т.д.
                                                          +3
                                                          А, тогда понял.

                                                          -исправил опечатку в окне «О программе».
                                                          -добавил выбор «г-н»\«г-жа» на экране регистрации
                                                          -добавил окно с надписью «Спасибо за визит» после нажатия на «крестик»

                                                          И в резюме можно писать еще три успешных проекта:)
                                                            +1
                                                            Не обязательно. Например бывают проекты вида «нужно быстро запилить какую-нибудь штуку для обработки заявок, интегрировать ее с системой1, системой2 и сделать API для системы3». 90% проекта 2 человека * 2 недели, срок жизни системы 1-2 года максимум.
                                                              +1
                                                              И уже мидл, переходящий в сеньеоры. Я даже и не припомню сколько народу ко мне приходило на собеседование с такими резюме
                                                            0
                                                            Вполне возможно что синьоры и мидлы подключились еще на стадии пресейла оценивая техническую часть по затратам и задавая вопросы по хотелкам юзера и это все длится несколько месяцев (те самые ваши 4 месяца на согласование), а вот когда все уже согласованно и надо писать конкретные маленькие кусочки подключают джунов. Также возможно что гарантийным багфиксингом тоже занимается синьор или мидл, а джуниора перекидывают на другой проект, вот и получается что джун на проекте 4 месяца, а более старшие товарищи год.
                                                            Хотя не могу не признать что за исключением чего-то типа Proof of concept проектов всего в 4 месяца активной разработки не припомню
                                                              +1
                                                              Этот сценарий мне тоже знаком.

                                                              Крутые сеньоры подрядчика полгода обсуждают детали проекта со спецами заказчика.
                                                              А когда все наконец согласовано вместо сеньоров приходят джуны которые не умеют ничего.
                                                              Денег за них заказчик платит как за сеньоров, конечно же.
                                                                0
                                                                Я имел в виду именно вариант без мошенничества когда джуниоры изначально согласованны и просто приступают к работе не сразу, но сценарий как у вас тоже возможен.
                                                                0
                                                                У меня есть проект, на реализацию которого ушло 50 дней де-факто и месяцев восемь календарно (т.к. это сайд-проект). Не самый тривиальный оптимизирующий компилятор для не самого тривиального языка. И это, пожалуй, одна из тех вещей, которыми можно гордиться по результату.

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


                                                                  Вспомнилось старенькое, но отличное :)
                                                                    0
                                                                    ASN.1 таки покруче будет :)
                                                                      0
                                                                      Валкин вообще какой-то демон, прости господи :) интересно, где он сейчас, что пишет…
                                                          0
                                                          Вопрос что за проект, есть большой Проект с большой буквы, но в него входят несколько (десяток+) самостоятельных и в меру независимых проектов со своими этапами и задачами, сроки на каждый — несколько месяцев (делаются частично параллельно), но кодинга там — недели на две-четыре на каждом (остальное — выработка и согласование ТЗ, оформление документации и оттчётов), нет смысла держать джуна на нём весь срок — подключили после готового ТЗ на этап работ, отключили после, перевели на следующий, подошедший к этапу реализации. Для него это два проекта (да и солиднее цифра 2, чем 1), «но мы-то знаем...»(Ц) о глобальности всего этого и можем сказать что проект один.
                                                          +1
                                                          А бывает история, прийдешь такой 35 летний в новый проект по переписыванию пхп на с#, а там сидят «старички» и косо смотрят, а могут и «съесть».
                                                            +3
                                                            Хорошая статья, хотя бы потому, что она не пушит обрыдлую идею «Программист, развивайся в управленца!».
                                                            Я знаю изрядно людей, которым тупо неинтересно быть управленцами, им это не надо, они сидят и пишут кот.
                                                              0
                                                              Не только программист. Есть куча других специализаций, работающие по которым не хотят быть управленцем. Вопрос в том, как искать работу, если работодатель схлопнется, а тебе 50 лет. И ты не Роб Пайк или типа того. И живёшь в провинции.
                                                                +1
                                                                Занимаясь набором людей и видя много проектов — в какой-то момент понимаешь, что 50+ -летние дядечки для некоторых проектов подходят сильно лучше молодёжи.
                                                                Более того, если человек в 50 лет продолжает развиваться — он скорее всего в принципе лучше любой молодёжи. Вижу такие примеры.
                                                                Ну и есть проекты, где «тупое легаси, надо просто поддерживать» — и человек, который уже спокойно строит дачу и имеет нужный скиллсет, подойдёт туда значительно лучше молодого парня, которому всё хочется переписать.
                                                                К сожалению, далеко не все работодатели это понимают.
                                                                  0
                                                                  человек, который уже спокойно строит дачу и имеет нужный скиллсет, подойдёт туда значительно лучше молодого парня, которому всё хочется переписать.


                                                                  Поддержу, скиллованный консерватор на этой позиции будет куда полезнее хипстера, потрясающего очередной bleeding egde hype-driven технологией. Потому, что если все работает, работает как надо и всех всё устраивает — не трогай.
                                                                    +5
                                                                    Проблема ещё в том, что переход из технаря в управленцы скорее всего закончится управленцем нижнего, в лучшем случае среднего звена. Которым жестоко, нещадно выносят мозги. Дорасти до топов не получится с большой вероятность. Там всё оккупировано управленцами, которые были сразу управленцами, с дипломами МБА и прочими управленческими регалиями.
                                                                    И не известно, что лучше, остаться технарём или стать управленцем нижнего звена, которому постоянно выносят мозг, постоянный стресс.
                                                                      +4
                                                                      Дорасти до топов не получится с большой вероятность.


                                                                      «У генералов свои дети есть» (С)
                                                                        +1
                                                                        Смотря чем стремиться управлять. «Ваши» управленцы настроены, по-моему, на управление людьми и(или) финпотоками и с удовольствием отдают управление техническими вещами техническими специалистами. Когда искал себе (как ведущий разработчик, нежелающий много времени тратить на управление людьми и рутинные задачи) тимлида или ПМа очень чётко резюме делились на две группы даже при одинаковом послужном списке: в одних акценты на численности команды, выстраивании процессов разработки, обычно scrum, успехах в мотивации и т. п., «продажах» бизнесу, а в других на технологиях, технических решениях бизнес-задач, количественных и качественных технических характеристиках проектов. И на собеседованиях первые с точностью до человека могли назвать сколько народу было в подчинении в любой день, какие бюджеты были у проектов, а другие список технологий и количество серверов.

                                                                        Субъективно отличаю первых от вторых по отношению к людям, деньгам и технике(включая софт): для одних объект управления деньги и люди, а техника — ресурсы, для других наоборот. Первые в целом метят на позиции CEO/CFO, вторые на архитекторов/CTO.
                                                                  +6
                                                                  Вывод для интроверта — без софт скиллов ты не нужен (тм). Вот тебе мылко и веревка.
                                                                    +2
                                                                    Я так понимаю, что вместе с этим комментарием прилетел и — в карму ;-)
                                                                    Интроверту искать проекты с минимальной коммуникацией и там, где софтскилы не так важны.
                                                                      0

                                                                      Я отдавал себе отчет о последствиях этой фразы. Тем более что я сам "из этих", пытавшийся работать менеджером, с эпик фейлом в конце. Пока решил, что могу обучать молодняк, так как хорошо умею обьяснять то, что понимаю сам. Но как представлю вот эти все бесконечные митинги и договоры, прям знобит.

                                                                        +2
                                                                        Из комментария следует, что заключение верно на все 100%: пересиливаешь себя — лучше сразу остановиться и не мучать себя. Не хочешь менеджерить и кодить — попробуй обучать.
                                                                          0
                                                                          Кодить хочу и люблю, но не всегда возможно — вырастаешь то в архитектора, то в лида, где надо следить за молодняком.
                                                                      +3
                                                                      Я думаю это ложный вывод. Быть интровертом вовсе не означает быть социопатом (и соответсвенно иметь очень низкий уровень soft skills). Интроверты тоже вполне способны развивать soft skills, разве что немного в другом направлении в отличии от экстравертов. Например, более менее известно, что интроверты гораздо более чуткие, и потому скорее всего смогут лучше осознать проблему подопечного разработчика и подобрать нужные слова, чем экстроверты. Интроверты предпочтут тет-а-тет комунникацию глобальному брейнштормингу и т. д.

                                                                      Другое дело, что в основом о soft skills приходится слышать как раз от экстравертов, потому что это их «тема». Вот и получается, что интраверты пытаются натянуть шкуру экстравертов в плане soft skills на себя и идут за мылом и веревкой.
                                                                        +8

                                                                        Кажется ты путаешь социофоба и социопата, последний вообще может вполне неплохие soft skills иметь, просто ему будет плевать на то, что случится с людьми вокруг него.


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

                                                                          +4
                                                                          А по поводу интровертов и их soft skills интересный взгляд есть в книге Девора Зак «Нетворкинг для интровертов» («Networking for People Who Hate Networking: A Field Guide for Introverts, the Overwhelmed, and the Underconnected» by Devora Zack в оригинале).
                                                                          Но вообще же разница между интровертами и экстравертами прежде всего в том, что вторые заряжаются при общении, а первые разряжаются
                                                                          Для себя нашел еще одну аналогию: люди — это усилители. Не даром ведь существует выражение «на одной волне с кем-то». Экстраверты — широкополосные усилители. У них большой рабочий диапазон частот, т.е. им легче с ходу найти общий язык со многими. Интроверты же — узкополосные усилители, они резонируют с определенными категориями людей. Но ширина полосы обратно пропорциональна возможному коэффициенту усиления. Интроверты способны на кратно большую интенсивность в общении на своих рабочих частотах (попробуйте остановить интроверта, который рассказывает Вам что-то, что ему действительно интересно). Т.е. нужно учиться перестраиваться в некоторых границах и искать окружения единомышленников. И отдыхать, восстанавливаться, конечно.
                                                                            +1
                                                                            Хз, я считаю себя интровертом, но либо эту категорию людей не нашел, либо ее не существует, либо вы не совсем правы. Мне в принципе комфортней быть одному, чем общаться с кем либо. И от общения на работе приходится отдыхать дома. Хотя со стороны это менее заметно, поскольку без общения решать рабочие задачи трудно, поэтому временами вполне интенсивно общаюсь.
                                                                              0
                                                                              «От общения на работе приходится отдыхать дома» — из этого не следует «мне в принципе комфортней быть одному, чем общаться с кем-либо». Просто у Вас среднедневное количество общения немного (или не немного, не знаю) превышает наиболее комфортное для Вас. Но фактическое количество общения может быть и ниже оптимального (даже для Вас), например, если Вы годик посидите дома, никуда особо не ходя. Хотя я не знаю, может быть лично для Вас оптимальное количество общения и 0, но я сомневаюсь, что оно ровно 0. По крайней мере, у меня не ровно нуль (причём за много лет жизни я привык к тому, что люди «мешают» и нужно всеми средствами «отвоёвывать» себе возможность от них отдыхать, так что, когда в какой-то момент количество фактического общения стало ниже количества оптимального, это стало некой неожиданностью (причём не очень приятной, потому что у меня не было привычек по поводу того, что стоит делать в такой ситуации, в отличие от противоположной)).
                                                                                0
                                                                                Ну вот недавно две недели отпуска брал от общения отдохнуть. Вообще ни с кем не общался голосом. На работе общения от 30 минут в день до пары часов, дома слава богу один живу и ни с кем не общаюсь.
                                                                                  0
                                                                                  Две недели — очень мало. За этот интервал Вы, наверное, даже и не ощутили этот режим как постоянный («всегда так будет»), а только наслаждались разнообразием (по сравнению с основным режимом). Хотя я не спорю, что у Вас может быть действительно нуль (или очень близко к 0).
                                                                                +1
                                                                                А зачем вы тут общаетесь? )
                                                                                  0
                                                                                  1) Узнать что то новое, что то спросить полезное.
                                                                                  2) Сдвинуть немного представления людей в нужную мне сторону.
                                                                                  3) Сформировать мнение о себе у потенциально полезного мне сообщества.
                                                                                  4) Получить информацию о мнениях и поведении людей со схожими интересами для уточнения своего мнения. (пересекается частично с пунктом 1)
                                                                                  Самое главное что тут иницииатором общения всегда выступаю я и только когда мне надо. До тех пор пока не проверю наличие уведомлений вполне отдыхаю.
                                                                                  Все таки люди существа стайные, соответственно приходится часто мимикрировать чтобы занять в стае нормальное место, получить нужные плюшки, эффективно выполнять работу.
                                                                          0
                                                                          Интроверт ≠ плохие soft-skills. Вот я интроверт, но медленно прокачиваю. Просто отдыхать между подходами приходится дольше.
                                                                            0

                                                                            Очень часто люди говоря: "ох, да я интроверт" имеют в виду что им не нравится оказываться в новой и некомфортно социальной ситуации и что им лень интересоваться другими людьми. Для успешной карьеры в управлении людьми и предприятиями нужен интеллект, желание учиться и немного эмпатии. Да и само это разделение больше связано с ролью индивидуума в конкретном коллективе и меняется со временем и с обстоятельствами. После 30 вообще разница несущественна, поколение взрослых диктуется требованиями социума.
                                                                            Я даже скажу что в корпорациях (по крайней мере инженерно- промышленных) на верхних этажах вы не встретите ярких экстравертов, зато ярко выраженных интровертов (или ведущих себя так) сколько угодно

                                                                            0
                                                                            30-летний старик
                                                                            молодому 33—летнему тимлиду

                                                                            занятная же у вас классификация… :)
                                                                            +6
                                                                            • ну так в пермом случае главному герою было лет 20-22 и он смотрит на тимлида, как на старика.
                                                                            • лет через 5 он уже разницу не так сильно ощущает, да и разрыв в возрасте и опыте уже не такой большой.
                                                                            • еще через 5 лет он смотрит на молодое поколение и начинает чувствовать себя старым

                                                                            Все относительно…

                                                                            По крайней мере у меня были именно такие мысли во всех IT компаниях города, где мне довелось поработать.
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                +3

                                                                                Или Коля забил на умные статьи и стал точиться в наиболее сложных и дорогих для рынка навыках, например, ML, DL, распределенные вычисления какие, highload с какими-нибудь >1M rps, разработка бд и так далее.
                                                                                Рынок его сузился, но востребованность после очередного периода джунства резко выросла.
                                                                                Коля ушел в суровую специализацию, но одновременно расширил свои навыки и скорее всего по дороге освоил еще несколько ЯП.
                                                                                И Коля стал настоящим senior с хорошей ставкой и полным непониманием, зачем ему переходить в лиды, PM и так далее.

                                                                                  +1

                                                                                  Это если он технологию угадал, а мог ведь уйти в какой-нить семантиквеб и все...

                                                                                    0
                                                                                    А на последние деньги купил биткоинов по $18к
                                                                                    Сейчас за 5-10 лет IT технологии меняются настолько, что востребованность на рынке может упасть в сотни раз. Потреряет Коля работу? Если закрепится за продукт, который будет поддерживать ещё лет 10, то нет, но автор об этом и так писал несколько раз.
                                                                                    Современный IT ещё и движется в сторону упрощения технологий в плане доступности. Если лет 12 назад я пробовал реализовывать перцептроны на C++, то сейчас практически любой облачный сервис предоставляет ML подсервисы, а по Интернету гуляют курсы по AI за 21 день. Я не говорю, что любой сможет ML сейчас, но в 90% проектов д.т.н. по AI/ML/Dl становятся не нужны, а в крупных R&D отделах нужны специалисты топового уровня всегда.
                                                                                      0
                                                                                      Стоит уйти в более сложные технологии, как описываемого вами нет.
                                                                                      Особенно если уйти в RnD проекты.
                                                                                      ML — реализации ничто, понимание, что делаешь — все. ML — это не столько про код писать, сколько задачу исследовать. Базовых подходов к типовым задачам десятки, у каждой реализации десятки параметров, у каждой задачи бесконечно много возможных фич. Верно выбрать, верно сделать прототип, верно внедрить в инфраструктуру — это мастерство.

                                                                                      Про 90% — все так. Я и говорил, что рынок доя Коли сузится, но его качество и доход повысятся. И частенько Коля будет не понимать, зачем люди рвутся в лиды и убивают себя, как способных инженеров и исследователей. Особенно это ему будет трудно понять с оплатой, скажем, 150$/час. В общем-то и коинов сможеь купить…

                                                                                      5-10 лет вы говорите. Ну устареет определенная технология, но я ведь говорю не о технологии, а о специализации. То есть об умении круто решать определенный класс задач. DL, ML, поиск, распределённые системы. Отдельные алгоритмы уйдут. Область останется.
                                                                                        0
                                                                                        Во время подготовки статьи мне скинули ссылку на другую статейку, но я не стал еще и это приплетать. А вообще, удивлен, что никто в комментариях не заклеймил за главное изображение поста с диаграммой. В ней, конечно, есть доля юмора, но и в каждой шутке есть доля шутки ;-).

                                                                                        У нас в заказной разработке по городу ЗП менеджеров колеблется в довольно узком диапазоне. ЗП разработчиков же начинается с очень низкой и начинает очень быстро расти, сеньоры уже легко перегоняют менеджеров по ЗП. Сильный технический специалист практически не имеет потолка по ЗП, главное тут — продолжать учиться и совершенствоваться, ни понимать, что для получения очень больших сумм надо очень много работать (в плане движения) и рассматривать возможность смены города и даже страны. Пройдясь по своему списку друзей в соцсетях, могу найти несколько подобных вариантов.
                                                                                          +1

                                                                                          Мой основной посыл был в другом: переход из инженера в управленца — это не единственный путь развития. Можно уйти в узкую специализацию, можно в RnD, можно в преподавание. При наличии soft skills любой из этих путей принесет достойный заработок. Но некоторые из них обладают уникальными качествами, как возможность исследовать ранее не решенные задачи, учить новые поколения, достигать тонкого мастерства в узном деле. Если Коле хочется чего-то из этого, то вряд ли стоит идти по пути управленца.
                                                                                          Да и про деньги тоже. Мой опыт говорит, что хороший спец ищет работу максимум месяц, выбирая наиболее клевую, а вот управленец может и на полгода и более застрять без достойной работы.

                                                                                            0
                                                                                            Мне кажется, что мы с Вами начали говорить разными словами, но об одном и том же.

                                                                                            Я специально в заключении выделил несколько путей дальнейшего развития разработчика: программирование, обучение, руководство. А так же специально акцентировал внимание на то, что если не хочется быть управленцем, то и не стоит это делать даже не смотря на то, что тебя к этому принуждают. Если же нравится заниматься менеджментом, то привел одну из книг, которая помогает двигаться в этом направлении.
                                                                                              +1

                                                                                              Хорошая работа с конфликтами. Действительно хорошая. Начали с конфликта, сказав про биткоины, но последовательно сместили внимание с острых вопросов на те, где возможно единое мнение, к которому и подвели.
                                                                                              С такой отличной работой грех не согласиться!
                                                                                              Конечно, я согласен. Как и с тем, что в крипту недальновидно вкладываться.

                                                                                            –2
                                                                                            ЗП менеджеров колеблется в довольно узком диапазоне


                                                                                            Менеджер, работающий за ЗП — это днище жизни. Менеджер должен работать за ДОХОД. Или как минимум, учиться этому у старших, тех, кто с экрана телевизора не сходит.
                                                                                              0
                                                                                              У жёлтогшо шарика или футболиста, засветившегося в каждой второй рекламе? Или у сериальных актёров, снимающихся сразу в нескольких? У Путина? Не очень знаю кто там с экранов не сходит.
                                                                                              Менджер — это упраяляющий, очень разные слои. Если он управляющий лавки — то да, доход ему близок (из-за малого размера предприятия), если предприятие большое, то вклад каждого отдельного минимален и ставить зависимость от прибыли — так себе идея (усложнение, не дающее профита). Так что ваш совет для управляющих лавки, не все хотят такими быть (даже менеджеры).
                                                                                      +1
                                                                                      Думаю, не стоило показывать графики если на самом деле никаких цифр нет. Даже оси не подписаны. К модели тоже, мягко выражаясь, вопросы. Создается видимость фактического подкрепления сказанного, а оно является чистой эмпирией. (поэтому нажал стрелочку вниз)

                                                                                      А вот личный опыт и основанные на нем советы — это полезно, для тех, кому этого достаточно.
                                                                                        0
                                                                                        Я долго ждал подобного комментария и был удивлен, что он долго не появлялся.
                                                                                        Да, действительно, графики без подписей являются плодом моего IMHO, что, собственно, и было указано в самом начале стати, а также несколько раз по тексту.

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

                                                                                        Единственное, что радовало меня как технаря, так это то, что они строились в на основе табличных данных и формул, т.е. не совсем от руки. А вот наполнение уже было сделано на уровне симуляции (а не эмуляции) разработчика в собственной голове, но на основании как собственного опыта, так и наблюдения за сотоварищами.
                                                                                        0
                                                                                        Довольно занятно было почитать с перспективы развития в научной среде. Сначала ты, действительно, кодишь / выполняешь другую работу в лабе. Потом ты пишешь заявки на гранты чтобы кодить / работать в лабе. Затем добавляются студенты, которых ты должен чему-то научить. Потом ты пишешь гранты за студентов и нанимаешь их чтобы они кодили и работали в лабе. Наконец, на работу в лабе и кодинг уже нет времени: ты становишься 100% «менеджером».

                                                                                        Думаю, в медицине да и во многих отраслях примерно так же. По прошествии определенного этапа за тобой заботливо закрывают двери. В этом плане программерская среда, конечно, более демократичная.
                                                                                          0
                                                                                          В ряде сфер есть привязка в выслуге лет. В IT я про такое не слышал и программировать можно хоть до победного. Я знаю и знал специалистов, которые были очень сильны именно как технари, но при этом в плане общения были очень тяжелы. Правильный руководитель создаст для такого сотрудника условия, при которых он сможет комфортно для себя и других выполнять свои обязанности (при условии, что такая возможность есть).
                                                                                            0
                                                                                            Да, тоже стал сравнивать как у нас происходит. В научной среде задачи все же другие — надо не производить материальный продукт, а выяснять как и что происходит в природе. И чем выше скилл гм… соображения тем меньше нужно заниматься непосредственно технической работой. Я вот сейчас пишу формулы и думаю, а кодит аспирант. Хотя некоторые формулы уже и он написать может. А какая у вас область?
                                                                                              0
                                                                                              Физика тв тела + материалы + кв. химия, всё теория.
                                                                                            0
                                                                                            На заре отечественной разработки (и реалиях контор, работающих по классификаторам) аналог сеньора — старший инженер. Ведущий инженер — именно лид. Может быть ближе к техлиду, может лид инженер, но лид.
                                                                                              0
                                                                                              Прочитав статью, порадовало мышление автора. Мне вот интересно кто как себя ведет когда приходит осознание того, что его основная технология устарела и ему требуется переквалифицироваться. Скорее всего в этот момент ему придется проиграть в з.п.
                                                                                              Приведу пример, который меня лично периодически беспокоит. На этапе становления на фронте принял решение изучать angularjs. Со временем я сделал ставку на angular 2 вместо react. С течением времени я стал замечать новые вакансии вида react и vue, и реже angular 2(6+), что обеспокоило меня. Изменение стека разработки влечет уменьшения твоей продуктивности. К примеру в angular у тебя уже есть архитектурный подход и т.п. Это влечет за собой изменения твоей вакансии (скажем синьера на мидла) и я бы описал это так ( бьет по самоооценке ) — автор назвал это Кризис возраста. Встает вопрос ( это уже к программистом со стажем ) при изменении стека технологий на сколько релевантен твой опыт, который можно перенять с прошлых технологий. К примеру на вряд ли занимая должность TeamLead в extjs или backbone ты станешь тимлидом в angular, react, vue и т.п. С удовольствием бы услышал мнение на этот счет)
                                                                                                0
                                                                                                Сильно зависит от конкретных вакансий. Одни компании больше ценят широкий кругозор, чем конкретную технологию, другие требуют знаний конкретного стека (по факту их вакансии могут месяцами висеть, хотя за это время вполне можно стек изучить было), третьи где-то балансируют, реально требуя, скажем, 50% из списка «требуется», ещё с 30% что-то близкое (скажем за тайпскрипт легко проходит даже javascript+java/c#, а то и PHP, не говоря о flow), а 20% можно на уровне «читал вводный пост на хабре».

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

                                                                                                  А меня — не порадовало.
                                                                                                  Потому что у него hard-skill жёстко прибит гвоздями к конкретному фреймворку, без какого-либо учёта предыдущего опыта и лёгкости изучить новое на основании знаний похожего.
                                                                                                    +1
                                                                                                    Потому что у него hard-skill жёстко прибит гвоздями к конкретному фреймворку

                                                                                                    Предлагаю перечитать статью еще раз и комментарий к ней, а потом уже «нерадоваться»

                                                                                                    Автор специально ввел понятие tech-skills для того, чтобы убрать из hard-skills фреймворки, библиотеки и прочее, а оставить именно опыт и фундаментальные знания.
                                                                                                    0
                                                                                                    Мне кажется, для TL изучить React, а тем более Vue, зная стек и Angular — это пара выходных.
                                                                                                      0
                                                                                                      Если говорить о изучении собственно react+react-dom, то да, что писать можно даже в день когда начал изучать. Но одна из особенностей react по сравнению с Angular и Vue — это не фулстэк фреймворк даже близко, а голый слой представления с довольно примитивным встроенным управлением состояния. Очень многие компоненты полноценного приложения надо будет выбирать дополнительно без чёткого понимания плюсов и минусов выбора даже для простейших приложений. В фуллстэк фреймворках такой выбор уже сделан.
                                                                                                        0
                                                                                                        Согласен, что ознакомиться с ним делов пару дней. А вот реализовать проект на том же уровне, что на родном стеке — нет)
                                                                                                      –1
                                                                                                      У меня 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 фуллстеком.

                                                                                                      Что помогало?
                                                                                                      • Глубокое знание веба (в свое время занимался разбором пакетов в wireshark)
                                                                                                      • Опыт работы с БД
                                                                                                      • Опыт работы и администрирования Linux. (сейчас приходится DevOpsить при необходимости)
                                                                                                      • Опыт разработки многопоточных приложений, межпроцессного взаимодействия, тестирования безопасности, нагрузочного тестирования, разработки высоконагруженных систем.
                                                                                                      • Опыт работы с кучей языков программирования (больше половины я не указывал в этом комментарии)
                                                                                                      • Опыт работы в качестве тимлида (уделять внимание мелочам, развивать младших товарищей, общаться с клиентом, не давать необдуманных обещаний, проактивность и клиентоориентированность)
                                                                                                      • Привычка работать в режиме постоянного стресса
                                                                                                      • Привычка разбираться в том, что ты делаешь, а не скакать по вершкам


                                                                                                      Возможно, что-то еще.
                                                                                                      Могу сказать, что смена стека технологий прошла тяжело, однако, относительно быстро, за 1.5+ года nodeJS знаю больше, чем среднестатистический молодой nodeJS разработчик, который пишет 3 года в резюме (переходы были без понижения ЗП)

                                                                                                      На текущий момент именно программированием занимаюсь только при необходимости (когда надо, а людей нет), но основная проблема с кодированием — постоянные задачи, которые надо решать, делегировать, контролировать.
                                                                                                        +1
                                                                                                        Не путайте вранье и стремление донести максимум ревалентной информации вместо односложного «правдивого» ответа. Если вам так важен опыт работы с конкретной технологией конкретной версии, но до собеседования вообще не стоит дело доводить с теми, у кого его нет. Это очень большой минус компании, если потратив много времени на контакты с ней выясняешь, что ты не прошёл по необладанию опыта какой-то технологии, о котором ты никогда не заявлял.
                                                                                                          0
                                                                                                          Что важного затрагивает эта статья и что прямым текстам, по-моему, стоит втолковывать ещё в школах (сейчас может, и говорят, но как-то неакцентированно) — что с возрастом когнитивные способности сильно падают (когда-то наступит момент, после которого ты уже не сможешь каждый день по новому фреймворку разбирать). И к этому имеет смысл готовиться заранее (либо заранее приобретать необходимые навыки (что не всегда возможно, потому что ты заранее не знаешь, что тебе потом понадобится), либо постепенно смещаться в сферы с меньшей динамикой требуемых компетенций или готовиться туда смещаться (что не всегда интересно, потому что хочется быть «на пределе»)). К сожалению, раньше я этого не понимал, (хоть старшие и упоминали не раз, что молодые быстрее соображают, но) был уверен, что это ко мне не относится и я всегда останусь таким, так тогда, и соответственно, заранее приобретать необходимые навыки не считал нужным.
                                                                                                            0
                                                                                                            У меня когнитивные способности и способности к обучению года в 22-23 резко подскочили, а также лет до 14-15 высокими были. А промежуток как будто потерял. Я за год осваиваю сейчас или до 14 столько же сколько осваивал за 3-4 года учебы в вузе.
                                                                                                              0
                                                                                                              У меня (субъективно) пик был в 25, а потом стали резко падать.
                                                                                                              Хотя я вроде читал, что объективно лет после 12 только спад.
                                                                                                                0
                                                                                                                У меня когнитивные способности и способности к обучению года в 22-23 резко подскочили, а также лет до 14-15 высокими были. А промежуток как будто потерял.
                                                                                                                Мозг брал отпуск на время пубертата =)
                                                                                                                0
                                                                                                                то с возрастом когнитивные способности сильно падают (когда-то наступит момент, после которого ты уже не сможешь каждый день по новому фреймворку разбирать). И к этому имеет смысл готовиться заранее

                                                                                                                Напомните средний возраст Нобелевских лауреатов? И вообще большинства известных ученых с мировым именем? Если что ссылка. Дело даже не в том, что нужно время, чтобы оценили заслуги, большинство 70-90 летних профессоров в разы лучше разбираются в новейших исследованиях по своей области, чем аспиранты.

                                                                                                                Медики говорят, что если постоянно заниматься мысленной деятельностью, когнитивные способности не снижаются, более того ВОЗ считает что до 44 лет это возраст молодости, когда еще практически нет возрастных изменений (ну если вы не проф. спортсмен).

                                                                                                                Поэтому нет, это не ваши когнитивные способности снизились, это ваш мозг лентяйничает (он это любит, да).
                                                                                                                  +1
                                                                                                                  Причём тут возраст нобелевских лауреатов?
                                                                                                                  Эффективность человека — это, если что, не только соображалка, но и количество знаний, а также доступ к информации (и прочим ресурсам) извне и прочее — комбинация этого всего достигает пика явно не в 12 лет.
                                                                                                                  Но соображалка с возрастом падает — это факт.
                                                                                                                  0
                                                                                                                  С возрастом становится меньше здоровья и выносливости, что в конечном итоге может восприниматься как падение обучаемости. Но, конечно, в уровне конечного влияния на карьеру разницы нет, устал ты или отупел. На своем личном примере я могу сказать, что после тяжелой работы вечером не остается сил даже на формошлепство, даже если оно до этого было на автоматизме. При это в последние годы я начал понимать то, что не понимал в математике ни в школе, ни в институте. В любом случае отбракуйте вариант со здоровьем и утомляемостью.

                                                                                                                  Также типовая работа веб-разработчика, мобильного разработчика или энрепрайзера не требует колоссальных умственных затрат. Прохождение собеседований — другое дело, но там что называется нужно заставить себя готовиться. Учить же все что есть на рынке невозможно. Обилие php-фреймворков конца нулевых было примерно такого же уровня как и сейчас фронтендовых фреймворков. Ни тогда, ни сейчас я не в состоянии это выучить на таком уровне чтобы меня нельзя было бы завалить на собеседовании. И среди программистов часто попадается такое дно, что понимаешь, что не в знаниях дело. Те кто громко кукарекают об иммутабельности, лямбдах, реактивном программировании и т.д. далеко не всегда настолько хорошие программисты как может показаться на первый взгляд. Наличия самородков это не исключает, но самородков на всех и не хватит.
                                                                                                                  0

                                                                                                                  Хорошая статья, но опять типичная ошибка, когда путают сеньора и лида:


                                                                                                                  была должность аналогичная Синьору, называлась она Ведущий программист — такой специалист не просто много знает, но и еще ведет проекты или коллектив.

                                                                                                                  Раньше были старший и ведущий инженеры(-программисты).
                                                                                                                  Сейчас это называется Senior и Lead.
                                                                                                                  Нужно понимать, что это Lead ведет за собой, а Senior это такой заслуженный товарищ, которые много знает и умеет, решает сложные задачи, но работает в основном в одиночку.
                                                                                                                  А если и ведет/делится опытом, то больше на неформальном уровне.


                                                                                                                  Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),


                                                                                                                  Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.

                                                                                                                    0
                                                                                                                    Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),

                                                                                                                    Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.

                                                                                                                    Автор решил не акцентировать на этом внимание в данной статье по той причнине, что если разобраться, то Team/Teach не выбивается из общей концепции, а еще и техлидов не хотелось бы обижать.

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

                                                                                                                    TeamLead — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин
                                                                                                                    • Он ближе к разработчикам и может их адекватно оценивать
                                                                                                                    • Разработчики к нему относятся лучше, чем к проектному менеджеру
                                                                                                                    • Можно убрать из проекта или снизить роль проектного менеджера (а он не приносит прямой доход)
                                                                                                                    • Он может общаться с клиентом с точки зрения бизнесса, а не технологий.
                                                                                                                    • Совещает в себе роли TechLead и PM


                                                                                                                    TechLead — техническй специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли. почему конкретный человек именно TechLead, а не TeamLead:
                                                                                                                    • Он может быть технически очень сильным и отвлекать его не стоит, например, может участвовать в большем количестве проектов
                                                                                                                    • Он интроверт или мизантроп, ему очень сложно общаться с людьми, а им с ним
                                                                                                                    • Он очень сильно любит программировать, а управленческие задачи ему не интересны
                                                                                                                    • PM не хочет делиться с ним обязанностями
                                                                                                                    • В компании нет необходимости в TeamLead и больше требуется технические специалисты


                                                                                                                    Техлид или архитектор — развитие программиста, который не хочет и не может развиваться в качестве управленца и об этом было упоминание в заключении, однако, при отсутствии очень сложных проектов он все равно менее востребован для работодателя, нежели тимлид, а если посадить рядом тимлида и техлида при равных технических скилах и наличии менеджеров проектов, то работодатель в большинстве случаев выберет именно тимлида из-за универсальности.
                                                                                                                      0
                                                                                                                      Могу под UPD добавить этот комментарий в статью.
                                                                                                                        0

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

                                                                                                                          0
                                                                                                                          Если возвращается чисто в программирование то по 3м причинам:
                                                                                                                          1. Наемным программистам больше платят, чем наемным управленцам
                                                                                                                          2. Он в какой-то момент понял, что «не хочет и не может» и решает вернуться в программирование
                                                                                                                          3. Упал спрос на менеджеров, а программисты нужны


                                                                                                                          Нежелание может быть не так выражено, либо они еще не решили, что ему будет лучше, но они же уходят в программисты со словами «не мое это»?
                                                                                                                            0

                                                                                                                            Вам видимо трудно представить вариант мотивации "могу проекты и управление, но хочу в спокойное программирование". И деньги, бывает, не главная мотивация.

                                                                                                                              0

                                                                                                                              Либо я плохо выразился, либо вы не так поняли. Я потексту указывал именно не хочет ИЛИ не может, а тут была контраста предыдущего комментатора.
                                                                                                                              Я могу представить себе такую ситуацию (и даже знаю примеры), когда хорошо получается управлять, но это отнимает слишком много сил, времени и т.д. + если ты ПМ, а твой заказчик в другом часовом поясе, то приходится подстраиваться под него, а переработки не оплачиваются.
                                                                                                                              Не являясь ПМом могу сказать, что это самая неблагодарная работа — на него давит и команда и клиент и работодатель. И плох тот менеджер, котррый это давление просто передает дальше поцепочке.

                                                                                                                          0
                                                                                                                          Почему «не хочет или не может»? Звучит так, как будто техлид — это какой-то фолбэк для программиста, желающего карьерного роста: по умолчанию тимлид или пм, а если нет желания или возможностей, то можно и техлидом. Как по мне, то ровно наоборот, если говорит о человеке уже пошедшим работать программистом, а не менеджером: по умолчанию рост в сторону лидинженера/техлида/архитектора, но вот если оказывается, что не хочет или не может, то идти в сторону тимлида.

                                                                                                                          Ну и общение с бизнесом с точки зрения бизнес-задач позиция техлида ничуть не отменяет, а скорее предполагает большее, чем у тимлида и пма (если все трое есть в команде): чтобы выбрать правильный стек, правильную архитектуру нужно досконально понять бизнес-задачу. Собственно прямая задача техлида — выбирать или предлагать на выбор технические решения бизнес-задач.
                                                                                                                            0
                                                                                                                            Отлично, что добавили в статью — описания этих ролей как раз не хватало.

                                                                                                                            Исходный комментарий связан с тем, что в некоторых окмпаниях и в понимании некоторых управленцев, сеньору приписываются навыки и полномочия лида.

                                                                                                                            Можно делализировать тот момент, что в сеньоры попадают как те, кто просто «заслуженный», и вроде на мидл-позицию его не поставишь, но сам разработчик и не хочет развиваться особо — так и те, кто мог бы стать архитектором и тех лидом, но, как вы заметили, что «архитекторы и тех лиды не нужны», поэтому они тоже идут в сеньоры, если не хотят идти в тим лиды и тем более в управленцы.
                                                                                                                          +2
                                                                                                                          Почти согласен с автором, но в статье отсутствует еще один путь развития, даже два. В один момент, проработав 15 лет разработчиком, я понял что надо самому действовать. Перешел во фрилансеры, выполнил успешно 3 средних проекта. Затем открыл свою фирму и стал индивидуаальным предпринимателем, продолжил программировать, но больше поддерживать нескол-ко продуктов. Так зарабатываю больше, график гибкий, с детьми целый день. Из минусов нет платного отпуска, но зато отпуск может быть в любое время, да и на море можно поработать.
                                                                                                                            0
                                                                                                                            Хотелось бы увидеть больше мыслей людей, идущих в таком направлении. Как вариант, не своя фирма, а инвестиции. Например, если не хочет человек быть зависимым от компаний, можно подумать о создании пассивного дохода, хотя бы минимального, а там уже заниматься тем, что интересно, касательно программирования. Хоть фирму свою, хоть фриланс, хоть на наёмную.
                                                                                                                              0
                                                                                                                              Сделайте пост про ваш опыт перехода, интересно было бы его прочитать.
                                                                                                                              0
                                                                                                                              Местами прям про меня, мой личный кризис жахнул в 2015, в результате я поменял стек. Процесс идет до сих пор, но потихоньку я таки выхожу на свою былую проектную мощность/производительность.

                                                                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                              Самое читаемое