company_banner

Как не испортить своего джуна



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

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

    Страх, страх и еще раз страх


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

    Точно такой же стереотип существует и в области разработки программного обеспечения. Сформулировать его можно так:

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

    Когда молодой специалист находит первую работу в сфере, он уже прекрасно знаком с общественным мнением касательно джунов. Он уже почти смирился с клеймом опасного вредителя. Так что большинство джунов выбирают тактику «минимизации ущерба» от собственного присутствия. Это выражается в отказе проявлять инициативу и брать на себя хоть какую-то ответственность.

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

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

    Я считаю, что программирование — это история о созидании, о творчестве.

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

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

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

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

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

    Давайте новичку настоящие и актуальные задачи


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

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

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

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

    Это огромная ошибка и проблема одновременно. Через выдачу таких «карманных задач», джун непреднамеренно изолируется от реальной команды и проекта. Пока весь остальной коллектив обсуждает боевые цели и таски, джун существует в каком-то своем пузыре, абсолютно не представляя, кто чем занимается и что вообще сейчас происходит. Все рабочие активности проходят мимо: он не принимает полноценного участия в митингах, не может проследить за развитием задач в трекере, банально не способен вникнуть в разговор у кофемашины или на курилке.

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

    Подобная «безопасная изоляция» приводит к серьезному выпадению из коллектива. Если джун внимателен и активен, если у него, как у личности, развиты коммуникабельность и прочие софт-скиллы, то он найдет себе пару товарищей и в курилке, и у кофемашины. Такой джун предложит угостить пару коллег бокалом пива, спросит, есть ли по пятницам в офисе зарубы в Quake 3 или CS, или расскажет забавную историю времен своего студенчества. То есть такой джун сам установит базовые социальные контакты с другими сотрудниками и уже через эту «социалочку» вольется в рабочий процесс.

    А что если наш джун соответствует всем стереотипам о программистах? Что если он нерешителен в живом общении, замкнут в себе и банально стесняется подходить к незнакомым людям со своими разговорами? Если он боится показаться посмешищем, ведь он и так толком ничего не умеет, потому что новичок? Или это молодая девушка, которая решила связать свою карьеру с разработкой ПО, но при этом не хочет давать поводов для сплетен о том, что кто-то из команды делает за нее всю работу? Как быть им?

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

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

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

    Подобный подход требует намного больших инвестиций в плане времени и усилий. Однако он позволяет успешнее онбордить новичка как на проект, так и в команду. Это учит его работать вместе с коллегами, а не где-то там в углу сидеть и «жевать клей», пока другие занимаются чем-то важным и крутым. В долгосрочной перспективе такой подход даст намного большие дивиденды, чем можно изначально представить.

    Практикуем парное программирование


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

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

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

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

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

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

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

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

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

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

    Относитесь к джуну, как к равному


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

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

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

    Однако в профессиональном плане он пока «подросток» и это играет злую шутку: к взрослому человеку начинают относиться, как к неразумному ребенку. Снимают с него ответственность, осторожничают, опекают.

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

    Так и отношение к джуну, как к разработчику, а не как к бесполезному питомцу или ребенку, подтолкнет его к профессиональному росту, осмотрительности и аккуратности.

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

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

    А ведь именно это нам и нужно, потому что через внимательность, старательность и желание стать профессионалом, из джунов и вырастают лучшие члены команды.

    Итог


    Тут я просто тезисно перечислю основные идеи из текста выше, для вашего удобства.

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

    P.S.


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

    Comments 64

      +2
      А где, на твой взгляд, новичку проще начать карьеру: в маленьком стартапе, где от каждого разработчика требуется решать сразу много разноплановых задач, или в большой компании, где все процессы уже более-менее стандартизованы и поставлены на поток?
        0
        Если нужно быстрое развитие по широкому списку технологий — большое количество разноплановых задач будет в самый раз, лишь бы успевал выполнять и разбираться. Такие задачи могут дать в любой компании, независимо от размера
          0
          Зависит от.
          Тут нет единой правильной формулы и правильного пути. Все люди разные.
          Для кого-то стартап будет отличным вариантом. Ответственность и неизвестность сыграет отличным мотиватором. И он быстро «прокачается» на разноплановых задачах
          Кому-то намного комфортнее пройти этот путь в большой компании «с методом под боком»
            +3
            Я думаю, что далеко не все стартапы имеют и материальные, и людские ресурсы на «прокачку» джунов. Для многих стартапов прежде всего важнее выйти на самоокупаемость. Там зачастую царит атмосфера «это надо было сделать ещё вчера». Поэтому развитие джунов грамотно можно реализовать только в крупных компаниях.
              +2
              Я думаю, что далеко не все стартапы имеют и материальные, и людские ресурсы на «прокачку» джунов. Для многих стартапов прежде всего важнее выйти на самоокупаемость. Там зачастую царит атмосфера «это надо было сделать ещё вчера».

              Моей первой работой после универа был стартап. И честно говоря я до сих пор считаю что мне в этом плане дико повезло потому и «ресурсы на прокачку» у них вполне себе были и технологии/подходы использовались вполне себе актуальные и местами даже передовые.

              Поэтому развитие джунов грамотно можно реализовать только в крупных компаниях.

              С другой стороны куча крупных фирм в плане ИТ всё ещё живут в 20-м веке и у них можно мало чему полезному научиться.

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


            если стартап полагается на джуна — это так себе стартап.
            или основатели ничего не понимают в тех. скиллах или у них нет ресурсов на настоящего спеца.
            учится в стартапе не у кого, кроме себя самого, а это малоэффективно и не все так могут.

              +3
              Лучше бы в большой или хотя бы состоявшейся компании: там больше возможностей посмотреть на то, как ведётся разработка ПО по-взрослому и перенять хорошие практики. А стартап — это:
              1. Небольшое количество разработчиков.
              2. Дай бог, чтобы эти разработчики были нормальной квалификации. Но присутствие даже одного джуна вызывает опасение, что они там все вчерашние студенты. В лучшем случае позавчерашние.
              3. Горящие сроки и связанные с этим компромиссы. Потому что стартапу нужно срочно закрепиться на рынке, у него нет времени на нормальную разработку.
              4. Слабо развитая инфраструктура. Потому что доводить её до ума для команды из десяти человек — некому.

              Но новичкам обычно выбирать не приходится.
                0

                Однозначно в большой компании: опыт будет качественным и не придется терять время на выполнении непрофильных работ.


                Широкий опыт возможет в обоих случаях, просто там, где процессы налажены, широкий опыт будет вокруг основного профиля, а не в рандомных точках.
                В частном случае это Terraform и CSS для бекендщика соответственно.

                +3

                Джуны бывают разные. Зачастую после первого роста, компании, которым повезло растить джуна превращаются в "stepping stone", и джун уходит дальше, на лучшие начала. Такой поток сохраняется.


                Да, найм джуна — это не усиление команды, а частичное ее ослабление на срок обучения

                И вот это хроническое, во всяких мелких вебстудиях. Хорошо если есть процесс в компании по типу стажерства и в компании есть рост на года.

                  +7
                  джун уходит дальше, на лучшие начала

                  Чаще всего причиной этого является эмоционально понятное, но ошибочное поведение компании «мы в тебя вложились, поэтому теперь ты нам обязан и мы будем тебе недоплачивать»

                    +1

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

                      +1

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


                      За 2-3 месяца желание работать и проявлять инициативу упало до 0, т.к. осознал что в ближайшее время никакого роста не будет. При этом не известно когда работник "отработает долг".

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

                      Да, в итоге я ушёл. Но проработал лишние полгода, только ради того что бы помочь закрыть проект над которым работал, и который некому кроме меня было закончить. Я мог бы этого не делать, но был благодарен конторе.
                        +5
                        Ещё есть третий взгляд, Выращенный из джуна мидл — будет очень держаться за коллектив… за сильного как лидера… тим лида… за стабильность… само собой пока будут интересные задачи и разница в деньгах на другой работе не 100% от зп
                          –1
                          Ну это само собой. Там у конторы были проблемы и я помог. Если бы там могли платить по рынку, то я бы само собой никуда не уходил.
                          +2
                          Я как-то был джуном, но потом в бухгалтерии лежала стопка договоров с размером з/п и я её немного подсмотрел незаметно. Через пару недель я уволился)
                            –1
                            Я как-то был джуном, но потом в бухгалтерии лежала стопка договоров с размером з/п и я её немного подсмотрел незаметно. Через пару недель я уволился)


                            Вы уверены, что в той фирме 100% зарплаты «в белую» выплачивалось?
                            Видал и такие фирмы, где официальная зарплата всего навсего 10% от реальной…
                            Соответственно, ни в каких бухгалтерских документах 90% суммы вы бы не увидели.
                          +1
                          Я согласен с одним из комментаторов выше. Джун ничего не должен ни вам, ни компании. Не нужно его считать «своим». Он такой же разработчик, как и все другие.
                          И тут задача работодателя обеспечить такую среду, из которой он не захочет уходить к другим: хорошая команда, возможности для развития, возможности проявить себя, интересные задачи.

                          Зп тоже влияет. Но она не всегда на первом месте. Человек может жертвовать частью зп ради «плюшек» описанных выше. Но и платить годами человеку зп, которую он перерос давно — не правильно.
                            +2

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


                            Опять же про деньги: джуны часто жалуются что им долго не повышают зп. Хотя по факту на самом деле просто первое время им переплачивают — платят больше, чем та польза которую они приносят. Просто потому, что на меньшую сумму никто не согласится. И только где-то через год может быть реальная польза от него догоняет его зарплату, а ему-то кажется что он вырос и потому зарплата тоже должна вырасти. Хотя по факту он просто до нее наконец дорос.


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


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


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

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

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

                            0
                            По-моему, если компания адекватно пересматривает стоимость работника, то никуда он не уйдет, так как чаще просто работать там, где все уже знаешь, чем где-то еще начинать с условного «нуля» в плане налаживания отношений, изучения продукта и т.д. Мне кажется, что «джун», который уже не джун может уйти или потому, что компания как-то забыла, что он уже не джун, либо в компании такая атмосфера, что человек терпел только ради опыта. Грамотные руководители найдут способы, чтобы текучка была минимальна. Но да, придется платить и создавать условия для работы, а так же следить за отношениями в коллективе. Иногда руководству полезно и на себя взглянуть. Часто сотрудники уходят именно потому, что в руководстве компании стоят какие-то самодуры, даже если с зарплатами все в порядке. Даже если речь идет о том, что человеку захотелось решать иные задачи и это единственная его мотивация ухода, в большинстве компаний и эта проблема решаема при желании. Чаще бывает, что руководство просто не слышит сотрудника и не пытается начать какой-то диалог, какие есть возможности изменения его обязанностей или перевода в другой отдел/проект.
                            +3
                            Правильная и полезная статья для многих руководителей. Спасибо!
                              0
                              Спасибо за добрые слова.
                              +22
                              Джуны роняют дев
                              Мидлы роняют стейдж
                              Синьоры роняют прод
                                +4

                                А архитекторы роняют сеньоров

                                  +1
                                  Архитекторы планируют возможность урона
                                  0
                                  Принципалы роняют фабрику
                                • UFO just landed and posted this here
                                    0
                                    Наоборот. Человек называя «своим» признает отвественность и хотя бы рабочую близость.
                                      –3
                                      А если повезет, то и не только рабочую?
                                      Теперь-то я понял, почему всегда подсознательно избегал всяких корпотативов, спасибо!
                                        +2
                                        «А если повезет, то и не только рабочую?»
                                        А почему бы и нет? Что плохого в близости? Неужели на уме только «половая близость»?
                                      +1
                                      Вы случайно не попутали наставничество с рабством? Своего джуна, как это прекрасно.


                                      1) Просто так заставить джуна как раба работать за тебя, а самому целыми днями бездельничать — невозможно. Ибо джун такого наворотит — его нужно контролировать, проверять, направлять. Это занимает кучу времени.

                                      2) Разумеется, джуна не поставят пилить архитектуру (впрочем, и такое бывает, но это показатель плохой организации труда). Джуна поставят делать не самую интересную работу. Например, косяки выгребать из кода за другими. Джуну кажется что это рабство, эксплуатации и т.п. Но, глядя в чужой хоть и неидеальный код, джун таким образом, начинает понимать — а как на самом деле выглядит изнутри выглядит та система над которой работает фирма.
                                      • UFO just landed and posted this here
                                      0

                                      Всегда интересен вопрос зачем берут себе джуна? Я не против джунов и все начинают где-то, но хочется понять. Для консалтинга ясно, берём всех подешевле, а продаём как сеньёров, а для банка например?


                                      Ну то есть я тимлид, у меня не хватает ресурсов, встаёт вопрос что делать. И я говорю давайте джуна наймём, нам полегчает? С учётом того что у банка денег на кого угодно хватит.


                                      Или просто есть лишний бюджет и надо куда-то его потратить, а когда под тобой больше народу, то выглядешь поважнее?


                                      Про рога&копыта понятно, они могут 30-50 в месяц дать и кто придёт, тот придёт, не до жиру.

                                        0
                                        С учётом того что у банка денег на кого угодно хватит.

                                        Денег то может и хватит, но человеческие ресурсы ограничены.
                                          +1
                                          Хороший вопрос.
                                          Скорей всего многие ответят на него по разному и имеют разные причины.
                                          Я вижу так:
                                          Во-первых, удивительно, но на «рынке» реально мало толковых специалистов. Даже мидлов. Сейчас есть много ребят, которые прошли курс на, условно, JavaRush и хотят сразу 100500 в минуту и быть синьорами. И получается, что легче компании «вырастить» своего условного мидла. Который будет и с хорошими техническими знаниями. И сразу еще со знаниями бизнес-процессов внутри компании и ее целями.

                                          Во-вторых, в этом есть что-то… (Не знаю какое слово подобрать правильнее.)
                                          Если у компании есть возможность взять стажеров и джунов и дать им хорошие и качественные знания, то почему бы и нет? На рынке будет больше хороших специалистов. Будет больше конкуренция среди них, подталкивающая их больше развиваться.

                                          Тут главное понимать, что есть условная команда «в мыле», которая и так загруженна «по самые уши», то такой команде нельзя давать (или брать) Джуна. Я про то и пиши в статье, что это ответственный шаг. И команда должна быть готова к нему. Нельзя взять Джуна и просто забить на него. Так будет только хуже всем.
                                            0

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


                                            Но думаю что подумал и понял в чём разгадка, скорее всего ему делают предложение "от которого нельзя отказаться". Тогда всё более-менее сходится.

                                              +2

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

                                                0

                                                Я в крупной компании работаю и не в РФ, здесь есть программа для интернов и пару раз к нам приходили. Толку не очень много (но и затрат тоже), ну и личные телефоны им интереснне чем что-то ещё. Хотя все на CS учатся.

                                                +1
                                                скорее всего ему делают предложение «от которого нельзя отказаться».

                                                Может где-то такое и есть, но я не встречал.

                                                Зачем ему конкретно головняк, ради какого-то «светлого будующего» банка или отрасли в целом.

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

                                                Не могу ответить за всех

                                                  0

                                                  Ну дай ТНБ. Хотя посмотрел на вашем карьерном сайте, для программистов не увидел джунских позиций.

                                              +4
                                              Ну то есть я тимлид, у меня не хватает ресурсов, встаёт вопрос что делать. И я говорю давайте джуна наймём, нам полегчает?

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


                                              С учётом того что у банка денег на кого угодно хватит.

                                              у банка лишних денег нет, потому их у него и много

                                                0

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


                                                Самое смешеное что сам работал в банке, в середине 90-х, но думал что это не релевантно сейчас.


                                                После написания комментария повспомнал и все те "джуны" которые к нам приходили, были детьми уважаемых людей. А специалистов брали уже состоявшихся. Думаю что не сильно поменялось с тех времён.

                                                  0
                                                  я очень рад, что ни разу у меня не было, что просят взять «детей уважаемых людей.» :)
                                                  Либо это что-то из прошлого. Либо что-то в конкретном твоем случаии.
                                                  Хочу в это верить :)
                                              • UFO just landed and posted this here
                                                  0

                                                  У нас не набирают джунов, поэтому и вопрос возник.

                                                +1

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

                                                  0
                                                  Совершенно верно. Но про команды. И как вообще сделать команду. И что такое команда, это разговор прям на отдельную статью. А то и не на одну.
                                                  +4
                                                  ну окей, вырастил джуна (я вырастил наверное уже с десяток разрабов и админов суммарно, в 3 конторах так что статистика накопилась), вопрос что делать дальше. Получается так:
                                                  1. 100+ резюме, 10+ собесов,…, взял джуна и естественно не кого попало
                                                  2. вырастил джуна (вероятность 1/2-3/4)
                                                  3. получаю уведомление что «рекрутёръ атакують», начинаю превентивный движ
                                                  4. затем оказывается, что денег на апгрейд ставки нет(а я же взял нормального, поэтому офферы уже естественно есть )
                                                  5. подписал ему заявление
                                                  6. «у вас же есть ставка джуна», goto 1.

                                                  эта музыка будет вечной.

                                                    +2
                                                    Я понимаю твою печаль, но не знаю как тебе помочь.

                                                    Если вы берете Джуна «на вырост», что бы самим его обучить до нужного вам уровня, то у вас должна быть под это условная вакансия под мидла.
                                                    Если вы можете позволить только Джуна, то, наверное, не стоит удивляться, что они потом, когда набираются опыта, уходят на позицию выше, где им ее могут предложить?

                                                    Тут, на мой взгляд, другого не может быть.
                                                    Даже если у вас Мега крутая компания и люди, они рано или поздно уйду на позицию выше, если вы сами ее им не дадите.
                                                      +1
                                                      >> должна быть под это условная вакансия под мидла
                                                      ну была бы условная вакансия под мидла, брали бы сразу мидла xD

                                                      >> ни рано или поздно уйду на позицию выше
                                                      и чем дальше в лес, тем быстрее это происходит (конкуренция растёт не только за нормальных, а просто за «из лужи не пьющих»)
                                                      +2
                                                      эта музыка будет вечной.

                                                      это изначально можно прикинуть и экономически оценить.

                                                      ну например из моей последней практики:

                                                      1. среднее время работы джуна в конторе — 2 года.
                                                      2. из них 2 месяца — это чистые убытки, ты за ним постоянно смотришь, консультируешь целыми днями. причем первые 2 недели — это вообще целый рабочий день парное программирование.
                                                      3. а потом тратишь на него меньше времени. но всё равно много. и это пока идут убытки
                                                      4. а где-то через полгода он начинает выходить в 0 (выдает чуть больше пользы и чуть меньше проблем).
                                                      5. последние полтора года идет прибыль с джуна. часть этой прибыли, разумеется, идет в зачет первого убыточного полугода.
                                                      6. ну и где-то около года из двух лет работы — джун приносит чистую прибыль и радует тебя.
                                                      7. можно делать апгрейд ставки, а можно не делать — зависит от особенностей фонда оплаты труда конкретного предприятия.
                                                      8. но задачей с точки зрения бизнеса является не вечное удержание, а удержание как минимум хотя бы до тех пор, чтобы джун окупил свое обучение и принес сверх этого какую-то разумную прибыль. сколько именно — это оценки только ваши. по моим прикидкам 1,5 года (из которых 1 год — это убытки и их компенсация, а 0,5 года это прибыльный период) — это самый минимум целесообразности удержания джуна. если меньше, то нет смысла изначально его нанимать.
                                                      9. если удалось более менее точно прикинуть время обучения и время получения прибыли и с учетом этого корректно установить заработную плату, то с экономической точки зрения это выгодно и то, что он уйдет потом — уже не принципиально для выгоды предприятия.
                                                      10. не значит, что не нужно пытаться удерживать обученного специалиста, но это не критично, если вы корректно оценили убытки и прибыль с джуна.


                                                      0
                                                      А что не так с Google-программистами?
                                                        0
                                                        Ну это не программисты в гугле работающие, а программисты, которые могут решить задачу только тогда, когда ее решение попадается в выдаче гугла. Думаю не нужно объяснять чем это плохо.
                                                          +1
                                                          А что не так с Google-программистами?

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

                                                          я встречался даже когда вбивают в поиск локальные пути к своим файлам своего проекта (типа /home/vasyapupkin/projects/mysuperproject_uniquename) в поисках решения — то есть даже не способны сформулировать корректный запрос для поисковой системы, не могут абстрагировано выделить проблему, которую нужно нагуглить.

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

                                                          совсем недавно на Хабре была об этом целая статья.
                                                            +1
                                                            Имеется в виду программисты, которые пишут код, копируя из гугла
                                                            +2

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

                                                              0
                                                              Интерестно, а изменилось что-нибудь в процессе в связи с удаленной работой? Все же как я понял статья писалась про людей которые сидят в офисе
                                                                0
                                                                Интерестно, а изменилось что-нибудь в процессе в связи с удаленной работой? Все же как я понял статья писалась про людей которые сидят в офисе


                                                                Для сложившихся специалистов — не имеет значения.
                                                                Для джунов — только сложнее стало. По удаленке сложнее скиллы прокачивать, так как стало суше-формальнее взаимодействие с опытными коллегами, которые бы при очном общении запросто подсказывали.
                                                                0
                                                                Боевые задачи дали джуну — так вот почему интернет банк валялся в понедельник?
                                                                  +1
                                                                  Замечательная статья, спасибо!
                                                                    0

                                                                    Тему подняли интересную, но аргументация статьи — ерунда с кучей каких-то непрофессиональных комплексов и вот почему:


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

                                                                    Не считают. Есть процессы адаптации и onboarding'а и не только джунов. В команду\проект может не влиться и матёрый, бородатый сеньор.


                                                                    Это сейчас подавляющее большинство из нас — опытных разработчиков — уверенные в себе профессионалы.

                                                                    Кину камень в ваш огород — вы выкатываете релизы в часы пик, которые парализуют работу бизнеса. Т.е. зарелизить новый серверный бэк в разгар дня — норма. Обратная совместимость — нет, не слышали, blue-green deployment — тоже мимо.


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

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


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

                                                                    Нет. Это лишь значит что на проекте отвратительные процессы и никчёмный менеджмент.


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

                                                                    Да важно и нет, не отобразится, но только при условии — Scrum Master или тимлид или ПМ не спят в уголочке, безвольно пуская слюни, а хотя бы занимаются черновым планированием спринта.


                                                                    Что же действительно важного вы не написали:


                                                                    • Фидбэк — обратная связь — мощный инструмент с которым надо очень аккуратно работать. Им можно как поломать карьеру человека, так и сильно её ускорить.
                                                                    • Менторство — более эффективно чем парное программирование, развивает навыки R&D и решения проблем, а не безголового — делай как я и пофиг если не эффективно.
                                                                    • Правильная коммуникация — не стоит "дрючить" джуна слишком часто или жёстко, так и забывать о нём не стоит, джун должен понимать что его статус отслеживают. Это же работает и в обратную сторону: джун должен понимать что обратившись к этому человеку он получит помощь, но слишком часто отвлекать более опытного товарища тоже не стоит: потыкался, что-то попробовал, погуглил, собрал пачечку вопросов и пошёл их разъяснять.
                                                                    • Процессы — должны быть чёткие инструкции куда бежать и что делать.
                                                                    • Нормальная команда и руководители — я видел несколько поломанных карьерных судеб у действительно стоящих людей, но на старте они столкнулись с конченными мудаками и уродами.
                                                                      0
                                                                      Как мне кажется, про уронить прод это утрирование уже, PR же существует, на нем кстати если ревьюверы хорошие можно много уроков извлекать полезных.

                                                                      Only users with full accounts can post comments. Log in, please.