Comments 61
Без кейса конкретного проекта все эти советы нанимать или не нанимать джунов - болтовня. У меня есть примеры, когда нанятые джуны просто респердолили все, чего коснулись, и довели сеньора (меня) до аритмии и почти нервного срыва. Проект был сложный, динамичный. Дать джуну возможность говнякать абы как и плодить техдолг каждым своим коммитом было слишком большой роскошью. А было наоборот, когда компания шла по пути "только сеньоры" - а по факту спектр задач чисто джуновский. Сидит такой сеньор-помидор за много денег и сюда два поля в респонс добавит, там два поля уберет.
Ну и по аргументации несложно догадаться, кто писал статью. Мол вы нас нанимайте и ЗП повышайте через год. А мы вам новую кровь и новое видение принесем. Нюанс в том, что чтобы что-то принести, нужно для начала что-то иметь.
У меня было наподобие. Проговорили с аналитиком внесение правок в определенном месте. Джун взял и остальное удалил, т.к. аналитик про это не написал. А раз не написано, значит нужно удалить.
А у вас не было испыталки и мелких задач для джунов? Сразу в бой без ревью, пушим в прод в воскресеньям.
Я Лид с 2003-его года.
Пропорция в найме обусловлена потребностями проекта. Менеджер может этого не понимать, но лид это понимать обязан, я бы даже сказал чувствовать жопой.
Самый важный график:
У каждого программиста, даже у Возняка (он об этом рассказывал, в книжке "iWoz") есть свой индивидуальный порог сложности за которым скорость работы обваливается даже не в разы, а на порядки. JSON-чики конфигов джун и синьер редактируют с примерно одинаковой скоростью. ПОэтому выбор кого нанимать это всегда вопрос "Есть ли у вас в проекте задачи, на котороых разница между мидлом и синьеором сможет проявиться".
Причём если вы тимлид, то должны понимать не только это, но ещё и то, что каждый синьер стремится схватиться за наиболее сложные задачи, то есть те, на которых его производительность начинает просидеть. И руля синьерами важно удерживать баланс, иначе они на столько наусложняют, что никто кроме таких же синьеров не сможет потом это поддерживать. То есть думая о человеке в своей команде вы всегда, не только при найме, должны держать в голове где у данного конкретного человека индивидуальный предел сложности, а лавировать задачамми и требованиями к продукту с учётом этого.
P.S. Просто мы разные. Порогом некомпетентности Возняка оказалась программа в машинных кодах под два разных взаимодействующих процессора, которая пишется сразу в кодах и запускается без отладки. Как говорится, это тот уровень некомпетентности до которого нам расти и расти
JSON-чики конфигов джун и синьер редактируют с примерно одинаковой скоростью.
Не факт. Если синьеру скучно, он их не будет редактировать в принципе пока не нажмут на него. И джун справится быстрее. Так что в вашей картинке, все кривые должны иметь спад слева.
Может и хочет - два отдельных графика и повод не то что для статьи - для книги. Я, в данном случае, исключительно про "может". Если ему будет нужно, например это конфигуратор движка, или исправление косяка в JSON допущенного геймдизайнером в качестве разового исправления, он справится быстрее, но не на много.
Почему-то многие сейчас считают, что сеньоры всё наусложняют - и это нормально. Когда я учился программировать, умные книжки читал и потом общался с коллегами (лет 5 назад), то наоборот считалось, что более квалифицированный прогер напишет более простой, эффективный и понятный каждому код, а сложный и непонятный код пишет мудила-понторез, который вместо работы занят самоутверждением. Видимо, теперь эти понторезы продвинулись в тимлиды
Если говорить о каждой мелкой задачке то да. Есть ещё задачи трейдофа, когда синьер может сделать какой-то инструмент, который раз в пять-десять ускоряет разработку всем в команде и вы встаёте перед выбором - ускорить в пять раз, но внутрь ускорителя можно запускать мидла или в десять, но без синьёрских нашивок внутрь лучше не соваться. Именно на таких задачах синьер может принести как наибольшую пользу продукту, так и наибольший вред.
Ну вот был у нас такой модуль, который такие синьоры писали. Всё очень красиво, очень структурировано, с кучей ассертов, чтоб не дай боже чего-нибудь куда-нибудь не туда не пошло. Прилетела задача в этом модуле поправить поведение. В итоге пришлось несколько дней штудировать доку, чтоб понять, что решение может быть только временным, т.к. очень умные сеньоры, которые всё это писали, почему-то не подумали об ограниченности ресурсов, с которым мы столкнулись в рамках этой задачи. Но переделка этого модуля потребовала бы отдать на это дело сеньора как минимум на месяц.
Ну и еще байка туда же - другой был модуль, в котором всё было очень запутано, многие ветераны даж говорили, что туда заходить боятся, т.к. там сам черт ногу сломит. А вылезла задача, т.к. у кого-то где-то там что-то ломалось - и железка падала примерно раз в месяц (а должна работать непрерывно годы). Ну и я начал там разгребать весь этот перемудрёный код, нашел много потенциально опасных операций с данными - и выпросил у начальника разрешения всё это переписать. Переработал структуры, хранившие данные, написал промежуточные функции для работы с ними, переписал функции верхних уровней, которые в старом коде дёргали данные напрямую без каких-либо проверок. Проблемы решились, код стал компактней, ресурсы высвободились, хоть это и не ставилось как цель, но разработка и отладка этого заняла больше ГОДА с перерывами на другие задачи.
Это я к тому, что после этого сформулировал свой критерий оценки качества кода, из-за которого у меня перманентное недопонимание с нынешним поколением тимлидов - код должен быть настолько простым и понятным, насколько это возможно для решения задачи, которую он выполняет
А господин точно лид с 2003-го? Квалифицированный разработчик отличается не скоростью разработки, а скоростью деградации (усложнения поддержки проекта). Она у него ниже чем у неквалифицированного настолько, что может достигать отрицательных значений. Человек усложняющий поддержку не называется сеньором. Нет ну то есть называется, но не является. Джун может работать ооочень быстро, проблема в том что отпущенный в автоном джун разгоняет эту самую деградацию и за ним всегда нужно вдумчивое ревью, жесткая корректировка, или решение прописанное досконально. Так что на любом проекте необходимо n высококвалифицированных сотрудников и n*m сотрудников попроще где m - индивидуально от количества задач которые эти n имеют и главное способны делегировать со всеми отягчающими.
Джуниоры привносят в команду энергию — они хотят учиться, у них есть стремление проявить себя и добиться успеха. Их мотивация может быть заразительной! Вашим сеньорам понравится работать с умными и мотивированными коллегами.
Таких джунов пара человек на сотню. Основная масса из того, что я видел, пришли на работу за большой зарплатой. Человек может худо-бедно что-то делать, но как только что-то идет не так и нужно разбираться, тут все: у него наступает ступор, ловится выгорание, отрастают лапки.
Подумать и разобраться? Да нафиг надо! Пойду донимать коллег вопросами, даже не попытавшись приложить минимальные усилия. Но это ладно, тут можно еще что-то исправить, привить навык включать мозг.
Все больше приходит таких, которым ставишь какую-нибудь задачу, спрашиваешь:
Все понял, что нужно сделать?
Да, понял
Если вопросы будут, то спрашивай
Да, хорошо
Проходит время, человек что-то делает, вопросы не задает. На твои вопросы говорит, что все ок. Подходит срок, начинаешь спрашивать результат. А результата нет, либо на выходе лютая дичь. Плюс, бывает, человек начинает отмораживаться: не отвечает в чатах, на письма. Когда срок совсем подгорает, человек уходит со словами, мол, что-то у вас токсичненько и вообще меня не мотивируют подобные задачи.
Так что джуну джуну рознь. На стажировку взять человека можно, а в штат - по результатам. Обычно все становится понятно в течение месяца.
Подумать и разобраться? Да нафиг надо! Пойду донимать коллег вопросами, даже не попытавшись приложить минимальные усилия.
выходит, это тоже один из навыков, который надо проверять при найме: умеет ли человек решать задачи, которые решать пока не умеет, умеет ли учиться
Подумать и разобраться? Да нафиг надо! Пойду донимать коллег вопросами, даже не попытавшись приложить минимальные усилия.
Вот тут не совсем согласна. Иногда спросив можно выиграть 1-4 дня.
И вот трое джунов сэкономили по 1-4 дня на своих низкоприоритетных простых задачах, а отвлекаемый их вопросами сеньор потерял 4 дня на сложной и критичной задаче.
Только вот потом они аналогичные задачи будут решать быстро.
А по вашему джун должен сидеть всегда сам в одиночку и разбираться. Это не командная работа.
Когда джуны своими проблемами рвут сеньора на части — это тоже не командная работа.
Если это происходит, это значит не правильные процессы в команде.
При нормальных процессах обычно один начинающий джун в команде (а не куча их) и он прикреплен к сеньору.
У вас что-то не то с командой. Если джуна прикрепляют к сеньору, то это всегда 1 на 1. Этакое наставничество и менторство, которое полезно обоим. Как там считается, если ты можешь доступно объяснить что-то другому несведущему человеку, значит ты это хорошо понимаешь, настолько, что с помощью аналогий можешь донести это до него. Ну и наоборот, если не можешь что-то объяснить, уверен ли ты в том, что сам все хорошо понимаешь.
Вы, простите, из диагностов по фото? Если не обратили внимания, то мы там выше обсуждали гипотетическую ситуацию с различными крайними её проявлениями, а не мою команду.
Компания - это не школа с бесплатным обучение для ваннаби программистов, и другие программисты не нанимались учителями работать. Предполагается, что нанимаемый сотрудник знает всё необходимое для выполнения работы, на которую его наняли. В этом смысле джун от мидла отличается только количеством опыта и соответственно скоростью и качеством решения задач. Если джун к старшим постоянно бегает с вопросами, то это признак его некомпетентности и несоответствия занимаемой должности.
Кто же спорит. Но если джун будет боятся показаться некомпетентным, будет искать все ответы в интернете, самостоятельно, в базе знаний компании, насколько это по-вашему правильно? Это признак чего? Токсичной атмосферы в компании? А как ему стать профи? Люди испокон веков делятся опытом, обучая кого-то. Можно и самому, конечно. Но путь будет длинен. Или интернет все порешает, зачем общение? Думаю и вы и я правы оба. Просто всего в меру должно быть.
Только вот потом они аналогичные задачи будут решать быстро.
Не будут. Процесс обучения - это не копирование информации на носитель, а наращивание тканей в мозге, он больше похож на накачивание мышцы, поэтому чтобы быстро решать какие-то задачи, надо сначала неоднократно приложить усилия к самостоятельному их решению.
А по вашему джун должен сидеть всегда сам в одиночку и разбираться. Это не командная работа.
По-моему, джун должен идти за помощью только тогда, когда сделал всё от него возможное, но не добился результата. Командная работа - это когда каждый сотрудник несёт полную ответственность за вверенный ему участок работ, а не когда за тебя остальная команда работает. Джун отличается от мидла только тем, что участок работает у него попроще, а справляться он с ним должен самостоятельно.
По-моему, джун должен идти за помощью только тогда, когда сделал всё от него возможное, но не добился результата.
Я разве пишу о том, что джун должен сразу бежать с вопросами?
Да, он должен посидеть и попытаться сам. Но это не значит, что он должен сидеть и неделю убить на это. По хорошему, если не получается решить в течении 3х часов, то лучше подойти и задать вопрос. В этом и заключается командная работа. А не работа в одиночку в команде.
Поэтому джунам нужен наставник, в рабочее время которого заложен некоторый ресурс для помощи младшим товарищам без ущерба для основных задач. Либо процесс, позволяющий решать возникающие вопросы планово, не отвлекая коллег от текущих дел.
Все больше приходит таких, которым ставишь какую-нибудь задачу, спрашиваешь:
Все понял, что нужно сделать?
Да, понял
Если вопросы будут, то спрашивай
Да, хорошо
Проходит время, человек что-то делает, вопросы не задает. На твои вопросы говорит, что все ок. Подходит срок, начинаешь спрашивать результат. А результата нет, либо на выходе лютая дичь. Плюс, бывает, человек начинает отмораживаться: не отвечает в чатах, на письма. Когда срок совсем подгорает, человек уходит со словами, мол, что-то у вас токсичненько и вообще меня не мотивируют подобные задачи.
Здесь явно что-то не то с обратной связью от наставника/начальника, что джун не хочет с ним контачить и спрашивать. Если на вопрос человека, который не знает что-то отвечать: "ну что ты, такой тупой, элементарного не знаешь, за что тут тебе денег платить, когда ты такие вопросы задаешь", то вероятность, что при появлении следующего вопроса, его зададут, резко снижается. А если будут добавки про "если не можешь выполнить эту работу самостоятельно - увольняйся", то вообще никогда, и весьма гарантированно уволится. Сталкивался на предпоследнем месте работы с такой обратной связью от начальника - сначала были фразы типа "ты тут больше года работаешь, и не знаешь, какие саблокации за что отвечают", после попыток расспросить других работников на эту ему прилетело от начальника "Х - не твой персональный консультант", а потом, когда скопом натолкал в анализ движений поступления водопроводной воды (потому что кто ж знал, что в некоторых складах она на стоке числится, хотя обычно нет) и прилетело от начальника обвинение в некомпетентности, тупо положил заявление на увольнение. Сразу замечу, что это был типичный случай, не единичный и системный - по уточняющим вопросам был ответ обычно негативный, расспросы коллег не приветствовались, а с потолка или из предыдущего опыта взятая информация вызывала еще более резкий негатив, а потому естественной реакцией было не дергаться самому, и не тревожить небожителя-начальника, шибко занятого, чтобы ответить на вопрос на каких складах и на каких локациях есть трубопровод, учитываемый в стоке. Тем паче, что работу я нашел в первую же неделю после увольнения, причем звали на два места сразу.
Тут надо явно менять систему коммуникации, обучения и связи с работником. В принципе, если с вами не хотят общаться, причем ситуация повторяется, то что-то не в порядке явно не с джунами, чисто статистически там столько людей с нарушениями социализации быть не может.
Честно говоря, я потому в частности в IT и не рвусь, потому что знания не систематические, отрывочные, и задача "разбирайся сам" без указания куда копать, практически всегда жрет огромное количество времени, а на то, что мне будут объяснять некоторые вопросы с нуля, я даже и рассчитывать не могу, и предпочитаю, чтобы все осталось на уровне "специалист, умеющий немного в компутер"
Обоюдно острая ситуация. Я был готов отвечать на вопросы, делится опытом, и подходами и начал с неких правил работы. А что в итоге? Значительная часть проблем не из мира программирования, а логики, повседневной жизни и очевидных вещей:
Как это работает? - ты сам делал, посмотри в свой код
Так не заработает - ты уже это сделал в другом месте, вот оно
Это не получится - приходил, смотрел, сам погружался в задачу, и все получалось. Ок, ему бы потребовалось больше времени, но это не беда. Там задачи из разряда переложить джейсон.
Проблемы с пониманием задачи. Перешли на текст. Кажется теперь написанные слова порой просто игнорируются, а они оказываются ключевыми
Проблемы с памятью и контекстом - обсуждали группой проблему, решили что делать, но по случайности в задачу не дописали пару слов из обсужденного. Человек это и не сделал. В задаче же не было. Время между обсуждением и задачей - полчаса-час.
Проблемы с охватом и контекстом. Не читает корневую таску с контекстом задачи и задает вопросы, ответы на которые там есть. Или начинает делать задачу вообще не в ту степь. Потому что не прочитал контекст.
Проблемы с тестированием и подготовкой тест кейсов. Если поправлен какой то общий функционал - перетестировать надо все, что на него ссылается.
Самый смак - я уже об этом писал в коментах тут под очередной такой статьей. Была задача сделать некоторые поля на форме обязательными. Сделал. Проверяю. Запускаю экран, не заполняю значения, жму сохранить и все сохраняется 😄. Серьезно? Это не программирование. Это человек походу никогда не заполнял формы на веб сайтах в повседневной жизни и не сталкивался с обязательными полями. И выходит мне нужно программисту объяснять как работают обязательные поля??
Ну и главное - все это происходит снова и снова. Раз за разом. Складывается ощущение, что современные джуны не учатся на своих же ошибках.
Ну и главное - все это происходит снова и снова. Раз за разом
Такая жиза, что аж зубы свело. Я когда попал в эту ситуацию, в итоге пришел к начальнику с фактурой. Смотри мол, одни и те же замечания в каждом пулл-реквесте. Плюс отношение количества замечаний к числу строк кода не падает. В итоге додавил, и двух таких одаренных уволили.
Из вашего объяснения я вижу, что учитель из вас так себе. Первая, и самая главная ваша ошибка - вы не понимаете, что педагогика (а она есть почти в каждом рабочем процессе, обучение в широком смысле слова) - это "наука о повторении". И вас очень раздражает необходимость повторять. Но мир многообразен, и нельзя войти дважды в одну и ту же воду. Вот у меня вчера было - месяц делали приемки все отлично, безупречно, и за вчерашний день - три детских косяка с последствиями, причем такими, что я сам просто не смог их выправить так, как предполагается. Почему? Потому что люди делали все поступления сразу, а как только столкнулись с передачей процесса от одной смены другой, накосячили. Повторил все то, что вколачивали предыдущие пару месяцев. НОРМАЛЬНЫЙ ПРОЦЕСС.
Как это работает? - ты сам делал, посмотри в свой код
я тоже много чего делал, не понимая сущности, как это работает, тупо копируя откуда-то, на том этапе понимание было не нужно, а сейчас потребовалось
Так не заработает - ты уже это сделал в другом месте, вот оно
Люди часто не делают акценты на том, что они делают, особенно когда делают много. И забывают. Особенно когда копируют без понимания. Это нормально. Не добившись понимания (см.п.1) человек будет в спешке слепо копировать, и забывать про это.
Это не получится - приходил, смотрел, сам погружался в задачу, и все получалось. Ок, ему бы потребовалось больше времени, но это не беда. Там задачи из разряда переложить джейсон.
И что тут? Ему бы потребовалось больше времени - сами же пишете. Для обучения нужно время, если вы его не даете, то какие претензии-то? К себе претензии, что ставите задачи, которые оцениваются как нерешаемые, не дав достаточно времени для самостоятельного решения.
Проблемы с пониманием задачи. Перешли на текст. Кажется теперь написанные слова порой просто игнорируются, а они оказываются ключевыми
Слова ключевые только для вас. А кроме вас есть и другие люди, когда вы вспомните об этом, то у вас будет гораздо лучше получаться ставить задачи.
Проблемы с памятью и контекстом - обсуждали группой проблему, решили что делать, но по случайности в задачу не дописали пару слов из обсужденного. Человек это и не сделал. В задаче же не было. Время между обсуждением и задачей - полчаса-час.
Это совсем глупая претензия. Вы зафиксировали задачу - не все обсуждение законспектировали и зафиксировали, а только то, что считаете важным и необходимым сделать, ошибочные и неприемлемые решения не фиксировали. Для подчиненного фиксированная задача есть прямое распоряжение начальника, и фантазировать о том, что "на обсуждении было вот это еще сказано", НЕ ДОЛЖЕН. Даже если это пять минут назад было сказано. Если начальник задачу не включил в резюме встречи, то значит, она как минимум не приоритетна. Если джун будет думать за вас - то вы тоже сильно обидитесь. И куда джуну деваться? Угадывать, что вы хотите? Нанимайте фокусников, у них такое хорошо получается.
Проблемы с охватом и контекстом. Не читает корневую таску с контекстом задачи и задает вопросы, ответы на которые там есть. Или начинает делать задачу вообще не в ту степь. Потому что не прочитал контекст.
угу. Проходили. Отправляю в юр.отдел типовой договор с "Деловыми линиями" на согласование. Вместо пояснения, что конкретно и где надо поменять, отсылка к Регламенту, который сложный гипертекстовый документ, распечатываемый на 500 с чем-то листов. И начальник мне: "Ты регламенты читал?" Да, конечно, наизусть заучил все 500 страниц за две недели работы - домой как прихожу, регламенты читаю и нараспев учу. Это к чему: работник с малым опытом может просто не знать, где искать в достаточно сложных документах, или же в ветках задач, которые ему не совсем очевидно, относятся к его функционалу. Просто отослать к корневым таскам - практически всегда разговор ни о чем. Я тогда начальника юр.отдела тоже послал вместе со своим начальником, после чего юр.отдел все-таки написал, с чем они не согласны, потому что отгрузка не может ждать, пока я в Регламенте наконец-то наткнусь на то, что они там имели в виду.
Проблемы с тестированием и подготовкой тест кейсов. Если поправлен какой то общий функционал - перетестировать надо все, что на него ссылается.
джун может просто не знать "всего, что на него ссылается" или не знать, как его искать. Вариантов масса. Я сам настраивал WMS и до сих пор бывает, что забываю, что там еще какой-то обработчик ссылается на измененное событие, и вспоминаю лишь, когда что-то идет не так. Явление нормально - подписок и обработчиков много, рисовать дерево сложно, так как стандартного функционала визуализации нет. Нормальный рабочий процесс, если вас это так раздражает - не знаю, может, руководить людьми - не ваше?
Самый смак - я уже об этом писал в коментах тут под очередной такой статьей. Была задача сделать некоторые поля на форме обязательными. Сделал. Проверяю. Запускаю экран, не заполняю значения, жму сохранить и все сохраняется 😄. Серьезно? Это не программирование. Это человек походу никогда не заполнял формы на веб сайтах в повседневной жизни и не сталкивался с обязательными полями. И выходит мне нужно программисту объяснять как работают обязательные поля??
Ну и что? Я объяснял, что в Экселе в ячейке может быть много строк. Люди этого не знали. Да, мартышки, но теперь узнали. Как бы люди - это люди. Я сталкиваюсь, даже, поболе вашего с людьми, у которых нулевые или отрывочные и несистематические знания в банальной компьютерной грамотности. Бывает, просто не понимают или неверно понимают терминологию. Например, объяснял людям, что такое путь к папке. Диковато, но это в большинстве случаев не их вина - это производная как от развала общей системы образования, так и бессистемного обвальному развития компьютерных технологий, когда систематизация и терминология не успевала. В вашем случае возможно просто не так понял. Но случай единичный явно. А вы строите из единичного случая целую теорию, что джуны-де тупые и не торт.
Люди в целом, особенно молодежь не торт уже давно - читают мало, кругозор узкий. Но другого человеческого материала нет, и самое интересное, что не будет, особенно если от каждого такого с пробелами в знаниях и навыках отпихиваться.
Я уже года два повторяю и меня раздражает то, что за это время лучше не становится. Каждый раз одни и те же грабли.
я тоже много чего делал, не понимая сущности, как это работает, тупо копируя откуда-то, на том этапе понимание было не нужно, а сейчас потребовалось
Люди часто не делают акценты на том, что они делают, особенно когда делают много. И забывают.
Ну так пускай пойдет и посмотрит код, вспомнит. А не спорит до усрачки, что это не заработает.
И что тут?
Джун говорит - что это не получится и перестает пытаться решить задачу.
Слова ключевые только для вас.
Это совсем глупая претензия. Вы зафиксировали задачу - не все обсуждение законспектировали и зафиксировали, а только то, что считаете важным и необходимым сделать, ошибочные и неприемлемые решения не фиксировали.
Нет не так, мы обсудили задачу, зафиксировали на словах что надо сделать, джун поддакивал. Потом мы перенесли эти договоренности в текст, то есть зафиксировали еще раз (на тот случай если джун забудет), но пропустили два слова. Сениор - делает так как договорились, даже если заметил неточность в описании - поправит таску сам. А у джуна даже не возникает вопроса - почему на словах договорились об одном, в задаче немного другое. Не уточняет это и хорошо, что это потом всплывает на код ревью и тестировании.
угу. Проходили
Угу и я проходил. Сначала на словах - джун забывает или забивает, потом пишем текстом - джун не читает или читает, но игнорирует. По итогу за ним переделывают.
джун может просто не знать "всего, что на него ссылается" или не знать, как его искать
Знает (условно правой кнопкой find all references), просто не делает. Правит в одном месте. Вот эта статья в деталях описывает, что происходит за сценой с джуном и с сениором https://habr.com/ru/articles/656979
Ну и что?
Для перечисленных людей - это норм. Для программиста - это по сути профнепригодность. Случай не единичный, но самый яркий и показательный.
Но другого человеческого материала нет, и самое интересное, что не будет, особенно если от каждого такого с пробелами в знаниях и навыках отпихиваться.
Хм... ну и отлично, у меня зарплата больше будет.
Хм... ну и отлично, у меня зарплата больше будет.
Забавненько. То есть, ваша форма общения с джунами - не просто ваша личная педагогическая ошибка и отсутствие нужных социальных качеств для работы с людьми, но еще и сознательный саботаж процесса обучения менее опытных сотрудников? Что тут сказать? Остается только пожелать никому не попадать к такому начальнику, потому что научить ничему не научит, а вот нервов помотает.
Не, вру, научит. Даст бесценный опыт, почему не надо работать с такими людьми.
Интересно, а ваш начлаьник понимает, что вам с людьми работать противопоказано?
Если джун настолько не обучаем - это уже не моя проблема. Я не штатный психолог. Повходили в айти за большими деньгами, а работать не хотят или не могут. Если нет способностей или не лежит душа - значит менять профессию.
И я не начальник и не тим-лид. Мы все работаем в команде и делаем проект / продукт. Мы все, бывает, косячим, не роботы. Но когда кто-то из команды - сваливает свою работу на других, не тестирует или не проводит детальное исследование бага, а при этом говорит, что все сделал и все ок - это и есть саботаж. И эти люди знают, что они так поступают (им об этом говорили и не раз) и ничего не меняется.
Вы похоже на психолога маминой подруги. Тут много кейсов вам рассказали как в жизни. 1. Джун это не умный человек, с которым сеньору будет интересно общаться. 2. Джун это человек, от которого много не ждут на собеседовании, поэтому квалификацией он может не обладать совсем. 3. Каждый человек особенный, один у меня ровно в 6 вставал и уходил, хотя на месте Джуна, который за целый день ничего не сделал мысли должны быть хотя бы о развитии. Другой болтает весь день имитируя работу и т.д.
Оч жизненно. Всего два года работаю, но очень вымотан, хуже чем в офисе с ненормированным рабочим днём. Когда на вопрос для меня сложный отвечают в духе да тут же легко, ты этого не знаешь что-ли? Или когда сижу и дня два не могу продвинуться никак(из последнего - правильно в многопоточке разрулить) и прошу совета, а говорят: ну посиди подумай еще, попробуй сам разобраться¯\_(ツ)_/¯. Или подсказывают в общих чертах, хотя в 99% это нифига не работает из-за корнер кейсов и надо именно помощь с их учётом. В итоге очень медленно расту, чувство, что наоборот конкретно отупел, а за новое и сложное вообще браться не хочется.
Всякое конечно бывает.
Но обычно видно пытался человек разобраться сам или нет. Если пришел с вопросом - "а как сделать?" Значит не пытался. А если "я попробовал это, получил это, потом это - не вышло, и вот это - тоже не получилось, что еще можно сделать?" - вот это другой разговор.
Насчет подсказок в общих чертах - со мной тоже так бывало. Причина - нет готового решения сразу. Надо посидеть подумать, разобраться. Но это означает переназначить таску на себя. Когда есть время - лично я вполне этим занимаюсь и помогаю. Но чаще - времени нет, свой список задач, расписанных на две недели вперед + тех поддержка L3 или L4 + созвоны по архитектуре + созвоны по бизнес аналитике + созвоны по внезапным крупным проблемам. Обо всем это надо успеть подумать, принять решение и очень постараться не зафакапить.
Вроде, для таких ситуаций скрам и придумали. Раз в день каждый говорит, что сделал, что делает, как и в чём в данный момент затык, если он есть. Либо проблема решается тут же на скраме мудрым советом старших товарищей, либо можно подойти к сотруднику и позже подробно разобрать, что он там наворотил. Просто ответы 'делаю задачу, всё хорошо' не принимать и расспрашивать, что конкретно делает и что конкретно хорошо
Был на стажировке в 1 конторке за 300$/мем на позиции Джуна. Очень забавная таска была, за два дня сделать копию приложения конкурентов, над которой работала целая команда. На слова что невозможно технически, оказалось, что я плохой программист и вообще на фрилансе люди лучше и быстрее бы сделали.
Так что некоторых руков 300 вакансий на место затуманивает мозг. Учитывая, что я был единственный кодер на проекте.
«сИньор» это от слова «синь»? То есть он синячит много?
Доля правды в тексте есть (хотя меня не покидает чувство, что писал джун, хотящий зп синьора), но:
1) джун, чтобы приносить пользу уже через несколько недель должен уже на старте что-то уметь. Допускаю, что есть гении, которые уже через день-два начнут кодить как боги, но в большинстве случаев джун-нулевик уйдет в плюс хорошо, если через полгода.
2) джуна кто-то должен учить, а в некоторых случаях и контролировать. не во всех командах есть запас прочности на это. когда работала на первой работе нашим джуном мы занимались вдвоём - я учила человека писать тест-кейсы и баг-репорты, а наш миддл рассказывала о продукте (там было довольно сложно джуну разобраться) - вышли в плюс через пару недель, но во-первых нас было двое, во-вторых там был человек хорошо знавший теорию тестирования и очень быстро схватывающий, в-третьих это всё-таки тестирование, здесь порог входа ниже, но для дальнейшего развития уже придется потрудиться.
Во-первых. Чтобы нанять джуна, надо чтобы имело место быть:
ему можно чего-то дать, чтобы не переделывать много на постоянной основе либо вы работаете в "социальной" организации
есть кому учить, чтобы не получить команду из псевдо-мидлов, которые могут клепать только простые задачи
можно легко выгнать на мороз и взять следующего, так как совершенно неинтересно потом думать, как его уволить, если взял "на белую"
Во-вторых. Нанимают людей "под бюджет". Я вообще не очень понимаю, к чему писать статью, если вопрос бабла первичен? Любой человек нанимается, чтобы от него получить отдачу, которая не просто "будет", а будет приносить деньги. Может быть ситация, когда у вас нет ни одного сеньйора просто потому, что деньги ограничены. Либо просто два разработчика на проекте уровня сеньор/мидл. Вот просто интересно, у вас есть бюджет на сеньора, но вы принципиально берете джуна? Три раза ха-ха. Вам, как руководителю, дали деньги на "здесь и сейчас" на вакансию. И тогда вы берете готового спеца с рынка. Либо не дали, тогда вы берете человека работать за еду, а лучше сразу пучок, чтобы через полгода повысить самого лучшего.
Примеры отдельных людей в статье говорят лишь о том, что автору неплохо было бы осознать как работает закон Больших чисел :)
Смысл найма джуниоров заключается не в том, чтобы иметь "дешевую рабочую силу", а в том, чтобы создать продуктивную и лояльную команду. Этого можно добиться только если вы платите им столько, сколько они действительно заслуживают.
Да нет, как раз в этом :) Потому что первое предложение противоречит последнему в вашей же цитате. Если вы им платите столько, сколько они заслуживают - значит вы получаете "дешевую рабочую" силу. Это нормально. Наивный рабочий джун за миску супа с нормальными мозгами после универа - это прекрасно. Только не надо строить из себя святого :)
Ну тут как сказать. Я однажды искал себе пару мидлов, отсобеседовал за полгода кучу народа, в итоге наняли двух джунов с которыми я увидел что сработаемся. И это было лучшее решение в моей жизни. Один делал быстро и плохо, но позволил здорово сократить сроки, несмотря на то что пришлось потом серьезно рефакторить. Второй делал медленно и вдумчиво, а главное слушал внимательно и в итоге возглавил проект когда я с него уже ушел в другую компанию. Регалии - они такое себе. Надо с людьми работать.
Ну и да, "отличное новое полено" после универа это стажер.
С учетом того как сильно разняться у компаний требования к тем же джунам и мидлами порой не понятно кто перед тобой. Например, на прошлом месте работы человек был сеньером, а пришел к нам на собес и чуть ли не на уровне джуна отвечал - про докер не слышал, контейнеризация от лукавого и прочее. При найме всегда нужно понимать, на сколько команда готовка найти у себя ресурсы, чтоб уделить достаточно внимания новому сотруднику, а джуну в особенности.
контейнеризация от лукавого
А вы считаете, что все должны думать что контейнеризация от бога? И если кто так не считает, он сеньором быть не может? Интересное когнитивное искажение.
Не может конечно. Когнитивное искажение, уважаемый, это классифицировать инструмент в терминах "от лукавого"/"от бога". Таким людям нужно лечение, а не работа. Без искажений это звучит как "знаю этот инструмент на уровне блаблабла".
Когнитивное искажение, уважаемый, это классифицировать инструмент в терминах "от лукавого"/"от бога".
Я вас сейчас удивлю, но инструменты разные бывают. Есть хорошие, а есть и плохие. Это зависит и от конкретного инструмента и от его предназначения. И что очень важно – от задач которые этим инструментом решаются. А таки да, забивать гвозди микроскопом можно, но синхрофазотроном уже перебор. Лучше камнем попробовать. Вы так не считаете?
Не бывают они плохие и хорошие. По вашим же словам они бывают подходящие и нет. Но это вы в СПГС ударились. Я часто провожу собесы. Приходит чувак и говорит "я SQL руками не пишу" (это кстати не единичный случай). Не конкретно в решении где нужно поддерживать разные диалекты, и не по другим каким-то привязанным к задачам причинам. Просто не пишет. Принцип такой. Или не признает в принципе реляционок. Без привязки к тому что в них лежит и зачем оно там лежит. Просто не признает. Или считает что приложения должны быть 100% онлайн без автономности. Вне зависимости от того зачем они нужны и в каких условиях их эксплуатируют.
Я так-то только за если человек может внятно и связно рассказать где какой инструмент нужен а где не нужен. Это значит что можно не задавать ему глупые вопросы про хеш-таблицу и вызубренные принципы солид, а нормально перетереть за настоящую работу. Но в подавляющем большинстве случаев заявления о неприятии инструмента X - принципиальные и не подкреплены разумными аргументами. Такая вот фигня.
Не бывают они плохие и хорошие.
Вы очевидно никогда не сталкивались с TIA-Portal от Siemens. :D Ну или просто привыкли работать с плохими инструментами и не можете их отличить от хороших. Бывает.
Или не признает в принципе реляционок.
Я очень часто работаю с реляционными базами данных, они мне нравятся, SQL пишу хорошо и с удовольствием.
Но в последнее время иногда спрашиваю себя, так ли они незаменимы и не получится ли решение и лучше и даже проще без них. Но ясно понимаю, что у меня нет беспристрастности и на этот вопрос я не могу ответить. По крайней мере без какого-то эксперимента.
Докер - контейнер. Нужен, чтобы не перенастраивать переменные окружения под сборку каждого проекта, например. Виртуальная машина на минималках.
Три предложения - и джун в ваших глазах превращается... превращается... ну хотя бы в мидла. А если ему рассказать про кросскомпиляцию - это еще два предложения - то там и до сеньора не далеко)
Каким объективным методом аффтар меряет "Skill" на приведенном графике? К тому же "Сеньорити" подвержено инфляции. Сеньоры сейчас не то же самое, что 10 день назад. Поэтому набирая джунов, вы дай бог возьмете кого-то с недельными курсами.
После прочтения статьи у меня сложилось стойкое впечатление, что вы назвали засидевшихся (сразу скажу, что в этом нет ничего плохого) миддлов сеньорами и на основе этого построили целую статью.
Даже если пройтись по тезисам
У вас больше кандидатов и вы можете выбрать лучших. Если вы ищете full‑stack разработчика с 5+ годами работы на Python и 3+ годами работы на React, вариантов будет несравнимо меньше, и вам, скорее всего, придётся пойти на компромисс
Больше открытых резюме и больше кандидатов это не одно и то же. Случайный джун не является кандидатом на вашу вакансию (но может являться кандидатом на другую).
Чтобы стать кандидатом нужно соответствовать вакансии по стеку и сложности продукта. И как только мы начинаем учитывать значение слова "кандидат", то оказывается, что кандидатов-миддлов гораздо больше, чем джунов (и, с увеличением сложности продукта, количество кандидатов-сеньоров будет стремиться к количеству кандидатов-миддлов, т.к. кол-во вторых будет снижаться, а джуны там неуместны)
Джуниоры привносят в команду энергию — они хотят учиться, у них есть стремление проявить себя и добиться успеха. Их мотивация может быть заразительной! Вашим сеньорам понравится работать с умными и мотивированными коллегами. Это даст им возможность попробовать себя в менторской роли и взглянуть на свою работу свежим взглядом.
На перегретом всякими курсами "войди в айти, получай миллионы" данный тезис ну очень сомнителен. Джун сейчас может вообще не хотеть учиться, он хочет получать миллион нефти в наносекунду за то, что носит ярлык айтишника.
К тому же, горящие глаза могут быть как у миддла, так и у сеньора, особенно, когда он переходит в другой тип бизнеса (у меня, лично, из глаз фениксы вылетать начнут, если я устроюсь в сверхсовременный биотех).
Что касается "менторства": наличие хороших софт и хард скиллов не равносильно хорошему скиллу к обучению других, это другая сфера человеческой деятельности, на которую люди учатся отдельно. Да и вашим специалистам может совершенно не понравится подобный тип доп. нагрузки, тут уже писали про развивающиеся неврозы на почве менторства и это нормально. Срокам и бюджету проекта менторство тоже нанесёт урон.
Для включения менторства в процесс разработки недостаточно крикнуть "Нанимаем джунов, сейчас вырастим спеца!", нужна предварительная серьёзная оценка.
Ну и в довесок, спустя годик обучения джуна он может просто уйти с новыми знаниями в другую компанию :)
Джунов не ограничивают старые привычки — они не будут пытаться использовать те же технологии, что и в предыдущих компаниях, или воссоздавать те "гениальные" паттерны проектирования, которые были полезны только в определенном контексте.
Тут вы просто сделали ход конём, обесценив решения сотрудников, которые были рождены на других местах работы.
Напомню, что мы говорим про сеньоров, но вы пишете так, будто сеньоры вообще не думают о применимости решений в новом контексте. Сеньор это не чатгпт, который просто увидел в своей жизни много чужих умных строчек кода и бездумно предлагает их вставить в ваш проект.
Либо вы считаете миддлов сеньорами, либо просто обманываете читателей. Иначе я не могу объяснить подобную манипуляцию.
Джуны более открыты для работы с новыми технологиями и менее придирчивы к задачам. Это не значит, что вы должны заставлять их целыми днями исправлять баги, но это даёт вам больше гибкости в команде.
И миддлы, и сеньоры обычно рады изучить что-то новое, разнообразить свою работу. Однако, в отличии от джунов, они не будут предлагать внедрить технологию в проект по причине "она новая", а предварительно оценят технологию, взвесят риски, прикинут оценку по внедрению.
Но в любом случае, как это даст гибкость команды -- неизвестно. Гибкость за счёт чего? За счёт открытости к новым технологиям? Вы же не пытаетесь добавлять по новой технологии каждую неделю. Если это к тому, что джуны читают новости из мира разработки и могут сказать "вышла такая-то технология", то замените такого джуна на еженедельный дайджест, заодно и отфильтруете технологии на те, которые вам подходят и те, которые бесполезны/сырые/дорогие
Толковые джуны быстро учатся и ждут обратной связи, поэтому с ними проще работать. Они хотят совершенствоваться и знать, что вы думаете об их работе.
Ровно как и толковые миддлы, и толковые сеньоры. И как толковые люди. И даже животные. Тезис ради тезиса, уж простите
Самую большую группу должна составлять новая кровь.
Найм миддлов и сеньоров это тоже новая кровь. Но вообще тезис звучит как "текучка кадров это очень хорошо". Вы же не можете бесконечно расширяться, в конце концов
За сим я устал писать. Спасибо за внимание
Вот автор не учился по нормальному и у него сплошные ошибки вместо выводов. Оконченное академическое образование есть основа самодостаточности профессионала.
Академическое. Оконченное.
Без этого, скорее всего, будет отсутствовать необходимое для работы программиста абстрактное мышление. При окончании института студент должен выходить уже средним программистом. А если у претендента уровень новичок - это детский сад и результат быстрой переучки без профильного образования.
Нельзя стать программистом без профильного образования. И если по окончании института у студента всё ещё уровень новичок, то он выше и не прыгнет, значит он не учился.
А теперь к некоторым ошибками в Вашем тексте.
закон убывающей отдачи.
Такого закона не существует. А то что Вы приводите в математике называется теорема Вейерштрасса и говорит, что если неунывающая последовательность ограничена, то она имеет точный предел. В физике, в сопромате, в социологии, в теории управления есть подобные теоремы (изморомфные по доказательству теореме Вейерштрасса), но закона уб. отдачи нет.
Биле Гейтс и Ко - это пример использования ошибки выдавшего.
Свежая кровь - поговорим о господе нашем И. И. (Я.) Христе?
Вас послушать, так синьоры никому не нужны: зажравшиеся эксперты универсальных паттернов, ничего в этой жизни не хотят, ни к чему не стремятся. Тогда куда им податься, если все пресно и не вкусно?
Прикольно читать комменты от джунов (максимум) в соцаильном управлении, педагогике и экономике предприятия с завышенным ЧСВ. Если человек достиг синьерской лычки в программировании, почему-то считает, что он теперь компетентен в любой сфере человеческой деятельности. Чего стоят только перлы типо того, что устно зафиксировали условия задачи. Ну покажите теперь этот фикс. Как будто в голове пару полочек с аккуратно разложенными блестящими знаниями в программировании, а остальное в состоянии бардака валяется как попало.
Почему нанимать только сеньоров — проигрышная стратегия