Попробуйте посмотреть со стороны бизнеса — сроки, бюджеты, риски и тп.
Я думаю бизнес должен быть доволен, если лид при бюджете отдела может выжать больше используя сеньоров как основу.
В 95% реальных проектов ревью архитектуры которую создал текущий технический лид/сеньор/архитектор не делает никто
Хорошо это и плохо?
Непонятно почему жаль — у них была отличная возможность поработать на реальных проектах(со всеми "прелестями" типа жестких сроков
Похоже я не правильно оценивал ваши слова. В любом случае я не знаю, что у вас там было, и не мне высказывать такое мнение. Все понимают, что джуниора можно пускать только в локальный функционал, там где он при всем желание не может повлиять из подсистемы. А оценивать на сколько это эффективно, я бы дал лидам, а не бизнесу. Очень часто наблюдаю недоверие между бизнесом и разработчиками. Возможно для этого есть почва.
то есть по вашему если из трех "взрослых" убрать одного то с проектом ничего не случится? А зачем тогда их изначально было 3, а не 2?
Что бы делать "на треть" больше.
Обычная группа из сеньора + пары мидлов и 2-5 джуниоров имеет обычно следующее распределение — сеньор больше архитектор и пишет ключевые сложные куски, раскидывая более простые вниз и заодно объясняя что и как в придуманной им архитектуре.
Обычно, не значит правильно или лучше, если быть критичным.
Мне больше нравится команды построенные по принципу самоорганизации, где все равны с точки зрения прав и перед логикой, но есть арбитр в виде лида. А ревью той же архитектуры кто будет делать? И сеньор не значит архитектор, это две разные роли, которые конечно могут совпадать. Но архитектор может быть один на сотню человек. Архитектор вообще может плохо мочь в кодинг, а вот у сеньора в моем понимание такой преференции нет. А еще сеньоры могут возразить, указать на ошибке в архитектуре, предложить решение лучше, устроить мозговой штурм, до собственно говоря миллион аспектов в пользу сеньора.
пары мидлов и 2-5 джуниоров
Как раз вся статья про то, что если "+ пары мидлов и 2-5 джуниоров" заменить на сеньоров за те же деньги, то получиться быстрее и лучше. Зачем платить больше, если можно меньше в случае если брать сеньров?
Безусловно, сеньор центризм (или брать лучших) наверно подходит не для каждого бизнеса, а только для тех перед кем стоят актуальные вызовы, в виде конкуренции на техническом и пользовательском уровне. Возможно это больше присуще продуктовым компаниям.
Сеньор написал фреймворк на котором джуниоры клепали "формочки", точнее "задания/тесты"
Звучит как приговор. Мне даже джуниоров в этом случае жаль, интересно как много из них потом станет программистами?
Такое конечно может существовать и даже быть эффективным, но статья уж точно не претендует на общую практику для всех. Собственно говоря бедные компании тоже должны быть, что бы могли существовать богатые.
Возможно это ошибка выжившего, моя или ваше. В моем круге общения таких примеров не так много. Я думаю все эти многочисленные сайты делаются чаще не программистами, а пользователями используя готовый CMS или конструкторы сайтов.
Но если там можно делать все джуниорами, то это уже не "большая" индустрия: нет денег и конкуренции, и говорить об этом как то не интересно. Примерно как соревноваться с тем, кто и не собирался соревноваться.
Оффтоп:
делают всякого рода веб-сайты/интернет-магазины.
А потом у них интернет магазины, в которых изменение одной позиции фильтра приводит к рефрешу всей страницы.
Вы конечно же можете сказать, ну и пусть, главное, что бы выполняло задачи бизнеса. Конечно, вершины у бизнеса разные. Это их выбор или цель.
Честно говоря, мне очень сложно представить простые проекты, где очень много рутины и простейшего линейного формошлепства. Мне это уже представляется задачей пользовательско-прикладного уровня. Но даже если допустить существование такого варианта, тогда я не понимаю, что за сеньор там будет работать? Зачем ему там работать? Скорее всего это будет сеньор и соответствующей не высокой квалификации, ну то есть вовсе не тот человек, о котором думают на хабре.
Ключевой момент, простота задачи чаще все может стать очевидна, только после ее выполнения. "До", по опыту, эта очевидность иллюзорна. Но если не брать и этот "факт" во внимание, то я бы еще вспомнил про сильную не эластичность в возможность жонглирования разрабами по мере продвижения проекта. Простые задачи могут появлялся и исчезать, а менять оперативно набор квалификаций в команде обычной компании сложно.
По поводу bus-фактора.
Я не думаю, что брать джуниоров это способ решения басфактора. Он решается по другому: открытая среда, общее обсуждение проблем, ревью кода, парное программирование, митинги и ретроспективы, документация и спецификации.
только он обычно в курсе того что он делал
По правде говоря, я думаю, это сигнал, о том, что консерваторию надо править.
Ведь если посмотреть этим же взглядом, на предложенный вариант, то получить, что если выпадет из обоймы в середине проекта тот единственный сениор, и останутся только его несколько джунов и мидлов, то точно будет полный швах. В противном случае, ну выпадет из обоймы один из трех сеньоров — проблемы не случится, у нас еще два "взрослых" человека на проекте.
В среднем, все же, армия состоящая только из офицеров неэффективна.
Я не сторонник аналогий, очень легко натянуть одно на другое и не заметить. Можно углубится и утонуть в сравнение профессиональной контрактной армии против срочников, задуматься о разных родах войск и спецподразделениях, об эффективности использования технический пепелацев в зависимости от того, в чьих руках они находятся. И задуматься, является ли сеньор аналогом офицера в армии, сеньор про компетенции, и совсем слабо пересекается с вопросами управлениям или понятием командный игрок.
Не понятно зачем умерить гонор. Вы же не знаете ничего о команде и продукте. И далеко не все хотят в Яндекс. Я, например, совершенно к нему спокоен. Да, я беру одно из 300 и не вижу в этом проблемы. И собственно говоря нет проблемы взять джуниора, проблемы начинаются дальше.
А я же не спорю, что возможно так и есть. Но разговор не об этом, а о том, как таких людей выявить, если каждый день по 50 откликов в небольшую команду и нет отдела надрессированных HR'ов
Раз в год и палка стреляет. Знаю такие случаи.
И я не против поговорить с такими людьми, но дайте в резюме хотя бы намек, что вы программист, а не человек решивший, что надо что то в жизни менять и побежал куда ветер дует.
Расскажите о ваших критериях и количестве откликов? Абсолютно всех зовете на собеседование или даете задание?
А какие слова там должны быть у джуниора? Это нормально, когда у выпускника вуза кроме вуза ничего нет. Даже если он полгода назад выпустился, потому что без опыта не берут никуда. Я вот даже про год армии в резюме писал на всякий случай, чтобы не возникало вопросов, почему я больше года назад вуз закончил и еще нигде не работал.
Нет. Не соглашусь. Это не нормально. Исключения бывают. Но если человеку вообще нечего сказать в резюме кроме [X]ГУ, 2020. Это не нормально. Тут не только опыт, но и логика говорит, что не эффективно на таких кандидатов тратить время. Чаще всего я не представляю вообще, какая у человека была учебная программа, что он знает, что не знает. С скорее предположу, что звезд с неба не хватал, активности не проявлял, в программисты попал случайно.
Про средний вуз это вообще смешно. От места обучения языки и принципы программирования меняются? Толковый джуниор отличается от нетолкового тем, что сам в этом может разобраться, ему не требуется чтобы учитель из хорошего вуза это показал.
Мне не смешно, а грустно. Бывает даже грустно за ИТМО.
Раз можно делать дома, то можно сразу указать его в вакансии и не проверять вручную миллионы безликих резюме.
В вакансии есть простой тест. Тут конечно можно поиграть с вариациями, сложностью и автоматизацией проверки результатов.
Но есть человек умеет пользоваться гитом, имеет опыт написания своих мелких проектов, пусть и стандартных, но все равно «не достоен» быть джуном в вашей компании.
Проекты конечно же не свои, а те что на курсах сделал. По ним нельзя определить совершенно ничего. У всех стандартные Spring. Перелицовка стандартных демо примеров.
Такая позиция взялась не просто так, а на основе опыта общения. Да, среди них могут быть изумительные программисты и в моих командах есть такие примеры, когда человек без профильного образования и даже без высшего образования стал хорошим программистом. Но у меня нет ресурсов, что бы таких людей выявлять. Из 100 кандидатов — 80 клонов после курсов. Да и как сравнивать? Знаний у них нет, есть только то, что успели впихнуть за полгода. Пишут все одинакового плохо. Да и сколько времени потребуется, что бы достичь хотя бы уровня из ВУЗа? Одно время давали задачи вообще не связанные с программированием. Но особой точности в выборе не добавило. Зачем их рассматривать если их обработать я всех все равно не могу, но за то могу уделить внимание тем, кто хоть как то привлекает внимание.
Скепсис в вопросе абсолютно оправдан. Я не знаю хорошей методики кроме стажировки при отбора джуниоров. Про это в статье сказано.
Тем не менее используем стандартный подход задающейся целью лучше не взять достойного, чем взять не достойного.
Начинается все с простейшее тестовое скриниг задание в HH тестах. На результат не смотрим (отсеиваем тех, кто не готов потратить 5 минут, а не просто веерно рассылает), смотрим на другое.
У человека в резюме только полгода онлайн курсов и стандартный гитхаб с курсов(калькулятор, mvc что-нибудь)? Скорее всего не достоен.
Профильное образование среднего вуза, но больше ни слова? Даже какая выпускная работа была или средний бал? Ну хотя бы, что то, что могло отличить резюме среди миллиона других безликих — скорее всего тоже не достоен.
Ок, есть профильное образование/хороший вуз/подходящая специальность/резюме цепляет чем то другим, даем простое тестовое задание с возможность выполнить дома с ориентировочным временем выполнения 40 минут — 2 часа. Описываем ожидания от консольной программы(Что бы запускалась и выдавала правильный результат в первую очередь).
Запускается, выполняет правильный результат? Зовем на собеседование. Обсуждаем, уже то, как написано, почему, какая мотивация, говорим за жизнь и технологии. Если не сразу нет уже на собеседование — то достоин.
По этому поводу какие то статьи видел. Но, это что то из разряда того, как у человека работает индукция и дедукция. Не уверен, что это обучаемый параметр, но это не точно.
Нанимать у тех, кто не делает ставку на сеньоров. Брать тех кто перерос мидла. Переманивать. Да с ними туго, но с джуниорами не проще и не лучше. Имею опыт по 100 откликов джунов за 2 дня на вакансию, среди них достойных очень не большой процент.
В конечном итоге, нет сеньора, можно взять мидла, нет мидлов, ну тогда джуниоров. На безрыбье и рак рыба.
Справедливости ради, я думаю никто, даже теоретически, не рассматривает возможность оставить джуниора один на один с большим проектом. Вопрос скорее стоит так, смогут ли джуниоры экономить время сеньору. В реально мире существует распределение на мастеров и подмастерьев. Кузнец и помощник кузнеца.
Правильно ли я понял, что в Separate chaining массив bucket'ов может ссылаться на массив bucket'ов? После того как связанный список превзойдет load factor и вместо linked list будет создан новый массив бакетов. И таким образом получим древовидный многоуровневый хеш.
Или при Rehash меняется размер основного массива bucket'ов?
Не знаю, что в книге, но в выжимке капитанство. В принципе это давно стандарт, например, вот правила на которые мы ориентируемся kernel.org
Хотел бы только добавить, что важно писать не только «зачем», но и «мотивацию». Между «зачем» и «мотивация» на самом деле большая разница. Из мотивации можно выяснить точку зрения автора коммита. Часто бывает неочевидно, почему для решения был выбран именно «вот такой» подход. Дам ссылку на наш опыт насаживания подобного подхода написания текста коммитов Что дал переход с SVN на Git или Git как ключ для синергии хороших практик
Да, сам тока что нашел. Написал что нет экспорта, а потом пошел проверять. Была ситуация, когда случайно удалил счет, вместе с ним пропали и все транзакции. На тот момент нельзя было делать бекапы.
Года 4 пользуюсь сервисом. Перепробовал до этого кучу других сервисов, все нет то. Самый большой негатив это отсутствие суппорта. Но предъявлять претензии по суппорту бесплатного продукта… все же надо иметь снисхождение. На премиум не проблема перейти, но хотелось бы и изменения отношения к поддержке.
И да, экспорта истории нет ни в каком виде, обидно будет все потерять если закроются.
Я думаю бизнес должен быть доволен, если лид при бюджете отдела может выжать больше используя сеньоров как основу.
Хорошо это и плохо?
Похоже я не правильно оценивал ваши слова. В любом случае я не знаю, что у вас там было, и не мне высказывать такое мнение. Все понимают, что джуниора можно пускать только в локальный функционал, там где он при всем желание не может повлиять из подсистемы. А оценивать на сколько это эффективно, я бы дал лидам, а не бизнесу. Очень часто наблюдаю недоверие между бизнесом и разработчиками. Возможно для этого есть почва.
Что бы делать "на треть" больше.
Обычно, не значит правильно или лучше, если быть критичным.
Мне больше нравится команды построенные по принципу самоорганизации, где все равны с точки зрения прав и перед логикой, но есть арбитр в виде лида. А ревью той же архитектуры кто будет делать? И сеньор не значит архитектор, это две разные роли, которые конечно могут совпадать. Но архитектор может быть один на сотню человек. Архитектор вообще может плохо мочь в кодинг, а вот у сеньора в моем понимание такой преференции нет. А еще сеньоры могут возразить, указать на ошибке в архитектуре, предложить решение лучше, устроить мозговой штурм, до собственно говоря миллион аспектов в пользу сеньора.
Как раз вся статья про то, что если "+ пары мидлов и 2-5 джуниоров" заменить на сеньоров за те же деньги, то получиться быстрее и лучше. Зачем платить больше, если можно меньше в случае если брать сеньров?
Безусловно, сеньор центризм (или брать лучших) наверно подходит не для каждого бизнеса, а только для тех перед кем стоят актуальные вызовы, в виде конкуренции на техническом и пользовательском уровне. Возможно это больше присуще продуктовым компаниям.
Звучит как приговор. Мне даже джуниоров в этом случае жаль, интересно как много из них потом станет программистами?
Такое конечно может существовать и даже быть эффективным, но статья уж точно не претендует на общую практику для всех. Собственно говоря бедные компании тоже должны быть, что бы могли существовать богатые.
Возможно это ошибка выжившего, моя или ваше. В моем круге общения таких примеров не так много. Я думаю все эти многочисленные сайты делаются чаще не программистами, а пользователями используя готовый CMS или конструкторы сайтов.
Но если там можно делать все джуниорами, то это уже не "большая" индустрия: нет денег и конкуренции, и говорить об этом как то не интересно. Примерно как соревноваться с тем, кто и не собирался соревноваться.
Оффтоп:
А потом у них интернет магазины, в которых изменение одной позиции фильтра приводит к рефрешу всей страницы.
Вы конечно же можете сказать, ну и пусть, главное, что бы выполняло задачи бизнеса. Конечно, вершины у бизнеса разные. Это их выбор или цель.
Честно говоря, мне очень сложно представить простые проекты, где очень много рутины и простейшего линейного формошлепства. Мне это уже представляется задачей пользовательско-прикладного уровня. Но даже если допустить существование такого варианта, тогда я не понимаю, что за сеньор там будет работать? Зачем ему там работать? Скорее всего это будет сеньор и соответствующей не высокой квалификации, ну то есть вовсе не тот человек, о котором думают на хабре.
Ключевой момент, простота задачи чаще все может стать очевидна, только после ее выполнения. "До", по опыту, эта очевидность иллюзорна. Но если не брать и этот "факт" во внимание, то я бы еще вспомнил про сильную не эластичность в возможность жонглирования разрабами по мере продвижения проекта. Простые задачи могут появлялся и исчезать, а менять оперативно набор квалификаций в команде обычной компании сложно.
По поводу bus-фактора.
Я не думаю, что брать джуниоров это способ решения басфактора. Он решается по другому: открытая среда, общее обсуждение проблем, ревью кода, парное программирование, митинги и ретроспективы, документация и спецификации.
По правде говоря, я думаю, это сигнал, о том, что консерваторию надо править.
Ведь если посмотреть этим же взглядом, на предложенный вариант, то получить, что если выпадет из обоймы в середине проекта тот единственный сениор, и останутся только его несколько джунов и мидлов, то точно будет полный швах. В противном случае, ну выпадет из обоймы один из трех сеньоров — проблемы не случится, у нас еще два "взрослых" человека на проекте.
Я не сторонник аналогий, очень легко натянуть одно на другое и не заметить. Можно углубится и утонуть в сравнение профессиональной контрактной армии против срочников, задуматься о разных родах войск и спецподразделениях, об эффективности использования технический пепелацев в зависимости от того, в чьих руках они находятся. И задуматься, является ли сеньор аналогом офицера в армии, сеньор про компетенции, и совсем слабо пересекается с вопросами управлениям или понятием командный игрок.
Не понятно зачем умерить гонор. Вы же не знаете ничего о команде и продукте. И далеко не все хотят в Яндекс. Я, например, совершенно к нему спокоен. Да, я беру одно из 300 и не вижу в этом проблемы. И собственно говоря нет проблемы взять джуниора, проблемы начинаются дальше.
И я не против поговорить с такими людьми, но дайте в резюме хотя бы намек, что вы программист, а не человек решивший, что надо что то в жизни менять и побежал куда ветер дует.
Расскажите о ваших критериях и количестве откликов? Абсолютно всех зовете на собеседование или даете задание?
Нет. Не соглашусь. Это не нормально. Исключения бывают. Но если человеку вообще нечего сказать в резюме кроме [X]ГУ, 2020. Это не нормально. Тут не только опыт, но и логика говорит, что не эффективно на таких кандидатов тратить время. Чаще всего я не представляю вообще, какая у человека была учебная программа, что он знает, что не знает. С скорее предположу, что звезд с неба не хватал, активности не проявлял, в программисты попал случайно.
Мне не смешно, а грустно. Бывает даже грустно за ИТМО.
В вакансии есть простой тест. Тут конечно можно поиграть с вариациями, сложностью и автоматизацией проверки результатов.
Проекты конечно же не свои, а те что на курсах сделал. По ним нельзя определить совершенно ничего. У всех стандартные Spring. Перелицовка стандартных демо примеров.
Много у кого бомбануло Вы безумны, остановитесь пока не поздно
Такая позиция взялась не просто так, а на основе опыта общения. Да, среди них могут быть изумительные программисты и в моих командах есть такие примеры, когда человек без профильного образования и даже без высшего образования стал хорошим программистом. Но у меня нет ресурсов, что бы таких людей выявлять. Из 100 кандидатов — 80 клонов после курсов. Да и как сравнивать? Знаний у них нет, есть только то, что успели впихнуть за полгода. Пишут все одинакового плохо. Да и сколько времени потребуется, что бы достичь хотя бы уровня из ВУЗа? Одно время давали задачи вообще не связанные с программированием. Но особой точности в выборе не добавило. Зачем их рассматривать если их обработать я всех все равно не могу, но за то могу уделить внимание тем, кто хоть как то привлекает внимание.
Тем не менее используем стандартный подход задающейся целью лучше не взять достойного, чем взять не достойного.
Начинается все с простейшее тестовое скриниг задание в HH тестах. На результат не смотрим (отсеиваем тех, кто не готов потратить 5 минут, а не просто веерно рассылает), смотрим на другое.
У человека в резюме только полгода онлайн курсов и стандартный гитхаб с курсов(калькулятор, mvc что-нибудь)? Скорее всего не достоен.
Профильное образование среднего вуза, но больше ни слова? Даже какая выпускная работа была или средний бал? Ну хотя бы, что то, что могло отличить резюме среди миллиона других безликих — скорее всего тоже не достоен.
Ок, есть профильное образование/хороший вуз/подходящая специальность/резюме цепляет чем то другим, даем простое тестовое задание с возможность выполнить дома с ориентировочным временем выполнения 40 минут — 2 часа. Описываем ожидания от консольной программы(Что бы запускалась и выдавала правильный результат в первую очередь).
Запускается, выполняет правильный результат? Зовем на собеседование. Обсуждаем, уже то, как написано, почему, какая мотивация, говорим за жизнь и технологии. Если не сразу нет уже на собеседование — то достоин.
В конечном итоге, нет сеньора, можно взять мидла, нет мидлов, ну тогда джуниоров. На безрыбье и рак рыба.
Или при Rehash меняется размер основного массива bucket'ов?
Хотел бы только добавить, что важно писать не только «зачем», но и «мотивацию». Между «зачем» и «мотивация» на самом деле большая разница. Из мотивации можно выяснить точку зрения автора коммита. Часто бывает неочевидно, почему для решения был выбран именно «вот такой» подход. Дам ссылку на наш опыт насаживания подобного подхода написания текста коммитов Что дал переход с SVN на Git или Git как ключ для синергии хороших практик
И да, экспорта истории нет ни в каком виде, обидно будет все потерять если закроются.